Re: [RFC] solving a bug with hunks starting at line 1 in git apply

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

Junio C Hamano <gitster@pobox.com> writes:

> Remi LESPINET <remi.lespinet@ensimag.grenoble-inp.fr> writes:
>
>> first original file:
>>
>> 10
>> 20
>> 30
>> 40
>>
>> for the following diff file:
>>
>> @@ -1,2 +1,2 @@
>>  20
>> -30
>> +35
>>  40
>>
>> The patch will not be applied with a git apply command, but it will
>> with a basic patch command.
>
> Doesn't that merely indicate a bug in "patch", though?

This needs a bit gentler explanation.  Imagine you are doing a usual
"git diff" with two lines of context, with a longer original.  A
change to do s/30/35/ would look like this:

@@ -1,5 +1,5 @@
 10
 20
-30
+35
 40
 50

And an attempt to apply this patch to an original that does not have
10, 20, 30, 40 and 50 in this order must fail.

On the other hand, if the change were instead s/20/35/, then the
diff output would look like this instead:

@@ -1,4 +1,4 @@
 10
-20
+25
 30
 40

Notice that the pre-context lines in this second example is only one
line.  Is it giving the same degree of safety if we rejected an
attempt to apply this patch only when the original does not have 10,
20, 30 and 40 in this order?

No.  Because we are doing two-line context patch, the patch is not
just saying "this change applies to a place where the first line is
10".  It also is saying "there is no line before that line".

To answer my own question in the previous message, we cannot tell
only from that example which of "git apply" and "patch" is wrong.
If you generated the patch with "git diff -U1", then "git apply"
that insists that there must be no line before that "20" is wrong.
If you generated the patch with "git diff" with the default two-line
context, then "patch" is wrong if it does not make sure "20" is the
first line.