threads / discuss / 37005

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

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

## tl;dr

4 messages between Jun 27, 2014 and Jun 30, 2014.

replies: 3people: 2as markdown or json

Christian Halstrick· Jun 27, 2014, 05:50 UTC · lore

Imagine git does a recursive merge between A and B and finds multiple
common ancestors X1,X2 for these commits.
- Does git try to create an implicit/temporary common ancestor X3 by
merging X1 and X2?
- How should workingtree, index (stage1,2,3) look like if during that
merge of common ancestors a conflict occurs? Will I see in stage2 and
stage3 really see content of X1 and X2?
- How is the end user supposed to fix this? Imaging merging X1 and X2
leads to conflicts solved by the end user leading to a implicit common
ancestor X3. Then merging A and B with X3 as common base again
conflicts occur.

Ciao
  Chris

Shawn Pearce· Jun 27, 2014, 15:31 UTC · re: Christian Halstrick · lore

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

On Thu, Jun 26, 2014 at 10:50 PM, Christian Halstrick <christian.halstrick@gmail.com> wrote:

> Imagine git does a recursive merge between A and B and finds multiple
> common ancestors X1,X2 for these commits.
> - Does git try to create an implicit/temporary common ancestor X3 by
> merging X1 and X2?

Yes this is the point of the recursive merge algorithm. When >1 common ancestor is found they are merged. If those again have >1 common ancestor, it proceeds recursively. :)

> - How should workingtree, index (stage1,2,3) look like if during that
> merge of common ancestors a conflict occurs? Will I see in stage2 and
> stage3 really see content of X1 and X2?

Its done entirely in memory and never touches the working tree or index. When a conflict exists in the X1-X2 merge the conflict is preserved into the new virtual base.

> - How is the end user supposed to fix this? Imaging merging X1 and X2
> leads to conflicts solved by the end user leading to a implicit common
> ancestor X3. Then merging A and B with X3 as common base again
> conflicts occur.

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.

Show 7 quoted lines

>
> Ciao
>   Chris
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Christian Halstrick· Jun 30, 2014, 12:48 UTC · re: Shawn Pearce · lore

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

> 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? 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.

Shawn Pearce· Jun 30, 2014, 21:30 UTC · re: Christian Halstrick · lore

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

On Mon, Jun 30, 2014 at 5:48 AM, Christian Halstrick <christian.halstrick@gmail.com> wrote:

Show 9 quoted lines

>> 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.