Re: Feature request: provide a persistent IDs on a commit

I just noticed that my message from almost 2.5 years ago got blocked
by the HTML filter, so here's a very late reply. I'd like to continue
this discussion, but maybe I'll start a separate thread later if you
prefer.

On Wed, Jul 27, 2022 at 1:26 AM Martin von Zweigbergk
[off-list ref] wrote:

On Wed, Jul 20, 2022, 21:47 Konstantin Ryabitsev [off-list ref] wrote:

quoted

On Mon, Jul 18, 2022 at 02:24:07PM -0700, Glen Choo wrote:

quoted

quoted

I just started working on this for b4, with the notable difference that the
change-id trailer is used in the cover letter instead of in individual
commits, which moves the concept of "change" from a single commit to a series
of commits. IMO, it's much more useful in that scope, because as series are
reviewed and iterated, individual patches can get squashed, split up or
otherwise transformed.

My 2 cents, since I used to use Gerrit a lot :)

I find persistent per-commit ids really useful, even when patches get
moved around. E.g. Gerrit can show and diff previous versions of the
patch, which makes it really easy to tell how the patch has evolved
over time.

The kernel community has repeatedly rejected per-patch Change-id trailers
because they carry no meaningful information outside of the gerrit system on
which they were created.

Since I didn't see a mention of it yet in this thread, I thought I'd point of some possible ways that Git itself could use a change ID:

* By allowing change IDs to be used for specifying a commit, you could do e.g. `git rebase main <change ID>; git checkout <change ID>` without requiring the user to look up the hash of the rewritten commit.
* Can be used for identifying rewritten commits that still have descendants (because you would have multiple reachable commits with the same change ID). That could be used for suggesting which descendants to rebase to where (a bit like Mercurial's `hg evolve`).
* Can be used by `git rebase` for skipping commits that are already in the destination.
* Can be used by `git cherry` for identifying commits that have been rebased. However, for `git cherry-pick`, we'd have to decide if we want to keep the change ID or generate a new one. We would not want to reuse the change ID if we consider multiple reachable commits with the same change ID a (soft) error.

quoted

Seeing a Change-Id trailer in a commit tells you
nothing about the history of that commit unless you know the gerrit system on
which this patch was reviewed (and have access to it, which is not a given).
This is not as opaque as it used to be now that Gerrit provided ability to
clone the underlying notedb, but this still fails on commits that were
contributed to an upstream that doesn't use Gerrit.

Yes, that's a good point. There's the old "git evolve" proposal [1] that may be a good solution for the problem of tracking rewrites across multi-remote exchanges.

[1] https://public-inbox.org/git/86d0spzoi1.fsf@gmail.com/T/