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

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 11, 2025, 17:44 UTC
Message-ID: <xmqqfriemw38.fsf@gitster.g>
In-Reply-To: <20250411154839.GC648081@mit.edu>

"Theodore Ts'o" <tytso@mit.edu> writes:

Show 7 quoted lines

> On Thu, Apr 10, 2025 at 09:18:56AM -0700, Junio C Hamano wrote:
>> Thanks to the "cover for iteration N is a direct response for
>> iteration N-1" and "cover is marked as [PATCH 0/$n]" conventions,
>
> Even if the cover for iteration N isn't a reply-to the cover for
> interation N-1, b4 will search based on the subject line for a cover
> letter with higher version number, and this mostly works.

That is nice.

Show 9 quoted lines

> My one (admittedly minor) pain point is where someone replies to a
> patch series with something like "you should really also fix FOO", and
> then someone replies with a single patch (without a cover letter,
> possibly created with git; possibly not) that addresses issue FOO.
>
> This can confuse "b4 am -c" into thinking that the patch to address
> FOO was in fact a newer version of the patch being reviewed.  It's not
> a big deal; I can deal with this manually.  But having a patch set ID
> would help with this.

Excellent. I've seen this happen often; even though I usually pick these small things up directly from within my newsreader, it would be unpleasant when it happens when you are trying to grab a large series with "b4 am".

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

> The other things that would help with having an official patch set ID
> would be to allow patchwork to automatically supercede an older
> version of the patch series (possibly with a link to the older version
> of the patch series in the Web UI).

Lovely.

Show 7 quoted lines

> I'd also love if lore.kernel.org and maybe b4 also had an automatic
> way to get at the older versions of the patch series, and the patch
> set ID would help with the automation.  Admittedly it's not strictly
> speaking necessary, since b4 is already using the cover letter subject
> line to search newer versions of the patch series.  The number of
> messages it would need to search to find older versions would be
> greater, though.

True.

Thanks.