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

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Jul 18, 2022, 18:50 UTC
Message-ID: <220718.86ilnuw8jo.gmgdl@evledraar.gmail.com>
In-Reply-To: <bdbe9b7c1123f70c0b4325d778af1df8fea2bb1b.camel@that.guru>

On Mon, Jul 18 2022, Stephen Finucane wrote:

Show 27 quoted lines

> ...to track evolution of a patch through time.
>
> tl;dr: How hard would it be to retrofit an 'ChangeID' concept à la the 'Change-
> ID' trailer used by Gerrit into git core?
>
> Firstly, apologies in advance if this is the wrong forum to post a feature
> request. I help maintain the Patchwork project [1], which a web-based tool that
> provides a mechanism to track the state of patches submitted to a mailing list
> and make sure stuff doesn't slip through the crack. One of our long-term goals
> has been to track the evolution of an individual patch through multiple
> revisions. This is surprisingly hard goal because oftentimes there isn't a whole
> lot to work with. One can try to guess whether things are the same by inspecting
> the metadata of the commit (subject, author, commit message, and the diff
> itself) but each of these metadata items are subject to arbitrary changes and
> are therefore fallible.
>
> One of the mechanisms I've seen used to address this is the 'Change-ID' trailer
> used by Gerrit. For anyone that hasn't seen this, the Gerrit server provides a
> git commit hook that you can install locally. When installed, this appends a
> 'Change-ID' trailer to each and every commit message. In this way, the evolution
> of a patch (or a "change", in Gerrit parlance) can be tracked through time since
> the Change ID provides an authoritative answer to the question "is this still
> the same patch". Unfortunately, there are still some obvious downside to this
> approach. Not only does this additional trailer clutter your commit messages but
> it's also something the user must install themselves. While Gerrit can insist
> that this is installed before pushing a change, this isn't an option for any of
> the common forges nor is it something git-send-email supports.

git format-patch+send-email will send your trailers along as-is, how doesn't it support Change-Id. Does it need some support that any other made-up trailer doesn't?

> I imagine most people working with mailing list based workflows have their own
> client side tooling to support this while software forges like GitHub and GitLab
> simply don't bother tracking version history between individual commits in a
> pull/merge request.

It's far from ideal, but at least GitLab shows a diff on a push to a MR, including if it's force-pushed. I'm not sure about GitHub.

Show 9 quoted lines

> IMO though, it would be fantastic if third party tools
> weren't necessary though. What I suspect we want is a persistent ID (or rather
> UUID) that never changes regardless of how many times a patch is cherry-picked,
> rebased, or otherwise modified, similar to the Author and AuthorDate fields.
> Like Author and AuthorDate, it would be part of the core git commit metadata
> rather than something in the commit message like Signed-Off-By or Change-ID.
>
> Has such an idea ever been explored? Is it even possible? Would it be broadly
> useful?

This has come up a bunch of times. I think that the thing git itself should be doing is to lean into the same notion that we use for tracking renames. I.e. we don't, we analyze history after-the-fact and spot the renames for you.

We have some of that in git already, as git-patch-id, and more recently git-range-diff. Both are flawed in a bunch of ways, and it's easy to run into edge cases where they don't spot something that they "should" have. Where "should" exists in the mind of the user.