Re: Gerrit, GitButler, and Jujutsu projects collaborating on change-id commit footer

[Junio C Hamano <gitster@pobox.com>]

Nico Williams <nico@cryptonector.com> 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.