Re: Semantics of change IDs (Re: Gerrit, GitButler, and Jujutsu projects collaborating on change-id commit footer)

From: Theodore Ts'o <tytso@mit.edu>
Date: Apr 12, 2025, 23:13 UTC
Message-ID: <20250412231318.GG13132@mit.edu>
In-Reply-To: <xmqqfriemw38.fsf@gitster.g>

On Fri, Apr 11, 2025 at 10:44:43AM -0700, Junio C Hamano wrote:

Show 9 quoted lines

> 
> 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.

       	   	   	     	      - Ted