Re: How to populate index/worktree when recursive merge merges multiple common ancestors?

On Mon, Jun 30, 2014 at 5:48 AM, Christian Halstrick
[off-list ref] wrote:

quoted

They don't. The conflicts are preserved into the virtual ancestor. The
user only sees the final conflicts during merging of A and B with
virtual X3 as the common ancestor.

Ah, now I understand. When I merge X1 and X2 into the virtual X3
I should not stop if this is not doable without conflict resolution. I
should store in memory the X3 content, including all the conflict
markers. If I finally merge A and B I will specify a common base
content which may contain conflict markers. Right?

Yes.

If X3 content is large, it could flow to loose objects on disk. These
will be unreachable and cleaned up automatically in a future garbage
collection.

Are git config param's like merge.conflictstyle=diff3 are also
effective when creating the virtual X3 content? Couldn't that lead to
complicated conflict marker situations? In the area where you expect
common base content you again see conflict markers in diff3 style.

Yes, but I think this is the correct behavior. The machine can't
reconcile the two branches any better than this, so now a human has to
step in and fix all of the conflicts.

IIRC, this is uncommon. Usually you use A's common content as A and B
do not differ relative to X3 in the regions where X3 has a conflict,
so those conflicts aren't considered relevant when A and B merge.