On Thu, Apr 03, 2025 at 10:31:08PM +0200, Remo Senekowitsch wrote: > > So as a cauaionary note, as people use Change ID's in Gerrit today, > > sometimes the Change ID changes between rebases, and I've certainly > > seen cases where the sematic meaning of the commit has changed > > significantly without changing the Change ID. So it's great as a > > hint, but in practice, at least today, it might not be completely safe > > to assume the semantics are as advertised.... > > That is all true. I would just say that some change-ids not being unique > doesn't systematically take away from the benefits. If a given change-id > is unique, you get all the benefits for that patch, independent of > the uniqueness of the other change-ids. If some patch changes a lot > semantically while keeping its change-id, that will degrade its review > history, but without affecting the review history of any other patch. Oh, agreed. I've certainly used a Change-ID by pasting it into the Gerrit Search Box, and when I saw two or three unrelated commits where the one-line subject were for entirely different kernel subsystem, as a human I could do the disambiguation myself. And if I did't find a particular bug fix for the various release brances, I would cut and paste the one-line commit summary into the Gerrit Search Box, and find the right commit, again aided by human intelligence. So I'm super-glad that it's there, and it *is* useful. But I just wanted to inject a note of caution if people were thinking about using it in some kind of automated tooling --- especilly if there is a proposal to inject this into git as a first-class object. Certainly from a git perspective, I will admit that more often than not, I generally don't do something like "git log --grep I23e218cd964f16c0b2b26127d4a5ca6529867673", but rather, "git log --grep 'mediatek: Don't modify spi_transfer'". If I have to cut and paste a Change-ID, most of the time I aso have access to the one-line commit description, and grepping for something human readable is just easier. - Ted
