From: "Jason Pyeron" <jpyeron@pdinc.us>
To: "'Stephen Finucane'" <stephen@that.guru>,
"'Ævar Arnfjörð Bjarmason'" <avarab@gmail.com>
Cc: <git@vger.kernel.org>
Subject: RE: Feature request: provide a persistent IDs on a commit
Date: Fri, 29 Jul 2022 08:40:38 -0400 [thread overview]
Message-ID: <1f2c01d8a348$68701ba0$395052e0$@pdinc.us> (raw)
In-Reply-To: <bf871a430177ced6d628641eac9d478389fb6c2b.camel@that.guru>
> From: Stephen Finucane
> Sent: Friday, July 29, 2022 8:11 AM
>
> On Tue, 2022-07-19 at 13:09 +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?
> >
> > That send-email have some "pre-send-email" hook? Something else?
>
> (Apologies for the delayed response: I was on holiday).
>
> I'm afraid I don't have the correct terminology to describe what I'm suggesting
> so I'll show an example instead.
>
> I have configured the 'fuller' pretty formatter locally:
>
> $ git config format.pretty
> fuller
>
> When I do git log on e.g. the openstack nova repo, I see:
>
> commit 2709e30956b53be1dca91eec801220f0efbaed93
> Author: Stephen Finucane <sfinucan@redhat.com>
> AuthorDate: Thu Jul 14 15:43:40 2022 +0100
> Commit: Stephen Finucane <sfinucan@redhat.com>
> CommitDate: Mon Jul 18 12:30:25 2022 +0100
>
> Fix compatibility with jsonschema 4.x
>
> This changed one of the error messages we depend on [1].
>
> [1] https://github.com/python-jsonschema/jsonschema/commit/641e9b8c
>
> Change-Id: I643ec568ee2eb2ec1a555f813fd2f1acff915afa
> Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
>
> (Side note: What *is the term for the "Author", "AuthorDate", "Commit" and
> "CommitDate" fields? Commit header? Commit metadata? Something else?)
>
> My thinking is there are two types of information here: information that relates
> to the "commiting" of this change and information that relates to the
> "authorship" of the this change. The commit ID, 'Commit' and 'CommitDate' fields
> clearly form the commit parts. I'm arguing that it would be good to have an
> equivalent to the commit ID field for the authorship-type metadata.
>
> commit 2709e30956b53be1dca91eec801220f0efbaed93
> Author: Stephen Finucane <sfinucan@redhat.com>
> AuthorDate: Thu Jul 14 15:43:40 2022 +0100
> AuthorID: I643ec568ee2eb2ec1a555f813fd2f1acff915afa
> Commit: Stephen Finucane <sfinucan@redhat.com>
> CommitDate: Mon Jul 18 12:30:25 2022 +0100
>
> Fix compatibility with jsonschema 4.x
>
> This changed one of the error messages we depend on [1].
>
> [1] https://github.com/python-jsonschema/jsonschema/commit/641e9b8c
>
> Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
>
> At risk of repeating myself, I think this information would be valuable to allow
> me to answer the question "is this the same[*] commit?". During code review,
> this would allow me to track the evolution of an individual patch. Once a patch
> is merged, it would allow me to track the backporting or cherry-picking of that
We have been toying with this. We are looking at a field (behaves like parent) to track "original commit".
This value would be set on first rebase, amend, cherry-pick, etc.
The bonus for us will be when we patch gerrit to consume it and git log --graph --somenewoption to use it.
It would be nice if git core did add such value.
-Jason
next prev parent reply other threads:[~2022-07-29 12:50 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-18 17:18 Feature request: provide a persistent IDs on a commit Stephen Finucane
2022-07-18 17:35 ` Konstantin Ryabitsev
2022-07-18 19:04 ` Michal Suchánek
2022-07-19 10:57 ` Stephen Finucane
2022-07-18 21:24 ` Glen Choo
2022-07-20 19:21 ` Konstantin Ryabitsev
2022-07-20 19:30 ` Michal Suchánek
2022-07-20 22:10 ` Theodore Ts'o
2022-07-21 11:57 ` Han-Wen Nienhuys
2022-07-24 5:09 ` Elijah Newren
2022-07-18 18:50 ` Ævar Arnfjörð Bjarmason
2022-07-19 10:47 ` Stephen Finucane
2022-07-19 11:09 ` Ævar Arnfjörð Bjarmason
2022-07-19 11:57 ` Michal Suchánek
2022-07-29 12:11 ` Stephen Finucane
2022-07-29 12:40 ` Jason Pyeron [this message]
2022-07-21 16:18 ` Phillip Susi
2022-07-21 18:58 ` Hilco Wijbenga
2022-07-22 20:08 ` Philip Oakley
2022-07-22 20:36 ` Michal Suchánek
2022-07-22 22:46 ` Jacob Keller
2022-07-23 7:00 ` Michal Suchánek
2022-07-24 5:23 ` Elijah Newren
2022-07-24 8:54 ` Michal Suchánek
2022-07-25 21:47 ` Jacob Keller
2022-07-26 3:49 ` Elijah Newren
2022-07-26 8:43 ` Michal Suchánek
2022-07-24 5:10 ` Elijah Newren
2022-07-24 8:59 ` Michal Suchánek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='1f2c01d8a348$68701ba0$395052e0$@pdinc.us' \
--to=jpyeron@pdinc.us \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=stephen@that.guru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).