Hello all,
While working on the commit-graph feature, I made a test commit that
sets core.commitGraph and gc.commitGraph to true by default AND runs
'git commit-graph write --reachable' after each 'git commit' command.
This helped me find instances in the test suite where the commit-graph
feature changes existing functionality. Most of these were in regards to
grafts, replace-objects, and shallow-clones (as expected) or when trying
to find a corrupt or hidden commit (the commit-graph hides this
corrupt/missing data). However, there was one interesting case that I'd
like to mention on-list.
In t6024-recursive-merge.sh, we have the following commit structure:
# 1 - A - D - F
# \ X /
# B X
# X \
# 2 - C - E - G
When merging F to G, there are two "best" merge-bases, A and C. With
core.commitGraph=false, 'git merge-base F G' returns A, while it returns
C when core.commitGraph=true. This is due to the new walk order when
using generation numbers, although I have not dug deep into the code to
point out exactly where the choice between A and C is made. Likely it's
just whatever order they are inserted into a list.
In the Discussion section of the `git merge-base` docs [1], we have the
following:
When the history involves criss-cross merges, there can be more
than one best common ancestor for two commits. For example, with this
topology:
---1---o---A
\ /
X
/ \
---2---o---o---B
both 1 and 2 are merge-bases of A and B. Neither one is better than
the other (both are best merge bases). When the --all option is not
given, it is unspecified which best one is output.
This means our official documentation mentions that we do not have a
concrete way to differentiate between these choices. This makes me think
that this change in behavior is not a bug, but it _is_ a change in
behavior. It's worth mentioning, but I don't think there is any value in
making sure `git merge-base` returns the same output.
Does anyone disagree? Is this something we should solidify so we always
have a "definitive" merge-base?
The biggest reason I think we should avoid sticking to the existing
behavior is that the current behavior depends on the walk order. That
means we would not be able to concretely define a tie-breaker without
changing the existing behavior anyway.
Thanks,
-Stolee
[1] https://git-scm.com/docs/git-merge-base#_discussion
