{"thread":{"id":"42744","subject":"git tag --contains for cherry-picks","startedAt":"2016-06-29T11:48:39Z","lastAt":"2016-06-30T10:41:35Z","messageCount":3,"participants":["Laszlo Papp","Jeff King","Jakub Narębski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"290479","messageId":"CAOMwXhNp9SwA_oQ8bE6-m72C+po+28maGtsP8wRFRfBLjSb5NA@mail.gmail.com","threadId":"42744","inReplyTo":null,"subject":"git tag --contains for cherry-picks","fromName":"Laszlo Papp","fromEmail":"lpapp@kde.org","sentAt":"2016-06-29T11:48:33Z","receivedAt":"2016-06-29T11:48:39Z","isPatch":false,"sender":{"key":"lpapp@kde.org","avatar":"https://gravatar.com/avatar/cffb9fb0b214d200319b3133ff5e78dcf358cc4db1bf565991e622c8c095d185?d=mp&s=160"},"body":"Dear List,\n\nWe have several release branches as well as a master branch where the\nactive development happens.\n\nOld releases are maintained with important bug fixes or even new features\nin our case. It sometimes means that we need to cherry-pick commits across\nbranches, like from master to a specific release branch.\n\nCherry-picking changes the hash of the commit, therefore, this may no\nlonger work for cherry-picks:\n\ngit tag --contains\n\nI am thinking of having something like:\n\ngit tag --contains-follow\n\nwhich would follow cherry-picks. I am not sure how easily and/or\nefficiently this can be implemented, but my gut feeling is that in the vast\nmajority of the cases, the content check would bail out already at the\n\"subject line\".\n\nAgain, just to recap: I would like to be able to list of releases (i.e.\ntags) in which a commit occurs even if it is cherry-picked because what\nmatters for us in the end of the day is whether the feature or bugfix goes\ninto a release.\n\nBest Regards,\nLaszlo Papp\n"},{"id":"290563","messageId":"20160630062236.GA15380@sigill.intra.peff.net","threadId":"42744","inReplyTo":"CAOMwXhNp9SwA_oQ8bE6-m72C+po+28maGtsP8wRFRfBLjSb5NA@mail.gmail.com","subject":"Re: git tag --contains for cherry-picks","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-06-30T06:22:36Z","receivedAt":"2016-06-30T06:24:20Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jun 29, 2016 at 12:48:33PM +0100, Laszlo Papp wrote:\n\n> Old releases are maintained with important bug fixes or even new features\n> in our case. It sometimes means that we need to cherry-pick commits across\n> branches, like from master to a specific release branch.\n> \n> Cherry-picking changes the hash of the commit, therefore, this may no\n> longer work for cherry-picks:\n> \n> git tag --contains\n> \n> I am thinking of having something like:\n> \n> git tag --contains-follow\n> \n> which would follow cherry-picks. I am not sure how easily and/or\n> efficiently this can be implemented, but my gut feeling is that in the vast\n> majority of the cases, the content check would bail out already at the\n> \"subject line\".\n\nGit generally considers commits \"equivalent\" based on the patch-id, whic\nhis a sha1 of the diff (modulo some canonicalization).\n\nSo you could ask right now for the patch-id of a particular commit:\n\n  git show $commit | git patch-id >needle\n\nand then the patch-id of all tagged commits:\n\n  git log -p --tags | git patch-id | sort >haystack\n\nEach line will have the patch-id followed by the commit id. You can then\ncorrelate them (join is part of GNU coreutils):\n\n  join needle haystack | cut -d' ' -f2- >synonyms\n\nThat gives you a list of synonym commits, which you can use to ask git\nwhich tags contain any of them:\n\n  git tag $(for i in $(cat synonyms); do echo \"--contains $i\"; done)\n\nThe big downside is that generating the haystack is expensive (it has to\ndo a diff on every commit). But if this is something you do a lot, you\ncan save the haystack and incrementally update it with new commits.\n\n\nOf course there are other ways of determining commit equivalence. You\ncould find ones with duplicate commit messages, or duplicate subjects,\nor whatever. But if you have a cherry-picking workflow, I suspect the\neasiest thing may be to simply use \"git cherry-pick -x\", which will\nwrite the sha1 of the original commit into the cherry-picked commit\nmessage. You can then use that to correlate directly.\n\nSo there's no specific \"--contains-follow\" as you want, but the tools\nare there to do it (and more flexibly and efficiently, depending on your\nneeds). That doesn't necessarily mean it's not a good idea to make the\nsimple case easier, though.\n\n-Peff\n"},{"id":"290587","messageId":"5774F747.4000700@gmail.com","threadId":"42744","inReplyTo":"20160630062236.GA15380@sigill.intra.peff.net","subject":"Re: git tag --contains for cherry-picks","fromName":"Jakub Narębski","fromEmail":"jnareb@gmail.com","sentAt":"2016-06-30T10:41:11Z","receivedAt":"2016-06-30T10:41:35Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"W dniu 2016-06-30 o 08:22, Jeff King pisze:\n> On Wed, Jun 29, 2016 at 12:48:33PM +0100, Laszlo Papp wrote:\n> \n>> Old releases are maintained with important bug fixes or even new features\n>> in our case. It sometimes means that we need to cherry-pick commits across\n>> branches, like from master to a specific release branch.\n>>\n>> Cherry-picking changes the hash of the commit, therefore, this may no\n>> longer work for cherry-picks:\n>>\n>> git tag --contains\n>>\n>> I am thinking of having something like:\n>>\n>> git tag --contains-follow\n>>\n>> which would follow cherry-picks. I am not sure how easily and/or\n>> efficiently this can be implemented, but my gut feeling is that in the vast\n>> majority of the cases, the content check would bail out already at the\n>> \"subject line\".\n> \n> Git generally considers commits \"equivalent\" based on the patch-id, whic\n> his a sha1 of the diff (modulo some canonicalization).\n\nThe problem with patch based equivalence is that for cherry-picking\non old release branches you might need to modify a patch for it to\napply - and then patch-id might not detect it.\n\n[...]\n> Of course there are other ways of determining commit equivalence. You\n> could find ones with duplicate commit messages, or duplicate subjects,\n> or whatever. But if you have a cherry-picking workflow, I suspect the\n> easiest thing may be to simply use \"git cherry-pick -x\", which will\n> write the sha1 of the original commit into the cherry-picked commit\n> message. You can then use that to correlate directly.\n\n\"git log --grep=<sha-1>\" would help there (or even match the specific\nmessage that \"git cherry-pick -x\" adds).\n\n-- \nJakub Narębski\n\n"}]}