On Thu, Jun 26, 2014 at 10:50 PM, Christian Halstrick
> 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.
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html