On Thu Apr 3, 2025 at 7:48 PM CEST, Theodore Ts'o wrote: > On Thu, Apr 03, 2025 at 08:39:31AM -0700, Elijah Newren wrote: >> >> But <change ID> isn't unique, right? The whole point of having the >> change ID is to preserve it despite edits (e.g. rebase, commit >> --amend, cherry-pick), meaning that you end up with multiple commits >> with the same <change ID>. > > It's supposed to be unique, but it isn't always. I've certainly seen > cases where it might not be, but that's arguably a bug. I suspect in > some cases it's because users are cutting and pasting commit > descriptions, and sometimes when they rebase a patch series, patches > will get collapsed or split apart --- especially when backporting to > an older LTS release. > > Perhaps because of this, in some communities, their tooling in front > of Gerrit will always regenerate the Commit-ID when doing a > cherry-pick (For example, when cherry-picking from the development > HEAD branch back to a release branch). > > 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. Remo
