Jeff King <> 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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to