On 4/15/2025 3:30 PM, Remo Senekowitsch wrote: > Doesn't a patch set ID suffer from the same kind of ambiguity the > change-id supposedly does? Patch sets can be split and merged, a commit > from one patch set can be cherry-picked into another. What patch set ID > should such a cherry-picked commit have? > > And I think the argument that a change-id for a singleton patch > set naturally falls out of the patch set ID can easily be reversed. > Admittedly, I don't have the most experience with the mailing list > workflow, but a multi-commit patch set usually comes with a cover > letter, right? And people like to track their cover letter in a commit? > IIUC, b4 is designed around that too. > > In that case, the cover letter has its own change-id as any other > commit, which will naturally remain stable across every version of the > patch set. It would be non-sensical to squash, split or cherry-pick the > cover letter commit. Sounds like a great candidate for the patch set ID. > If you commit your cover letter, that would work fine. If you don't commit your cover letter, you could probably also generate this. However, the commit itself wouldn't necessary have the patch-id as part of its metadata so you may not be able to easily look this up without referring to the external place where you published. Generally cover letters are commits only for the submitter. Once you submit and it is applied/merged, the patch-id would vanish unless > So the patch set ID can just as naturally flow out from the change-id. > > I can see two concrete disadvantages of the patch set ID: > > * It's strictly less powerful. As explained, the change-id can do > everything the patch set ID can via the cover letter. But the patch > set ID cannot help you track how individual commits within the patch > set evolved. Fair. > > * It's more complicated. While many Git users work with patch sets every > day, it's not a concept in Git iself. Git only knows about commits. > The patch set ID would introduce a new concept into Git unnecessarily, > while the change-id naturally extends the language Git already speaks, > that of commits. > Sure. I guess it depends somewhat on what you want to get out of the change-ids. If you only care about "how do commits fit together in series", I think a set of change-ids per commit is not that helpful on its own. You could likely build the equivalent of patch-id out of it with proper tooling. However, if patch-id is not sufficient for what most folks interested in this topic want, then I would agree with you its not the right direction. > Remo >
