Nico Williams <nico@xxxxxxxxxxxxxxxx> writes: > Change IDs for this purpose need not be unique, IMO. If they get > duplicated either you can notice the problem before pushing, or you can > accept the dups and use context to resolve them correctly as needed. 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 shorter (like 160-bit vs 128-bit) random string, being able to directly compute the object name of the very first iteration is also a plus, if you choose to use its commit object name as its change ID (hence you do not have to worry about how you come up with a new ID) possibly in some encoded form (if you want to be able to use both object name and change ID in your UI), and have later iterations record the same change ID in the trailer would be quite simple, robust, and would be just as useful, if not more, as a scheme that uses randomly generated string as change ID. In any case, I am not all that interested in how change ID is assigned than what its semantics would be and how it would help keeping track of the changes made to changes. Personally, I am uninterested in a scheme that does not let me even tell which one among many commit objects that share the same change ID is the original and how they evolved (in other words, how they relate to each other). Thanks.
