On Fri, Jun 13, 2008 at 09:32:52PM +0100, Johannes Schindelin wrote: > 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. Thanks for the feedback. I was unaware of path-lists. I'll try to find an example and implement it if it works. Cheers, Don -- 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
