From: "Remo Senekowitsch" <remo@buenzli•dev>
To: "D. Ben Knoble" <ben.knoble@gmail•com>,
"Nico Williams" <nico@cryptonector•com>
Cc: "Theodore Ts'o" <tytso@mit•edu>,
"Junio C Hamano" <gitster@pobox•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: Semantics of change IDs (Re: Gerrit, GitButler, and Jujutsu projects collaborating on change-id commit footer)
Date: Wed, 16 Apr 2025 13:36:26 +0200 [thread overview]
Message-ID: <D9816I5AX1RG.AA4A7H2D8SJ7@buenzli.dev> (raw)
In-Reply-To: <CALnO6CC_Gvqhcxp4AknwM+YSsngv_0zngKb2XHXN4u0AvKEMMg@mail.gmail.com>
On Mon Apr 14, 2025 at 9:54 PM CEST, D. Ben Knoble wrote:
> On Wed, Apr 9, 2025 at 12:56 PM Nico Williams <nico@cryptonector•com> wrote:
>> Let's nail down the semantics of these change ID headers. Here is a
>> proposal to bang on:
>>
>> - change IDs get preserved on cherry-pick and on `pick`s in rebases
>>
>> - users can manually remove or change these change IDs, naturally,
>> though generall they would not
>>
>> - the actual change IDs are either free-form or they are URIs -- pick
>> one, but if they are URIs they should be URIs to CRs, and approved
>> CRs should perhaps have links to integration reports etc.
>
> Using URIs [to code reviews] looks to me like it makes some
> assumptions about what creates or consumes these headers, right?
> Especially since the URI should point to a code review… Is there a way
> to do that which is downstream-agnostic?
>
> Further, and maybe this is my ignorance of Gerrit showing: how would
> you attach a URI to a local commit when authoring it? You don't have
> the review URI when running `git commit`, do you? (Maybe I
> misunderstood; I'm seeing an odd chicken-egg problem here.)
>
> Which begs another question: what/who applies the initial change ID to
> a commit and when?
These are all great questions, which the originally proposed format
(fixed-width reverse-hex) has answers to. I think a URI would be
strictly worse.
* Using a reverse-hex ID makes no assumptions about what consumes these
headers. There can be multiple different consumers which treat the ID
differently with different URI schemes.
* Attaching a reverse-hex ID to a local commit when authoring it is
trivial: you generate it randomly.
This is one of those cases where being maximally restrictive about the
format will enable maximal flexibility downstream.
One example: GitHub has a URL scheme that looks like this:
github.com/org/repo/compare/<ref1>..<ref2>
This doesn't work if the refs contain slashes, as branches sometimes do
(e.g. feat/foo, username/bar). If the change-id is a URI, this type of
URL scheme doesn't work reliably.
That is not to say we should design the change-id around GitHub, it's
just an example how making the format more free-form (URI is more
free-form than fixed-width reverse-hex) makes it more difficult to get
stuff working downstream.
And lastly, laser-etching the URI scheme of one particular tool into
your commit history means the history is at great risk of degrading
over time. URI schemes change, domains change, tools become outdated
and are replaced.
Adding some ephemeral configuration to a tool that constructs a URI out
of a reverse-hex ID on the other hand is trivial.
> PS This discussion feels somewhat related to the classic GitHub
> problem of not presenting interdiffs/range-diffs: GitHub shows a
> too-flat source diff on force-pushes. Perhaps better web UI tooling
> about interdiff review (which I think is one of the things Gerrit
> does/wants to do?) makes change IDs less necessary, since interdiffs
> help connect evolutions of commits?
I think it's the other way around: Building a code review UI built on
git and centered around interdiffs today is _hard_, that's why we don't
have it yet. Adding change-ids to commits will make it much easier,
paving the way for these tools to be implemented.
Remo
next prev parent reply other threads:[~2025-04-16 11:36 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
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 [this message]
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=D9816I5AX1RG.AA4A7H2D8SJ7@buenzli.dev \
--to=remo@buenzli$(echo .)dev \
--cc=ben.knoble@gmail$(echo .)com \
--cc=ekempin@google$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=martinvonz@google$(echo .)com \
--cc=nico@cryptonector$(echo .)com \
--cc=philipmetzger@bluewin$(echo .)ch \
--cc=scott@gitbutler$(echo .)com \
--cc=tytso@mit$(echo .)edu \
/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