"Theodore Ts'o" <tytso@xxxxxxx> 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.
