Jeff King <peff@xxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html