Re: Bug report: git apply --cached --reject

[Junio C Hamano <gitster@pobox.com>]

Patrick Stevens <patrick@patrickstevens.co.uk> writes:

> I don't think this behaviour is intended; in the report I give a couple
> of variations which correctly do what I expected, and this one breaks
> the semantics I expect, given the behaviour of those variations. I have
> not tried to find the source of the bug.

I do not think this is intended, either.  It certainly is not
something I would expect to see as an end user.  I somehow suspect
that when we added "--reject", we didn't even mean to make it work
with "--cached" in the first place.

A more plain-vanilla case like below, where an existing file sees a
two-hunk patch, but only one of the hunks apply cleanly,
demonstrates that the command, with an option to touch the index,
does not want to take any ...

--- >8 ------ >8 ------ >8 ------ >8 ------ >8 ------ >8 ---

seq 1 10 >file && git add file && git commit -m "1 to 10"
seq 1 10 | sed -e '/1/s/$/+/' >file
git diff --stat -p >patch

seq 1 10 | sed -e '/9/s/$/+/' >file
git commit -m "9 plus" file

rm -f file.rej
git reset --hard
git apply --reject patch
# inspect the index and working tree to see what happened here
# this one, that does not touch the index, works as expected.

rm -f file.rej
git reset --hard
git apply --cached --reject patch
# inspect the index and working tree to see what happened here

rm -f file.rej
git reset --hard
git apply --index --reject patch
# inspect the index and working tree to see what happened here

--- 8< ------ 8< ------ 8< ------ 8< ------ 8< ------ 8< ---

... half-baked changes.  The above prepares a 10-line file and a
patch that touches its first and the last line.  It then makes a
modification that textually conflicts the second last line to the
target file, and tries to apply the patch.

We do get .rej file in all cases, but in the mode that would touch
the index, the command refuses to put the result of an incomplete
patch application to the index, even though it updates the working
tree files with partial application.

The log message of 8938045a (git-apply --reject: finishing touches.,
2006-08-27) does mention that with "--index", it is the designed
behaviour to update the index for paths to which the patches were
cleanly applied, with a reasonable justification.  Even though it
also implies at the same time that it is also the designed behaviour
to leave the index untouched for paths that got .rej files, I do not
offhand see it explains the reason behind the design very well.  I
suspect that it was to avoid committing a half-resolved state by
mistake, but then it does not prevent the user from committing a
no-modification by mistake, and that is why I say "not ... very well"
here.  In any case, it does not even mention what ought to happen in
the "--cached" case, so...