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 <martinvonz@xxxxxxxxx> wrote: > > > On Wed, Jul 20, 2022, 21:47 Konstantin Ryabitsev <konstantin@xxxxxxxxxxxxxxxxxxx> wrote: >> >> On Mon, Jul 18, 2022 at 02:24:07PM -0700, Glen Choo wrote: >> > > 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. > >> 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@xxxxxxxxx/T/
