On Fri, 2011-03-04 at 11:05 -0800, Junio C Hamano wrote: > Junio C Hamano <gitster@xxxxxxxxx> 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 -- 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