From: Drew Northup <drew.northup@maine.edu>
Date: Fri, 04 Mar 2011 21:49:50 GMT
Subject: Re: [BUG] git-am silently applying patches incorrectly
Message-ID: <1299275390.24965.17.camel@drew-northup.unet.maine.edu>
In-Reply-To: <7v39n27llq.fsf@alter.siamese.dyndns.org>


On Fri, 2011-03-04 at 11:05 -0800, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
> 
> > Looking at it closer, however, I noticed that the false hit (i.e. "two
> > blocks closed, a blank line, return 0 and the end of function") in this
> > particular case only appears because we applied the previous hunk.  In the
> > version of the file in 0ce3017b, there is only one such place and there
> > should be no ambiguity in the patch application.
> >
> > The problem we are seeing is caused only because we look at the result of
> > application of the previous hunks in the patch and incrementally try to
> > apply the remaining hunks.  So clearly "git apply" can and should be fixed
> > for this case by teaching find_pos() not to report a match on a line that
> > was touched by application of the previous hunk.
> 
> And here is a quick and dirty fix to do something like that.  It assumes
> that the hunks for a single file being patched are already sorted in the
> ascending order (which should be the case), and may regress cases where we
> used to find a match even when the version you are patching has moved
> functions around in the file by failing to notice a match.  And it does
> get the same result as your GNU patch test.
> 

It checks out here applied against master. I don't know how I got it to
work the first time without this patch--but I'm pretty sure I don't want
to know at this point.

-- 
-Drew Northup
________________________________________________
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59