W dniu 2016-06-30 o 08:22, Jeff King pisze: > On Wed, Jun 29, 2016 at 12:48:33PM +0100, Laszlo Papp wrote: > >> Old releases are maintained with important bug fixes or even new features >> in our case. It sometimes means that we need to cherry-pick commits across >> branches, like from master to a specific release branch. >> >> Cherry-picking changes the hash of the commit, therefore, this may no >> longer work for cherry-picks: >> >> git tag --contains >> >> I am thinking of having something like: >> >> git tag --contains-follow >> >> which would follow cherry-picks. I am not sure how easily and/or >> efficiently this can be implemented, but my gut feeling is that in the vast >> majority of the cases, the content check would bail out already at the >> "subject line". > > Git generally considers commits "equivalent" based on the patch-id, whic > his a sha1 of the diff (modulo some canonicalization). The problem with patch based equivalence is that for cherry-picking on old release branches you might need to modify a patch for it to apply - and then patch-id might not detect it. [...] > Of course there are other ways of determining commit equivalence. You > could find ones with duplicate commit messages, or duplicate subjects, > or whatever. But if you have a cherry-picking workflow, I suspect the > easiest thing may be to simply use "git cherry-pick -x", which will > write the sha1 of the original commit into the cherry-picked commit > message. You can then use that to correlate directly. "git log --grep=<sha-1>" would help there (or even match the specific message that "git cherry-pick -x" adds). -- Jakub Narębski -- 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