Junio C Hamano <gitster@xxxxxxxxx> writes:
> I have more problems with the remaining 20% use case, where you need
> to deal with multiple commits.
>
> Perhaps your initial changeset is a single commit C0 that is so
> large and does too many things at once, and reviewers would
> naturally advise you to split things up. You'll come up with a
> series of commits, C1_0 and C1_1. The net effect of applying these
> two patches may be the same as applying the original C0, but each of
> them is more cleanly separated to address one issue at a time, and
> the explanation given in the proposed log message more clearly
> describes the issue each of them addresses. Now you gave a change ID
> to C0, and want to somehow relate C1_0 and C1_1 to the original C0.
> Which one gets the same change ID? Earlier one? The last one?
> Both gets the same change ID?
>
> Or your initial changeset is a two-commit series, C0_0 and C0_1, but
> reviewers find that each one of them alone is not complete, and
> because the issue addressed by these two is small and isolated
> enough, you are advised to make them into a single commit C1. Did
> you start with two change IDs for these two original commits? If
> so, whose change ID the updated commit C1 inherit? Or does C1 have
> two change IDs now? Or did you start with a single change ID
> assigned to both of these two original commits?
Another thing I forgot to mention.
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.
