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
