Nico Williams <nico@xxxxxxxxxxxxxxxx> writes: > argument against similarity heuristics over change IDs. I still think > that explicit change IDs would be better than using only commit > similarity heuristics. I do think it makes sense to explicitly record that this commit was (or "these commits were") created to refine and replace that commit (or "these other commits"), if we want to keep track of how a set of patches evolved, if such a determination can be reliably done. And I suspect that IDEs can do a much better job keeping track of such correspondence than they can keep track of renames and copies, which I mentioned in an earlier message. It is insufficient to just record a single "change ID" to each commit, in order to handle anything other than "a single commit gets updated by another single commit" case. It is insufficient to even keep track of "a single commit gets updated by another single commit, which in turn gets updated by yet another single commit" case, without assuming globally synchronised clock in a distributed environment, simply because you only have three commit objects that share the same "change ID" string among themselves, and you cannot tell between A becoming B becoming C (in which case people would consider C is the latest in the iterations), or two developers started from A to produce B and C indenendently (in which case it is not yet decided which one between B and C should be considered the latest). Since we are all human, it is possible that we think things through and make a design as complete as humanly possible but it later turns out to be insufficient. If we make such a mistake, we'd then need to deal with it and that is just simply a part of developers' life. But something that is _known_ to be structurally insufficient before it is added to the system? We should refuse to make such a thing a part of very core part of the data structure, like the header fields in commit objects. Thanks.
