On Thu, Jun 26, 2014 at 10:50 PM, Christian Halstrick <christian.halstrick@xxxxxxxxx> 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@xxxxxxxxxxxxxxx > 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html