On Wed, May 29, 2013 at 11:48:53AM -0700, Junio C Hamano wrote: > Jeff King <p...@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? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
