2010/2/8 Junio C Hamano <gitster@xxxxxxxxx>: > You cannot go by the line numbers on the "@@ -l,k +m,n @@" header line you > see in the second patch you received. On that line, only k and n are > reliable numbers (the must match the patch text). l and m are unreliable; > being able to apply even if the text you have at hand does not exactly > match l and m is the whole point of transmitting the change in the patch > format. The _only_ information you have usable at that point is that > there are _at least_ 3 blank lines before the addition, and perhaps the > fact that the hunk ends without post context lines. The latter tells you > that it must apply at the end, but still doesn't tell you how many blanks > you need to add back at EOF before applying the patch. I agree. The information is not enough if you apply one patch at the time. But my usage case that my test tries to demonstrate is different: I already have a number of commits in my repository (received either by pulling or applying a whole series of patches at once). I then do, for example: git rebase --whitespace=fix HEAD~4 to clean up the existing commits. That rebase uses "git apply" internally seems like an implementation detail that I as a user of rebase don't care about. I just expect it to work. I see at least two possible ways to implement that: 1. Have "git rebase" give "git apply" a special option so that it will apply patches beyond the end of file (and trusting the line numbers in the chunks). 2. Having "git rebase" remember the number of blanks line that was removed in each previous file in previous fixed commits and add them back just before invoking "git apply". It is possible that it is too much work to implement it to be worthwhile (especially solution 2), but I do think it is possible. If you don't agree, fair enough. In that case I will hold on to the test case and only re-submit it if I can also include a fix. -- Björn Gustavsson, Erlang/OTP, Ericsson AB -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html