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.... - Ted
