Hi, On Fri, 13 Jun 2008, Don Zickus wrote: > When working with a lot of people who backport patches all day long, > every once in a while I get a patch that modifies the same file more > than once inside the same patch. git-apply either fails if the second > change relies on the first change or silently drops the first change if > the second change is independent. > > The silent part is the scary scenario for us. Also this behaviour is > different from the patch-utils. > > I have modified git-apply to cache the filenames of files it modifies > such that if a later patch chunk modifies a file in the cache it will > buffer the previously changed file instead of reading the original file > from disk. > > Logic has been put in to handle creations/deletions/renames/copies. All the > relevant tests of git-apply succeed. > > A new test has been added to cover the two cases I addressed. > > The fix is relatively straight-forward. But I'm not sure if this new > behaviour is something the git community wants. The scary part is about adding a linked list for file names you want to look up. Not that performance matters here, I guess, but we _already_ have something much more efficient in Git, namely path-lists. You could use that, and end up with a substantially smaller patch. Ciao, Dscho -- 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
