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

[Jeff King <peff@peff.net>]

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? Though my
proposal would make it harder to change it in the future (as does
John's).

With mine, I wonder if you could use a different "loose" definition that
does not take the filenames into account.  Using something like the
changes in file sizes would be unique, but would not properly map to
strict cases (a patch-id that adds 5 lines to the end of a 100-byte file
may match one that adds the same five lines to the end of a 200-byte
file).

-Peff