Junio C Hamano <gitster@xxxxxxxxx> writes: > Remi LESPINET <remi.lespinet@xxxxxxxxxxxxxxxxxxxxxxx> 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. -- 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