On Tue, Apr 22, 2025 at 04:49:13PM -0700, Junio C Hamano wrote: > Not having to worry about duplicates (as long as you trust Git well > enough not to worry about object name collisions) is a powerful > thing, though. Unless there is a strong reason to stick to slightly > [...] Is that really true? Yes, because if two different objects have the same hash then the first one pushed to a repository will "win" and the second's content will never appear, right? I suppose that the server could detect the collision at push time and reject the push to make sure that there's no surprises for the pusher. But Git requires objects and refs to be unique _and_ it indexes by them. This is great. It might be fine for change IDs too, or not. But remember that proponents want change IDs to not quite be unique, since the point is that they tie multiple different versions of a commit series together for the purpose of code review. In the end, when the code review is completed and approved then the change ID might be unique again, but then cherry-picking onto other branches for forward- or back-porting might render them non-unique again. If you accept change IDs, I highly recommend not requiring them to be unique. Nico --
