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
On Thu, Jun 26, 2014 at 10:50 PM, Christian Halstrick
[off-list ref] 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.
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
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.
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.