git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Nico Williams <nico@cryptonector.com>
Cc: Junio C Hamano <gitster@pobox.com>,
	Martin von Zweigbergk <martinvonz@google.com>,
	Git Mailing List <git@vger.kernel.org>,
	Edwin Kempin <ekempin@google.com>,
	Scott Chacon <scott@gitbutler.com>,
	remo@buenzli.dev,
	"philipmetzger@bluewin.ch" <philipmetzger@bluewin.ch>
Subject: Re: Gerrit, GitButler, and Jujutsu projects collaborating on change-id commit footer
Date: Tue, 8 Apr 2025 08:55:21 -0400	[thread overview]
Message-ID: <20250408125521.GA17892@mit.edu> (raw)
In-Reply-To: <Z/RFQY433muaCW44@ubby>

On Mon, Apr 07, 2025 at 04:36:01PM -0500, Nico Williams wrote:
> This is why I suggested earlier that there need to be multiple change
> IDs, not just one.  Perhaps one is a "code review ID" and another is
> a "commit change ID".  The code review ID would let you link together
> all commits that were reviewed together, so if you have to split or
> squash commits they would all still have that one code review ID.  The
> commit change ID would be shared by all sufficiently-similar versions of
> a commit.  If a commit is dropped or split or squashed then its commit
> ID might get dropped too, but the code review ID would stay the same.

I think "code review ID" makes a lot of sense, although what I would
call it is "patch series ID".  This has very clear semantic: it ties
commits which should be grouped together as a single higher-level set
of changes.  It could be used by "git format-patch" / "git send-email"
to automatically send a group of patches as a logical unit.

I'd include the "patch series ID" in the e-mail that gets sent out, so
that "git apply-message" would be able to retain the patch series ID.
Patchwork could use the Patch series ID to automatically mark a v2
version of patch series as obsoleting the v1 version of the patch
series.  So it would be a lot more useful for than just for
Gerrit-style workflows, and that's a good sign that feature makes
sense from a design perspective.

I'll note that even without the "commit change ID", just simply
knowing that one patch series is a newer version of a pre-existing
patch series is enough to allow Gerrit to intuit which commit is a
newer version of another commit.  For singleton commits, nothing else
is necessary.  For multi-commit patch series, gerrit could use the
one-line commit description to associate commits; it could use
ordering of the patches; it could just see which commit contents are
similar to previous commits, much like how git detects renames.

In my experience looking at how kernel developers use gerrit versus
e-mail workflows, in general, gerrit patch series tend to involve a
smaller number of commits, because looking at how various files change
between commtis is awkward; and with e-mail workflows, the patch
series tend involve a larger number of commits, because reviewing
smaller commits is easier with e-mail.

So if this true for other communities using web-based review
workflows, using an hueristics instead of a "commit change ID" might
be sufficient --- and for those communities that run into problems,
they could continue to use a gerrit-style "Change-ID: " in the footer,
with the hueristics being used if for some reason commits that don't
have the Change-ID make it into Gerrit.

> > Quite frankly, I think the concept of "change ID" is nice but it is
> > not mechanically trustable.  Recording them in the trailers is fine,
> > but I somehow feel that they have a clear-cut semantics everybody
> > can agree on to deserve to be in the header part of commit objects.
> 
> I don't think they need to have such extremely detailed semantics in
> order to be able to get a header.  The semantics will ultimately be
> somewhat project-defined, typically something like "during code review
> you can use these to related newer updates to an MR/PR/CR to older
> versions" and "once integrated you can use these to find the approved
> code review as follows [details]".  The [details] (probably a URI
> template) for finding concluded CRs might vary.  The CR tool might vary.
> The construction of the change IDs might vary.  The intent might not
> vary at all.

I disagree.  From long experience, allowing something into an
interface that doesn't have strongly defined semantics has lead to
*huge* problems.  This has certainly been the case for
Kernel<->Userspace interfaces; so my bias is that if we can't define
strong semantics, then we should probably avoid adding that interface
until we can.  Otherwise, this can lead to a huge number of headaches,
both for developers and users.

