Thread (15 messages) flat view 15 messages, 7 authors, 2016-06-15

Re: [PATCH] git-apply doesn't handle same name patches well

From: Don Zickus <hidden>
Date: 2016-06-15 22:44:44

On Fri, Jun 13, 2008 at 09:32:52PM +0100, Johannes Schindelin wrote:
Hi,

On Fri, 13 Jun 2008, Don Zickus wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help