From: Junio C Hamano <gitster@pobox.com>
To: "Sean Allred via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, Sean Allred <code@seanallred.com>,
Sean Allred <allred.sean@gmail.com>
Subject: Re: [PATCH v2] cherry-pick: use trailer instead of free-text for `-x`
Date: Sun, 04 Jun 2023 13:32:05 +0900 [thread overview]
Message-ID: <xmqqfs776e62.fsf@gitster.g> (raw)
In-Reply-To: <pull.1519.v2.git.git.1685816463240.gitgitgadget@gmail.com> (Sean Allred via GitGitGadget's message of "Sat, 03 Jun 2023 18:21:03 +0000")
"Sean Allred via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: Sean Allred <allred.sean@gmail.com>
>
> When recording the origin commit during a cherry-pick, the current label
> used is not understood by git-interpret-trailers. Standardize onto the
> 'normal' trailer format that can be reasonably/reliably parsed and used
> by external tooling leveraging git-interpret-trailers.
I am somewhat negative on going in this direction, as we originally
added these "cherry-picked-from" by default, but stopped doing so
for a reason [*1*]. I'd be hesitant to see us spend any engineering
resources on a feature we discourage (not even to deprecate and to
remove). It is a different story if we change the previous stance
on the "cherry-picked-from" information, though.
I admit I've suggested "Cherry-picked-from:" long time ago [*2*], as
an aside in a discussion, but the discussion was more about treating
the line as a very distinct thing that is different from any other
"trailer" lines. The last time this was brought up, I thought that
it was deemed unnecessary because interpret-trailer code already
understood by the trailer code [*3*], and we _could_ teach the
interpret-trailer code to rewrite it to "Cherry-picked-from:". Any
renewed efforts should build on the discussion there, addressing
points raised during the discussion, I think.
Thanks.
[Footnotes and references]
*1* Unlike "revert", "cherry-pick" is done from an unrelated and
often not even published history, and referring to such a commit
that the end-user cannot do "git show" does not add much value
to the history.
*2* https://lore.kernel.org/git/xmqqtwcycqul.fsf@gitster.mtv.corp.google.com/
*3* https://lore.kernel.org/git/20181106221118.GA9975@sigill.intra.peff.net/
prev parent reply other threads:[~2023-06-04 4:32 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-03 17:56 [PATCH] cherry-pick: use trailer instead of free-text for `-x` Sean Allred via GitGitGadget
2023-06-03 18:21 ` [PATCH v2] " Sean Allred via GitGitGadget
2023-06-04 4:32 ` Junio C Hamano [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqfs776e62.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=allred.sean@gmail.com \
--cc=code@seanallred.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.