People *will* develop automation tools suing an official "commit
change ID", assuming that how their project (or their forge site) uses
the ill-defined Change ID is the One True Way that the badly defined
field should be used.  And other people will developer *other* tools
assuming some other interpreation for that field.  And then the git
developers and users will be left trying to pick up the pieces.

Cheers,

						- Ted

  reply	other threads:[~2025-04-08 12:57 UTC|newest]

Thread overview: 118+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-02 18:48 Gerrit, GitButler, and Jujutsu projects collaborating on change-id commit footer Martin von Zweigbergk
2025-04-02 19:34 ` Remo Senekowitsch
2025-04-02 19:49   ` Konstantin Ryabitsev
2025-04-02 19:45 ` Konstantin Ryabitsev
2025-04-02 19:52 ` Martin von Zweigbergk
2025-04-03  9:09 ` Patrick Steinhardt
2025-04-03 10:38   ` Remo Senekowitsch
2025-04-03 11:06     ` Patrick Steinhardt
2025-04-03 15:56   ` Elijah Newren
2025-04-03 16:25     ` Remo Senekowitsch
2025-04-03 16:38       ` Elijah Newren
2025-04-03 21:46         ` Martin von Zweigbergk
2025-04-04  9:41     ` Patrick Steinhardt
2025-04-03 15:39 ` Elijah Newren
2025-04-03 16:40   ` Remo Senekowitsch
2025-04-03 22:11     ` Kane York
2025-04-04  2:28     ` Elijah Newren
2025-04-04  2:40       ` Elijah Newren
2025-04-04  3:47         ` Martin von Zweigbergk
2025-04-04  4:03           ` Nico Williams
2025-04-04  4:59           ` Elijah Newren
2025-04-04  5:21             ` Martin von Zweigbergk
2025-04-04  9:29               ` Patrick Steinhardt
2025-04-03 17:48   ` Theodore Ts'o
2025-04-03 20:31     ` Remo Senekowitsch
2025-04-05  2:09       ` Theodore Ts'o
2025-04-03 18:10   ` Nico Williams
2025-04-03 21:45     ` Remo Senekowitsch
     [not found]       ` <Z+8GoNrdaJlmNpGm@ubby>
2025-04-04  0:05         ` Remo Senekowitsch
2025-04-04  3:52           ` Nico Williams
2025-04-04  7:41             ` Remo Senekowitsch
2025-04-04 16:08               ` Nico Williams
2025-04-03 22:05     ` Martin von Zweigbergk
2025-04-03 22:13       ` Nico Williams
2025-04-03 22:47         ` Martin von Zweigbergk
2025-04-04  2:06           ` Elijah Newren
2025-04-04  3:11           ` Nico Williams
2025-04-04  4:08             ` Martin von Zweigbergk
2025-04-04  4:23               ` Nico Williams
2025-04-04  9:34                 ` Patrick Steinhardt
2025-04-04 16:04                   ` Nico Williams
2025-04-07  8:00                     ` Patrick Steinhardt
2025-04-07 20:59 ` Junio C Hamano
2025-04-07 21:36   ` Nico Williams
2025-04-08 12:55     ` Theodore Ts'o [this message]
2025-04-08 15:53       ` Nico Williams
2025-04-09 12:19         ` Theodore Ts'o
2025-04-09 12:56           ` Junio C Hamano
2025-04-09 19:13             ` Nico Williams
2025-04-10  8:29               ` Junio C Hamano
2025-04-10 21:40                 ` Martin von Zweigbergk
2025-04-09 16:54           ` Semantics of change IDs (Re: Gerrit, GitButler, and Jujutsu projects collaborating on change-id commit footer) Nico Williams
2025-04-09 18:02             ` Junio C Hamano
2025-04-09 18:35               ` Nico Williams
2025-04-09 19:14                 ` Eric Sunshine
2025-04-09 19:31                   ` Nico Williams
2025-04-10 13:44                 ` Theodore Ts'o
2025-04-10 16:18                   ` Junio C Hamano
2025-04-11 15:48                     ` Theodore Ts'o
2025-04-11 16:38                       ` Konstantin Ryabitsev
2025-04-11 17:44                       ` Junio C Hamano
2025-04-12 23:13                         ` Theodore Ts'o
2025-04-14 15:13                           ` Junio C Hamano
2025-04-15 22:30                             ` Remo Senekowitsch
2025-04-16  0:09                               ` Junio C Hamano
2025-04-16  0:21                               ` Jacob Keller
2025-04-15 21:38                           ` Jacob Keller
2025-04-14 19:54             ` D. Ben Knoble
2025-04-14 21:34               ` Nico Williams
2025-04-15 21:44               ` Jacob Keller
2025-04-16 11:36               ` Remo Senekowitsch
2025-04-22 20:17                 ` D. Ben Knoble
2025-04-22 22:24                   ` Remo Senekowitsch
2025-04-22 22:42                     ` Junio C Hamano
2025-04-22 22:51                       ` Nico Williams
2025-04-22 23:47                         ` Remo Senekowitsch
2025-04-23  0:32                           ` Nico Williams
2025-04-23  1:15                             ` Remo Senekowitsch
2025-04-23  4:45                               ` Nico Williams
2025-04-22 23:49                         ` Junio C Hamano
2025-04-23  1:02                           ` Nico Williams
2025-04-23  4:47                             ` Nico Williams
2025-04-22 23:21                       ` Remo Senekowitsch
2025-04-23  5:07                       ` Martin von Zweigbergk
2025-04-23 15:51                         ` Junio C Hamano
2025-04-23 16:19                           ` Martin von Zweigbergk
2025-06-06 13:04                             ` Toon Claes
     [not found]                   ` <aAgWytQNqtLzg2TU@ubby>
