Re: [PATCH] git-apply doesn't handle same name patches well
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Jun 13, 2008, 20:32 UTC
- Message-ID
- <alpine.DEB.1.00.0806132131180.6439@racer>
- In-Reply-To
- <1213376131-20967-1-git-send-email-dzickus@redhat.com>
Hi,
On Fri, 13 Jun 2008, Don Zickus wrote:
Show 21 quoted lines
> 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