Re: [RFC/PATCH] patch-ids: check modified paths before calculating diff

[John Keeping <john@keeping.me.uk>]

On Wed, May 29, 2013 at 11:48:53AM -0700, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
> 
> > On Wed, May 29, 2013 at 11:08:46AM -0700, Junio C Hamano wrote:
> >
> >> This has rather interesting ramifications on cherry-pick and rebase,
> >> though.  Both command can handle changes that come from an old tree
> >> before some paths were renamed, but strict patch-id would not spot
> >> equivalent changes we already have in our history if our change
> >> happened after a rename, i.e.
> >> 
> >>    Z
> >>   /
> >>  O---R---X---Y
> >> 
> >> where Z updates path F, R moves F to G and X changes G the same way
> >> as Z changes F, and we are trying to cherry-pick Z on top of Y.  The
> >> cherry-pick filter will see different patch-id for Z and X.
> >
> > True. That is a problem with the current patch-id system, no?
> 
> Correct.  That is why I suggested not to change the external
> interface (i.e. what is shown from patch-id command) as people may
> have kept them, but wondered if a possible improvement may be to
> exclude the name from ids when we internally generate two sets of
> Ids and intersect them, i.e. log --cherry.

Would that not rely on the files still being in the same order?  Since
we essentially hash the content of the patch, it will presumably be
quite different if the order of the files in the patch changes.

I expect it's possible to work around that by being a bit more clever
though.  Perhaps hash each file individually and then sort those and
hash the concatenated result?