From: "Remo Senekowitsch" <remo@buenzli•dev>
To: "Nico Williams" <nico@cryptonector•com>
Cc: "Elijah Newren" <newren@gmail•com>,
"Martin von Zweigbergk" <martinvonz@google•com>,
"Git Mailing List" <git@vger•kernel.org>,
"Edwin Kempin" <ekempin@google•com>,
"Scott Chacon" <scott@gitbutler•com>,
"philipmetzger@bluewin•ch" <philipmetzger@bluewin•ch>
Subject: Re: Gerrit, GitButler, and Jujutsu projects collaborating on change-id commit footer
Date: Fri, 04 Apr 2025 02:05:13 +0200 [thread overview]
Message-ID: <D8XEYQ9TRB10.L5S89IAC2LZ9@buenzli.dev> (raw)
In-Reply-To: <Z+8GoNrdaJlmNpGm@ubby>
On Fri Apr 4, 2025 at 12:07 AM CEST, Nico Williams wrote:
> On Thu, Apr 03, 2025 at 11:45:55PM +0200, Remo Senekowitsch wrote:
>
> Regardless, all operations that "alter" a commit, such as by cherry-
> picking or rebasing it onto some other commit, should have the same
> defaults and options for preserving/dropping metadata such as "change
> ID".
>
> If I cherry-pick a commit then I absolutely want its "change ID" to be
> preserved by default. If I want to drop that I can always ask for that
> or amend the commit to remove it. I will want the same behavior for
> rebase and cherry-pick. Having to remember different defaults and
> options for the two would be a cognitive load I do not need.
Yeah, that's a very valid argument. In Jujutsus CLI, there is a very
clear separation between "rebase" and "duplicate", so there's no risk
of confusion if one preserves the change-id and the other doesn't. In
Git, the saparation between rebase and cherry-pick is less clear-cut.
Making them behave the same way can be seen as simpler.
>> [...]. The ways rebase and cherry-pick are most often
>> used are semantically very different from each other. (interactive)
>
> How do you know this is "most often" so? [...]
I haven't conducted a study, this is my impression from talking to peers
and reading chatter from other Git users online. Maybe the impression is
wrong.
>> rebase is often used to amend commits that already have descendants. In
>> that case, it makes sense for the change-id to be preserved. cherry-pick
>> on the other hand is often used to create a dublicate of a patch at a
>> different location in the commit tree, e.g. for backporting purposes.
>
> That's not how I use rebase. I rebase to:
>
> - catch up with upstream changes
> - reorder commits
> - combine commits
> - split commits
> - edit commit metadata
> - edit commit contents
Yeah, I was (over-)simplifying. rebase is the swiss-army knife of git
commands. But for all of these operations, it holds that the previous
version of the patch(es) won't be reachable in the commit tree anymore
after the rebase is complete. (assuming potential descendant branches
are also rebased, which is usually the case) So rebase doesn't generally
cause duplicate change-ids, which is what I wanted to get at.
> [...] The whole point of a "change ID" is to let the user notice that
> some set of commits all share the same origin, such as all being a fix
> to the same bug each in a different release (backports). If you're
> backporting bug fixes you'll really want the change IDs to be preserved.
>
> When would you not want to preserve a change ID on cherry-pick? I can't
> say I would ever have wanted to do that had Git had change IDs from day
> 1, and I've been using Git for more than twenty years.
That's not exactly how Jujutsu thinks about the change-id, but it's a
useful piece of information. Gerrit does indeed use its change-id to
track cherry-picks. I am in favor of measures to track that metadata
(although duplicating change-ids is not my preferred option for that).
Let's assume the change-id represents the origin of a patch. What should
happen if a patch is split in two? Should they have the same change-id,
because they ultimately have the same origin? Maybe.
I don't attach too much semantic meaning to the change-id. It's a
normally unique identifier for a change that persists as the change
evolves. That's useful. The more commits with the same change-id as
others there are, the less useful the concept becomes.
>> doesn't preserve the change-id for that reason. So if cherry-pick
>
> I have _never_ used cherry-pick to cause there to be duplicate commits
> in the same branch. Therefore calling it "duplicate" seems terribly
> wrong to me.
Well, obviously not in the same branch. I meant duplicate among all
visible commits (reachable from any branch). That's the issue we're
discussing w.r.t. change-ids not always being unique identifiers for
a single commit. What would you like me to call that siuation instead
of duplicate?
Can you maybe give some examples of how you use cherry-pick? I'd be
interested in your use cases to maybe better understand where you're
coming from. I myself almost never use cherry-pick, simply because I'm
not involved in any backporting. I've seen cherry-pick used to get a
bugfix from another branch onto your own, in order to avoid having to
wait for the other branch to be merged. But that practice has always
rubbed me the wrong way. I feel like the correct thing to do in that
situation is to extract the bugfix to a separate dependency-free branch
and make the two feature branches depend on it. That way, both feature
branches can more easily track changes in the bugfix by rebasing. If the
bugfix was cherry-picked, it's much harder to keep the two versions in
sync. (And finally, the latter approach probably makes the bugfix land
faster.) So yeah, interested to hear your use-cases for cherry-pick.
Remo
next prev parent reply other threads:[~2025-04-04 0:05 UTC|newest]
Thread overview: 118+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-02 18:48 Gerrit, GitButler, and Jujutsu projects collaborating on change-id commit footer Martin von Zweigbergk
2025-04-02 19:34 ` Remo Senekowitsch
2025-04-02 19:49 ` Konstantin Ryabitsev
2025-04-02 19:45 ` Konstantin Ryabitsev
2025-04-02 19:52 ` Martin von Zweigbergk
2025-04-03 9:09 ` Patrick Steinhardt
2025-04-03 10:38 ` Remo Senekowitsch
2025-04-03 11:06 ` Patrick Steinhardt
2025-04-03 15:56 ` Elijah Newren
2025-04-03 16:25 ` Remo Senekowitsch
2025-04-03 16:38 ` Elijah Newren
2025-04-03 21:46 ` Martin von Zweigbergk
2025-04-04 9:41 ` Patrick Steinhardt
2025-04-03 15:39 ` Elijah Newren
2025-04-03 16:40 ` Remo Senekowitsch
2025-04-03 22:11 ` Kane York
2025-04-04 2:28 ` Elijah Newren
2025-04-04 2:40 ` Elijah Newren
2025-04-04 3:47 ` Martin von Zweigbergk
2025-04-04 4:03 ` Nico Williams
2025-04-04 4:59 ` Elijah Newren
2025-04-04 5:21 ` Martin von Zweigbergk
2025-04-04 9:29 ` Patrick Steinhardt
2025-04-03 17:48 ` Theodore Ts'o
2025-04-03 20:31 ` Remo Senekowitsch
2025-04-05 2:09 ` Theodore Ts'o
2025-04-03 18:10 ` Nico Williams
2025-04-03 21:45 ` Remo Senekowitsch
[not found] ` <Z+8GoNrdaJlmNpGm@ubby>
2025-04-04 0:05 ` Remo Senekowitsch [this message]
2025-04-04 3:52 ` Nico Williams
2025-04-04 7:41 ` Remo Senekowitsch
2025-04-04 16:08 ` Nico Williams
2025-04-03 22:05 ` Martin von Zweigbergk
2025-04-03 22:13 ` Nico Williams
2025-04-03 22:47 ` Martin von Zweigbergk
2025-04-04 2:06 ` Elijah Newren
2025-04-04 3:11 ` Nico Williams
2025-04-04 4:08 ` Martin von Zweigbergk
2025-04-04 4:23 ` Nico Williams
2025-04-04 9:34 ` Patrick Steinhardt
2025-04-04 16:04 ` Nico Williams
2025-04-07 8:00 ` Patrick Steinhardt
2025-04-07 20:59 ` Junio C Hamano
2025-04-07 21:36 ` Nico Williams
2025-04-08 12:55 ` Theodore Ts'o
2025-04-08 15:53 ` Nico Williams
2025-04-09 12:19 ` Theodore Ts'o
2025-04-09 12:56 ` Junio C Hamano
2025-04-09 19:13 ` Nico Williams
2025-04-10 8:29 ` Junio C Hamano
2025-04-10 21:40 ` Martin von Zweigbergk
2025-04-09 16:54 ` Semantics of change IDs (Re: Gerrit, GitButler, and Jujutsu projects collaborating on change-id commit footer) Nico Williams
2025-04-09 18:02 ` Junio C Hamano
2025-04-09 18:35 ` Nico Williams
2025-04-09 19:14 ` Eric Sunshine
2025-04-09 19:31 ` Nico Williams
2025-04-10 13:44 ` Theodore Ts'o
2025-04-10 16:18 ` Junio C Hamano
2025-04-11 15:48 ` Theodore Ts'o
2025-04-11 16:38 ` Konstantin Ryabitsev
2025-04-11 17:44 ` Junio C Hamano
2025-04-12 23:13 ` Theodore Ts'o
2025-04-14 15:13 ` Junio C Hamano
2025-04-15 22:30 ` Remo Senekowitsch
2025-04-16 0:09 ` Junio C Hamano
2025-04-16 0:21 ` Jacob Keller
2025-04-15 21:38 ` Jacob Keller
2025-04-14 19:54 ` D. Ben Knoble
2025-04-14 21:34 ` Nico Williams
2025-04-15 21:44 ` Jacob Keller
2025-04-16 11:36 ` Remo Senekowitsch
2025-04-22 20:17 ` D. Ben Knoble
2025-04-22 22:24 ` Remo Senekowitsch
2025-04-22 22:42 ` Junio C Hamano
2025-04-22 22:51 ` Nico Williams
2025-04-22 23:47 ` Remo Senekowitsch
2025-04-23 0:32 ` Nico Williams
2025-04-23 1:15 ` Remo Senekowitsch
2025-04-23 4:45 ` Nico Williams
2025-04-22 23:49 ` Junio C Hamano
2025-04-23 1:02 ` Nico Williams
2025-04-23 4:47 ` Nico Williams
2025-04-22 23:21 ` Remo Senekowitsch
2025-04-23 5:07 ` Martin von Zweigbergk
2025-04-23 15:51 ` Junio C Hamano
2025-04-23 16:19 ` Martin von Zweigbergk
2025-06-06 13:04 ` Toon Claes
[not found] ` <aAgWytQNqtLzg2TU@ubby>
2025-04-23 0:25 ` Remo Senekowitsch
2025-04-23 0:45 ` Nico Williams
2025-04-23 12:58 ` How GitLab does/doesn't need change IDs (was Re: Semantics of change IDs) Toon Claes
2025-04-23 18:59 ` Nico Williams
2025-05-10 19:32 ` Semantics of change IDs (Re: Gerrit, GitButler, and Jujutsu projects collaborating on change-id commit footer) D. Ben Knoble
2025-05-10 19:46 ` D. Ben Knoble
2025-05-10 20:31 ` Martin von Zweigbergk
2025-05-12 17:03 ` Junio C Hamano
2025-05-12 17:19 ` Martin von Zweigbergk
2025-05-14 14:38 ` Junio C Hamano
2025-05-15 10:31 ` Oswald Buddenhagen
2025-05-15 16:32 ` Jacob Keller
2025-05-15 19:59 ` Junio C Hamano
2025-05-15 20:10 ` Nico Williams
[not found] ` <aCJi+4q6DZhnfdy+@ubby>
2025-05-12 21:43 ` Martin von Zweigbergk
2025-05-12 22:04 ` brian m. carlson
2025-06-06 12:28 ` Toon Claes
2025-06-06 15:44 ` Junio C Hamano
2025-05-13 21:22 ` D. Ben Knoble
2025-04-07 22:51 ` Gerrit, GitButler, and Jujutsu projects collaborating on change-id commit footer Remo Senekowitsch
2025-04-08 0:10 ` Junio C Hamano
2025-04-08 5:35 ` Martin von Zweigbergk
2025-04-08 14:27 ` Junio C Hamano
2025-04-08 15:58 ` Phillip Wood
2025-04-08 16:27 ` Nico Williams
2025-04-12 21:32 ` Junio C Hamano
2025-04-16 0:24 ` Jacob Keller
2025-05-14 15:08 ` Kristoffer Haugsbakk
2025-04-08 14:27 ` Junio C Hamano
2025-08-19 14:04 ` Askar Safin
2025-08-19 16:44 ` Ben Knoble
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=D8XEYQ9TRB10.L5S89IAC2LZ9@buenzli.dev \
--to=remo@buenzli$(echo .)dev \
--cc=ekempin@google$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=martinvonz@google$(echo .)com \
--cc=newren@gmail$(echo .)com \
--cc=nico@cryptonector$(echo .)com \
--cc=philipmetzger@bluewin$(echo .)ch \
--cc=scott@gitbutler$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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