Subject: Re: Semantics of change IDs (Re: Gerrit, GitButler, and Jujutsu projects collaborating on change-id commit footer)

From: Junio C Hamano <[email-masked]>
Date: Wed, 14 May 2025 07:38:58 -0700

Martin von Zweigbergk <[email-masked]> writes:

> Sorry, what I meant that those two things (limiting it to 0 or 1
> predecessor and transferring predecessors to the remote) would be
> needed if you want to be able to use the predecessor pointers to infer
> a "change ID" that allows you to do things like `jj describe qx -m
> 'new
> description'; jj new qx`.

If we limit the data model so that it cannot represent one commit
becoming split into two (or vice versa), and instead one old commit
always corresponds to one new commit, our design of convenience
operations may become a lot easier and simpler. No question about
that. I am not sure that is not like a tail wagging a dog, though.
If most use cases are one-to-one without split/merge, then you can
still perform operations that require one-to-one correspondence in
most cases where "predecessor pointer" and "change ID" are moral
equivalents, no?

In any case, that wasn't what I primarily was interested to talk
about.

It sounds like the "change ID" being discussed is a simple and
useful thing that can and should be a commit trailer that is carried
forward automatically across "git commit --amend", "git rebase", and
"git cherry-pick", i.e. those commands that duplicate a new copy, a
refinement, of an existing commit object, without any additional
support from Git proper.  More importantly, unlike the "predecessor"
thing, which may be helped if Git knew that it can optionally affect
reachability, it does not look like it needs any meaning that needs
structural support from Git internals.

So I do appreciate that the wider Git ecosystem like Gerrit and JJ
are talking to adopt "Change ID" with the same syntax and semantics
(if they all can agree, that is), but I do not think it needs to
affect Git at the object level.  From what I have heard so far, it
certainly does not fit in the commit and tag object headers, but
more like the usual trailer thing.