Re: Gerrit, GitButler, and Jujutsu projects collaborating on change-id commit footer

[Junio C Hamano <gitster@pobox.com>]

Martin von Zweigbergk <martinvonz@google.com> writes:

> For example, it enables
> `git rebase main <change ID>; git switch <change ID>` without
> requiring the user to look up the hash of the rewritten commit.

I do not quite see why this can be listed even as an advantage,
unless you are going to allow end users to name the changes, instead
of using auto-generated impossible-to-remember hexadecimal string
(perhaps prefixed with a single "I" or something).

> If the change id also transferred between repos and preserved by
> a forge (such as Gerrit), it enables the change id to be used to
> identify a code review.

People often talk about rebasing and rewriting in the context of
discussing "change IDs", and for 80% of the use cases where a simple
single-commit topic is involved, it would perfectly work fine.
After making a new commit C0 on top of 'main', updating 'main' with
others' changes, and then rebasing that C0 on top of updated 'main'
to produce C1, you would expect that C0 and C1 are moral equivalents
so it is natural that you wish there is a name to give to these
moral equivalents.

But stepping back a bit, if they are not just moral equivalents but
record identical changes that are so same that an earlier review of
C0 makes it unnecessary to review C1, why are you even rebasing in
the first place?  Just merging C0 to the updated 'main' would retain
the earlier review made on C0 and things should merge just fine.

I have more problems with the remaining 20% use case, where you need
to deal with multiple commits.

Perhaps your initial changeset is a single commit C0 that is so
large and does too many things at once, and reviewers would
naturally advise you to split things up.  You'll come up with a
series of commits, C1_0 and C1_1.  The net effect of applying these
two patches may be the same as applying the original C0, but each of
them is more cleanly separated to address one issue at a time, and
the explanation given in the proposed log message more clearly
describes the issue each of them addresses.  Now you gave a change ID
to C0, and want to somehow relate C1_0 and C1_1 to the original C0.
Which one gets the same change ID?  Earlier one?  The last one?
Both gets the same change ID?

Or your initial changeset is a two-commit series, C0_0 and C0_1, but
reviewers find that each one of them alone is not complete, and
because the issue addressed by these two is small and isolated
enough, you are advised to make them into a single commit C1.  Did
you start with two change IDs for these two original commits?  If
so, whose change ID the updated commit C1 inherit?  Or does C1 have
two change IDs now?  Or did you start with a single change ID
assigned to both of these two original commits?

Quite frankly, I think the concept of "change ID" is nice but it is
not mechanically trustable.  Recording them in the trailers is fine,
but I somehow feel that they have a clear-cut semantics everybody
can agree on to deserve to be in the header part of commit objects.