Ok, Thanks for all the informations > 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". Yes, It's obvious that "patch" has not the same degree of safety as the git apply command. But I thought that any patch working with git apply should work with the "patch" command and give the same output, It seems that this is not true, regarding file: 10 10 10 10 20 diff: @@ -1,2 +1,3 @@ +10 10 10 @@ -1,4 +2,5 @@ 10 10 +cc 10 10 (I changed it to have 2 line context). Of course these are hand-written patches, which can't be obtained with a diff (except with the non coalescing git add -p as you said yourself). Wouldn't it be a problem? > In other words, isn't the right fix to coalesce that input, so that > the second hunk does *not* require fuzzy application in the first > place? Yes, you're right, that will be fixed if we restore coalescing, I didn't thought of this possibility. This will cause fewer split but we have the edit option anyway. Thanks -- 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