From: "Remo Senekowitsch" <remo@buenzli•dev>
To: "Junio C Hamano" <gitster@pobox•com>, "Theodore Ts'o" <tytso@mit•edu>
Cc: "Nico Williams" <nico@cryptonector•com>,
"Martin von Zweigbergk" <martinvonz@google•com>,
"Git Mailing List" <git@vger•kernel.org>,
"Edwin Kempin" <ekempin@google•com>,
"Scott Chacon" <scott@gitbutler•com>,
"philipmetzger@bluewin•ch" <philipmetzger@bluewin•ch>
Subject: Re: Semantics of change IDs (Re: Gerrit, GitButler, and Jujutsu projects collaborating on change-id commit footer)
Date: Wed, 16 Apr 2025 00:30:22 +0200 [thread overview]
Message-ID: <D97KGN6TV8F7.1KKO8GYI65W59@buenzli.dev> (raw)
In-Reply-To: <xmqq8qo2srn5.fsf@gitster.g>
On Mon Apr 14, 2025 at 5:13 PM CEST, Junio C Hamano wrote:
> "Theodore Ts'o" <tytso@mit•edu> writes:
>
>> On Fri, Apr 11, 2025 at 10:44:43AM -0700, Junio C Hamano wrote:
>>>
>>> The submitting contributor must make a conscious arrangement to give
>>> a "patch set ID" shared among the messages in a single iteration,
>>> and everybody who are responding must make sure they do not add the
>>> same ID to the messages they throw at the thread in response. Those
>>> who use format-patch and send-email can do that with convention and
>>> automation and there is no reason to rely on In-Reply-To: header
>>> (which may confuse the automated recipient of manually created
>>> follow-up messages).
>>
>> So it all depends on how the patch set ID is implemented. Here's one
>> way that I had in mind. The reason why I like like this over the
>> Change-ID approach is that the semantics can be very clearly defined,
>> and the only thing we rely on is the user saying "this new commit is
>> part of patch series which I'm putting together".
>>
>> By default when creating a new commit, the field is empty (in which
>> case the patch set ID is presumed to be the same as the commit ID), or
>> if the user gives a command-line flag say, "git commit --series"
>> which indicates that it is part of a patch series in which case the
>> patch set ID of the commit is set to the patch set ID of the current
>> commit (i.e., eventully, its parent commit).
>>
>> Whenever the commit is amended or rebased or cherry picked, if the
>> patch series ID is NULL, then it is set to the original commit ID.
>> Otherwise, the existing patch set ID is preserved.
>>
>> The patch set ID will be output by git format-patch (perhaps as "Patch
>> Series ID: sha has" immediately after the --- line. And if it is
>> present, "git am" will import that patch series ID into git commit
>> which creates when it sucks in the e-mail.
>>
>> The net affect of this is that for new versions of git which implement
>> the Patch Set ID, all new commits are treated as patch series of
>> length 1, unless a subsequent commit is created using "git commit
>> --series". And the Patch Set ID will be preserved across
>> cherry-picks, rebase operations, and git send-email/git apply-message
>> operations.
>>
>> So if someone replies to an existing e-mail thread with a new commit,
>> git format-patch will give it a different patch set ID, so we can
>> distinguish it from an amended copy of a patch in the patch series.
>>
>> It also means that singleton commits, the patch ID effectively acts
>> much like the tranditonal Change-ID. For multi-commit patch series,
>> all of the commits will have the same patch set ID.
>
> Yeah, I like that aspect the best---the case for single commit
> series falling out as a natural degenerate case of the more general
> case to support multi-commit series is a good sign that the design
> got something right ;-)
>
> I am still not sure what to think about the lack of explicit the
> evolution history of one patch set that share the same patch set ID.
>
> When we have 10 commits that share the same patch set ID, I can
> imagine that we can easily tell 3 are from one iteration, and 3 and
> 4 among the rest are from another two iterations by noticing that
> there are three strand of pearls, having 3, 3, and 4 commits on it.
> And we can identify the initial round by noticing that one of the
> commits have its name as the patch set ID, but I am not sure if we
> should be OK by not having anything but the committter timestamp to
> tell which one among the other two iterations are earlier, and we
> cannot tell anything about these two other iterations if they are
> independent rewrites of the original round.
>
> But other than that, I like something with clearly defined semantics
> (and the definition coming naturally out of the structure, not out
> of some arbitrary convention that forces to bring in some
> semantics), and what you outlined above looks reasonably clean and
> easy to use.
Doesn't a patch set ID suffer from the same kind of ambiguity the
change-id supposedly does? Patch sets can be split and merged, a commit
from one patch set can be cherry-picked into another. What patch set ID
should such a cherry-picked commit have?
And I think the argument that a change-id for a singleton patch
set naturally falls out of the patch set ID can easily be reversed.
Admittedly, I don't have the most experience with the mailing list
workflow, but a multi-commit patch set usually comes with a cover
letter, right? And people like to track their cover letter in a commit?
IIUC, b4 is designed around that too.
In that case, the cover letter has its own change-id as any other
commit, which will naturally remain stable across every version of the
patch set. It would be non-sensical to squash, split or cherry-pick the
cover letter commit. Sounds like a great candidate for the patch set ID.
So the patch set ID can just as naturally flow out from the change-id.
I can see two concrete disadvantages of the patch set ID:
* It's strictly less powerful. As explained, the change-id can do
everything the patch set ID can via the cover letter. But the patch
set ID cannot help you track how individual commits within the patch
set evolved.
* It's more complicated. While many Git users work with patch sets every
day, it's not a concept in Git iself. Git only knows about commits.
The patch set ID would introduce a new concept into Git unnecessarily,
while the change-id naturally extends the language Git already speaks,
that of commits.
Remo
next prev parent reply other threads:[~2025-04-15 22:30 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
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 [this message]
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=D97KGN6TV8F7.1KKO8GYI65W59@buenzli.dev \
--to=remo@buenzli$(echo .)dev \
--cc=ekempin@google$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=martinvonz@google$(echo .)com \
--cc=nico@cryptonector$(echo .)com \
--cc=philipmetzger@bluewin$(echo .)ch \
--cc=scott@gitbutler$(echo .)com \
--cc=tytso@mit$(echo .)edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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