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

[Junio C Hamano <gitster@pobox.com>]

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

> Regardless how we come out on whethe having an "inode number" for the
> high-level semantic value of a commit is worth it, I do think having a
> "patch set ID" which ties related commits together does make sense,
> though.  That would solve some interesting problems both for the
> web/forge review workflow as wel as the mailing list review workflow.
> I'd be curious what people might think about that.

As a concept, I agree that a mechanism to identify these iterations
of the same topic collectively is a very valuable thing to have.

FWIW, I use the Message-ID of the cover letter e-mail as a rough
approximation for "patch set ID", and it is quite usable once you
train your contributors to always make the cover letter for
iteration N a direct reply to the cover letter for iteration N-1,
and also make the individual patches a direct reply to the cover
letter for the same iteration.

Then visiting lore.kernel.org/$mid/ will give me at a glance some
essential information about the series, like

 - how hotly the topic is being discussed?

 - does the iteration $mid I happened to have picked the latest, a
   bit older, or irrelevantly older?

 - has the topic been extending its scope?

Thanks to the "cover for iteration N is a direct response for
iteration N-1" and "cover is marked as [PATCH 0/$n]" conventions,
"b4 am" grabs, by default, the patches from the latest iteration
when given the message-id of the cover letter of any iteration of a
patch set.  Because most of the time a consumer of an evolving
patchset is interested in the latest iteration (unless the
contributor screws up, in which case we may need to go back and
explicitly grab an older iteration), I never felt a need for an
official "patch set ID", though.