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 09:41:24 +0200 [thread overview]
Message-ID: <D8XOO0H2GSK0.JQSNCLB1QUQR@buenzli.dev> (raw)
In-Reply-To: <Z+9XfLtodUOvqnse@ubby>
I'll try to join some of our threads and summarize... please correct me
if you disagree with that summary (or I've left something out you think
is important).
One of my points was that rebase usually doesn't lead to multiple
visible commits with the same change-id, whereas cherry-pick usually
does. You pointed out that rebase can in fact lead to multiple visible
commits with the same change-id and cherry-pick sometimes doesn't (and
some of these examples represent valid use cases). So making these two
commands behave in a different way that only makes sense in the "common"
case makes them more complicated - and less consistent - in the general
case. I find this convincing and I now agree that both cherry-pick and
rebase should preserve the change-id by default.
The Gerrit developers will be happy about this anyway, and it's worth
repeating that Jujutsu can deal with it perfectly fine while preserving
almost all benefits of change-ids.
When discussing the uniqueness of change-ids or lack thereof, I'd
like to introduce one more factor: At which point in time during the
development cycle a change-id is unique. Jujutsu users derive most
of the benefits of change-ids during active development. The use case
you find most important - tracking (forward- and) back-ports - happens
at a different time during development, when a change has been merged
to a public branch already. So I think there is no conflict at all.
Change-ids will naturally tend to be unique during active development
and once they are merged, whether the change-id stays unique or not
doesn't matter anymore for those active development use cases. We can
have our cake and eat it too.
Remo
next prev parent reply other threads:[~2025-04-04 7:41 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
2025-04-04 3:52 ` Nico Williams
2025-04-04 7:41 ` Remo Senekowitsch [this message]
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=D8XOO0H2GSK0.JQSNCLB1QUQR@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