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

["Michal Suchánek" <msuchanek@suse.de>]

On Tue, Jul 19, 2022 at 01:09:02PM +0200, Ævar Arnfjörð Bjarmason wrote:
> 
> On Tue, Jul 19 2022, Stephen Finucane wrote:
> 
> > On Mon, 2022-07-18 at 20:50 +0200, Ævar Arnfjörð Bjarmason wrote:
> >> On Mon, Jul 18 2022, Stephen Finucane wrote:
> >> 
> >> > ...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?
> >
> > It supports sending the trailers, sure. What it doesn't support is insisting you
> > send this specific trailer (Change-Id). Only Gerrit can do this (server side,
> > thankfully, which means you don't need to ask all contributors to install this
> > hook if you want to rely on it for tooling, CI, etc.).
> 
> Ah, it's still unclear to me what you're proposing here though. That
> send-email always (generates?) or otherwise insists on the trailer, that
> it can be configured ot add it?

And isn't send-email time too late?

That would mean that you get new ID for every version of the patch sent.

Thanks

Michal