From: Remi Lespinet <remi.lespinet@ensimag.grenoble-inp.fr>
Date: Mon, 01 Jun 2015 21:37:39 GMT
Subject: Re: [RFC] solving a bug with hunks starting at line 1 in git apply
Message-ID: <864699446.258590.1433194659960.JavaMail.zimbra@ensimag.grenoble-inp.fr>
In-Reply-To: <xmqqeglv5kg1.fsf@gitster.dls.corp.google.com>

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