{"thread":{"id":"62420","subject":"`cherry-pick -x' and git-interpret-trailers","startedAt":"2024-10-28T18:43:57Z","lastAt":"2024-10-28T21:19:13Z","messageCount":2,"participants":["Nicholas Sielicki","Kristoffer Haugsbakk"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"506242","messageId":"ab71a27d-728e-425a-8729-8699c9369bca@app.fastmail.com","threadId":"62420","inReplyTo":null,"subject":"`cherry-pick -x' and git-interpret-trailers","fromName":"Nicholas Sielicki","fromEmail":"vger+git@opensource.nslick.com","sentAt":"2024-10-28T18:43:35Z","receivedAt":"2024-10-28T18:43:57Z","isPatch":false,"sender":{"key":"vger+git@opensource.nslick.com","avatar":null},"body":"If one uses `git cherry-pick -x' to apply a commit to a stable branch\nfrom elsewhere, git appends something like:\n\n> Tested-by: Some Teammate <some.teammate@somedomain.com>\n> Signed-off-by: Some User <some.user@somedomain.com>\n> (cherry picked from commit 2efe13923d0ff714b1b0f3b7175e714f0e295727) <--- this\n\nIMO this is inconsistent in two ways:\n\n1. it's unclear to me why the cherry-pick metadata isn't emitted in\ntrailer form, ie: `Cherry-Picked-From-Commit: <...>', making it work\nwith `git-interpret-trailers'.\n\n2. I'm not sure if any tooling (external or otherwise) breaks because\nof this, but the existing trailers now have non-trailer content\nfollowing them, so it's ambiguous whether they still qualify as\ntrailers at first glance. (possibly, this is intentional?)\n\nRealistically, the only thing worse than this^ would be to have a\nmixture of two formats in the same repository, which is to say,\nwithout a surefire way to to share repository config defaults, I can't\nimagine there's a backwards-compatible solution to changing the `-x'\ndefault behavior and git is stuck with it.\n\nIt could be possible to extend the existing behavior with git-notes?\nAdded benefit of that would be that you could mark both commits\ninvolved with `Cherry-Picked-By' and `Cherry-Picked-From'.\n"},{"id":"506263","messageId":"c6f58024-45f5-4012-87a4-6b86ab2cd31b@app.fastmail.com","threadId":"62420","inReplyTo":"ab71a27d-728e-425a-8729-8699c9369bca@app.fastmail.com","subject":"Re: `cherry-pick -x' and git-interpret-trailers","fromName":"Kristoffer Haugsbakk","fromEmail":"kristofferhaugsbakk@fastmail.com","sentAt":"2024-10-28T21:18:44Z","receivedAt":"2024-10-28T21:19:13Z","isPatch":false,"sender":{"key":"kristofferhaugsbakk@fastmail.com","avatar":null},"body":"On Mon, Oct 28, 2024, at 19:43, Nicholas Sielicki wrote:\n> If one uses `git cherry-pick -x' to apply a commit to a stable branch\n> from elsewhere, git appends something like:\n>\n>> Tested-by: Some Teammate <some.teammate@somedomain.com>\n>> Signed-off-by: Some User <some.user@somedomain.com>\n>> (cherry picked from commit 2efe13923d0ff714b1b0f3b7175e714f0e295727) <--- this\n>\n> IMO this is inconsistent in two ways:\n>\n> 1. it's unclear to me why the cherry-pick metadata isn't emitted in\n> trailer form, ie: `Cherry-Picked-From-Commit: <...>', making it work\n> with `git-interpret-trailers'.\n\nI agree that would be better.  Modulo history and backwards\ncompatibility concerns.\n\n> 2. I'm not sure if any tooling (external or otherwise) breaks because\n> of this, but the existing trailers now have non-trailer content\n> following them, so it's ambiguous whether they still qualify as\n> trailers at first glance. (possibly, this is intentional?)\n\nThey still qualify.  See git-interpret-trailers(1)\n\n  “ Existing trailers are extracted from the input by looking for a\n    group of one or more lines that (i) is all trailers, or (ii)\n    contains at least one Git-generated or user-configured trailer and\n    consists of at least 25% trailers.\n\nThat example would work even if you only had one existing trailer (50%\nat the end).\n\nI don’t know what the significance of “user-configured” is here.  I\ndeleted all my configuration and tested with something made up and `git\ninterpret-trailers --parse`.  Those novel-looking trailers still got\noutput as trailers when placed before a cherry-pick line.\n\n> Realistically, the only thing worse than this^ would be to have a\n> mixture of two formats in the same repository, which is to say,\n> without a surefire way to to share repository config defaults, I can't\n> imagine there's a backwards-compatible solution to changing the `-x'\n> default behavior and git is stuck with it.\n\nMake a new option?  Like `--trailer`?\n\n> It could be possible to extend the existing behavior with git-notes?\n> Added benefit of that would be that you could mark both commits\n> involved with `Cherry-Picked-By' and `Cherry-Picked-From'.\n\nWhy Notes?  A trailer (a proper one) seems more straightforward.\n\nThere was a “crossreference” patch series from 2018:\n\nhttps://lore.kernel.org/git/20181211234909.2855638-1-tj@kernel.org/\n\n❦\n\nYou could emulate something like `git cherry-pick --trailer`:\n\n```\n#!/bin/sh\n# arg 1: commit\nset -u\n$ git config trailer.cherry.key Cherry-picked-from\n$ cat script\n#!/bin/sh\n\ngit showref \"$1\"\n$ git config trailer.cherry.cmd ./script\n$ git cherry-pick \"$1\" &&\n$ git commit --trailer=\"cherry: $1\" \\\n    --amend --no-edit\n```\n"}]}