Git development
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Nico Williams <nico@cryptonector.com>
Cc: Matt Stark <msta@google.com>,
	 git@vger.kernel.org,  ps@pks.im, phillip.wood@dunelm.org.uk,
	 Martin von Zweigbergk <martinvonz@google.com>,
	 remo@buenzli.dev,  Edwin Kempin <ekempin@google.com>,
	 schacon@gmail.com,  philipmetzger@bluewin.ch,
	konstantin@linuxfoundation.org,  newren@gmail.com,
	 tytso@mit.edu, rikingcoding@gmail.com
Subject: Re: [PATCH] headers: Preserve 'change-id' header in rebase / cherry-pick.
Date: Tue, 07 Apr 2026 07:42:05 -0700	[thread overview]
Message-ID: <xmqqcy0a7rya.fsf@gitster.g> (raw)
In-Reply-To: <adSO6zPwtFOWBcOw@ubby> (Nico Williams's message of "Mon, 6 Apr 2026 23:58:19 -0500")

Nico Williams <nico@cryptonector.com> writes:

>> Format is one thing, but what it means is much more important.  When
>> is it inherited?  What happens when you split a single commit into
>> three pieces, which piece, if any, among the resulting three will
>> inherit thee parent's?  Should rebase, cherry-pick, and replay
>> behave the same way (IIRC, rebase and cherry-pick behaves
>> differently while propagating notes).  Etc., etc.
>
> Exactly.  I remember I argued that cherry-pick and rebase should have
> the same behavior given that rebase is logically a script of
> cherry-picks, but others had strong arguments that the two should not
> have the same behavior (something which is not hard to implement if you
> make the inherittance / non-inherittance an option to cherry-pick has
> different defaults for cherry-pick than for rebase).

Yes.  Even though I often feel irritated when I use cherry-pick and
see the "amlog" note not propagate when I should have used rebase, I
think it makes sense to allow cherry-pick and rebase to behavve
differently.  This is because rebase is a rewriting operation, where
the old incarnation of the topic is discarded (other than that it
can be resurrected from the reflog of the branch for the topic) and
only the new incarnation will stay in the history, while cherry-pick
is a duplicating operation, where the new copy is an adaptation of
the original commit into a different context and both of them will
stay in the history serving different purpose.

> That the value of this header should not have a format imposed -- that
> much is certainly the case as far as consensus goes, I think.  Basically
> it should be site-local, for some definition of site.  But the tooling
> can just treat it as opaque, perhaps with hooks to do any interpretation
> of those values.

And there is nothing to prevent us from doing all of the above (and
more) with trailers.  The existing interpret-trailers mechanism may
be lacking, but hopefully it gives enough framework to build on top
to allow projects to customize what they want them to mean and how
they behave.

  parent reply	other threads:[~2026-04-07 14:42 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-07  3:13 [PATCH] headers: Preserve 'change-id' header in rebase / cherry-pick Matt Stark
2026-04-07  4:09 ` Junio C Hamano
2026-04-07  4:58   ` Nico Williams
2026-04-07  5:02     ` Nico Williams
2026-04-07 14:33       ` Junio C Hamano
2026-04-07  9:55     ` Phillip Wood
2026-04-07 15:52       ` Nico Williams
2026-04-07 16:20         ` Junio C Hamano
2026-04-07 20:13           ` Nico Williams
2026-04-07 14:42     ` Junio C Hamano [this message]
2026-04-07  9:41   ` Phillip Wood
2026-04-07 23:28 ` brian m. carlson

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=xmqqcy0a7rya.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=ekempin@google.com \
    --cc=git@vger.kernel.org \
    --cc=konstantin@linuxfoundation.org \
    --cc=martinvonz@google.com \
    --cc=msta@google.com \
    --cc=newren@gmail.com \
    --cc=nico@cryptonector.com \
    --cc=philipmetzger@bluewin.ch \
    --cc=phillip.wood@dunelm.org.uk \
    --cc=ps@pks.im \
    --cc=remo@buenzli.dev \
    --cc=rikingcoding@gmail.com \
    --cc=schacon@gmail.com \
    --cc=tytso@mit.edu \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox