On Mon, 7 Apr 2025 at 17:10, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>
> Junio C Hamano <gitster@xxxxxxxxx> writes:
>
> A well-kept reflog on a topic branch can keep track of how the set
> of patches that makes the topic evolved. E.g. with something like
> this:
>
> $ git switch topic
> $ git range-diff @{1}...
> $ git range-diff @{2}...@{1}
> $ git range-diff @{3}...@{2}
>
> you can view how the topic as a whole has evolved. A downside of
> using reflog entries this way is that it is not well-suited for
> distributed workflow.
>
> A set of individual commits that share the same "change ID" is,
> unlike reflog entries which is an ordered set of tip of topics, not
> inherently ordered. This is inevitable in the distributed world
> where many people can simultaneously work on improving a single
> "change" in many different ways, but making it difficult if not
> impossible to see how things evolved, simply because you first need
> to figure out the order of these commits that share the same "change
> ID". Some may be independently evolved from the same ancestor
> iteration. Some may be repeatedly worked on on a single strand of
> pearls (much like how development recorded in reflog entries of a
> single branch in a single user set-up goes). I guess you would need
> a way to record the predecessor vs successor relationship of various
> commits that share the same "change ID", much like commits form DAG
> to represent ancestor vs descendant relationship.
That is correct. The change ID should be sufficient for handling
simple distributed cases involving a single remote but it's not a full
replacement for something like Mercurial's Changeset Evolution [1].
For example:
1. I push commit C1 with change ID X to remote R
2. You fetch commit C1 from remote R
3. You rewrite commit C1 as commit C2 (still change ID X)
4. You push C2 to the remote
5. I fetch from the remote
My client will now be able to tell that the remote rewrote C1 to C2
(because you told it to do so). Any local commits I had on top of C1
can then be rebased on top of C2.
However, let's say you had instead pushed C2 remote R2. If my client
had never fetched from that remote before, then when I fetch from R2,
it would not know whether the new C2 was a successor of C1 or actually
a predecessor of it (or even a sibling in this "obsolescence graph" as
Mercurial calls it).
[1] https://wiki.mercurial-scm.org/ChangesetEvolution
