What is a criss-cross history in Git, and how does a merge choose a base then?

## How the shape arises Start with `main` and `topic` diverging from commit `A`. Then: 1. Someone merges `main` into `topic` to pick up the latest mainline — call the result `M1`, reachable from `topic`. 2. Someone else merges `topic` into `main` at roughly the same time — call it `M2`, reachable from `main`. 3. Both branches keep committing. Now ask for the common ancestors of the two tips. `M1` is reachable from `topic` and, through the merge in step 2, from `main` as well. `M2` is likewise reachable from both. Neither is an ancestor of the other. Two best common ancestors — the graph crosses over itself, hence "criss-cross". Running `git merge-base --all main topic` and seeing more than one line is the diagnostic. ## Why picking one is wrong The three-way merge derives "who changed this" from the base. If two valid bases disagree about a region, choosing either one arbitrarily makes changes look like they came from a side that did not make them. In practice this produces two bad outcomes: conflicts in places both sides actually agreed on, and — worse — silent resurrection of a change that one side deliberately reverted, because the chosen base did not know about the revert. ## The virtual merge base The recursive family of strategies solves it by **merging the bases**. If there are two candidate bases, Git merges them with each other — recursively, since those two may themselves have multiple bases — and uses the resulting tree as the base for the real merge. That synthetic tree is the virtual merge base. It exists in memory (and, where needed, as objects that are never referenced by any branch), it is not committed, and it does not appear in your history. The strategy name reflects the algorithm: the classic implementation is called `recursive` precisely because of this recursion over merge bases, and the modern default reimplementation inherits the behavior. (Which named strategy runs, and how you select one, is a separate matter — the base computation described here is common to them.) ## What you actually observe - **Conflicts during base construction.** Merging the two bases can itself conflict. Git resolves those internally as best it can, and the leftovers propagate into the base content you are then asked to merge against. This is why a criss-cross merge sometimes shows conflict content that does not match any commit you can find in the log — the "original" side of the conflict came from a synthesized tree. - **Slower merges.** Recursion over multiple bases costs real work on large histories. - **Surprising conflicts in untouched code.** When the bases disagree, regions neither current side edited can still surface. ## Diagnosing it `git merge-base --all main topic` printing more than one line means a criss-cross, and `git log --graph --oneline main topic` shows the two crossing merges that created it. If a merge behaves strangely and `--all` prints multiple hashes, you have your explanation. From there, the useful questions are: which two merges crossed, and can the branch be integrated in one direction only from now on? ## How teams get here Almost always by merging in both directions. Repeatedly merging `main` into a long-lived branch *and* periodically merging that branch back into `main` guarantees the shape. Release branches that receive backports and also get merged forward are another reliable source. The shape is not an error and Git handles it — but it is a sign that two lines of development are being exchanged in both directions over a long period, which is what makes bases multiply. ## Reducing it - Integrate in **one** direction per branch pair where you can: bring mainline into the topic branch, then merge the topic branch once and delete it. - Keep branches short-lived, so there is no time for two crossing merges to accumulate. - Complete the exchange promptly: a branch that is merged back and then kept alive for another month is the raw material for the next criss-cross. ## What to say in an interview "Two branches that have merged into each other in both directions can have several best common ancestors. Git does not pick one — the recursive strategy merges the candidate bases with each other, recursively, into a virtual merge base and merges against that. `git merge-base --all` shows you when there is more than one." Then the observable consequence: conflicts can reference content from a synthesized tree rather than any real commit.