2025-04-23  0:25                     ` Remo Senekowitsch
2025-04-23  0:45                       ` Nico Williams
2025-04-23 12:58                         ` How GitLab does/doesn't need change IDs (was Re: Semantics of change IDs) Toon Claes
2025-04-23 18:59                           ` Nico Williams
2025-05-10 19:32                     ` Semantics of change IDs (Re: Gerrit, GitButler, and Jujutsu projects collaborating on change-id commit footer) D. Ben Knoble
2025-05-10 19:46                       ` D. Ben Knoble
2025-05-10 20:31                         ` Martin von Zweigbergk
2025-05-12 17:03                           ` Junio C Hamano
2025-05-12 17:19                             ` Martin von Zweigbergk
2025-05-14 14:38                               ` Junio C Hamano
2025-05-15 10:31                                 ` Oswald Buddenhagen
2025-05-15 16:32                                   ` Jacob Keller
2025-05-15 19:59                                     ` Junio C Hamano
2025-05-15 20:10                                       ` Nico Williams
     [not found]                           ` <aCJi+4q6DZhnfdy+@ubby>
2025-05-12 21:43                             ` Martin von Zweigbergk
2025-05-12 22:04                               ` brian m. carlson
2025-06-06 12:28                                 ` Toon Claes
2025-06-06 15:44                                   ` Junio C Hamano
2025-05-13 21:22                               ` D. Ben Knoble
2025-04-07 22:51   ` Gerrit, GitButler, and Jujutsu projects collaborating on change-id commit footer Remo Senekowitsch
2025-04-08  0:10   ` Junio C Hamano
2025-04-08  5:35     ` Martin von Zweigbergk
2025-04-08 14:27       ` Junio C Hamano
2025-04-08 15:58         ` Phillip Wood
2025-04-08 16:27           ` Nico Williams
2025-04-12 21:32           ` Junio C Hamano
2025-04-16  0:24         ` Jacob Keller
2025-05-14 15:08         ` Kristoffer Haugsbakk
2025-04-08 14:27       ` Junio C Hamano
2025-08-19 14:04 ` Askar Safin
2025-08-19 16:44   ` Ben Knoble

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250408125521.GA17892@mit.edu \
    --to=tytso@mit.edu \
    --cc=ekempin@google.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=martinvonz@google.com \
    --cc=nico@cryptonector.com \
    --cc=philipmetzger@bluewin.ch \
    --cc=remo@buenzli.dev \
    --cc=scott@gitbutler.com \
    /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.
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 NNTP newsgroup(s).