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

["Theodore Ts'o" <tytso@mit.edu>]

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.

       	   	   	     	      - Ted