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 -- 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