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

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

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...