RE: needs merge

>-----Original Message-----
>From: git-owner@vger.kernel.org 
>[mailto:git-owner@vger.kernel.org] On Behalf Of Junio C Hamano
>Sent: Saturday, January 07, 2006 5:29 AM
>To: Brown, Len
>Cc: git@vger.kernel.org
>Subject: Re: needs merge
>
>Len Brown <len.brown@intel.com> writes:
>
>> however, when i then merged that branch into another there seem to
>> be some phantom conflicts on the very same files.
>
>First of all, does the final merge result look correct, without
>conflict markers?  I've slurped from your tree and tried the
>merge myself and it seems that both branches and the merge
>result of these branches have the conflicting path the same way,
>so I think it did the right thing for you, but I am just trying
>to make sure.
>
>> Do I understand all this output to mean that git attempted two
>> different merges, and discarded the 1st attempt in favor of 
>the second?
>
>Not really.  This is Fredrik's "recursive" merge in action.
>
>acpica (ed03f4) is merged into test (e3627f), but these two
>branches have criss-cross merge history and there are two
>equally valid common ancestors, 0aec63 and ed349a.
>
>What it did was first to find a merge between these two common
>ancestors, during which it found conflicting merge on those
>paths.
>
>It then used this merge result (with conflict markers still in
>them!) as the "virtual common ancestor" to merge the ed03f4 and
>e3627f commits; because both branches have resolved the
>conflicting part the same way earlier, this three-way merge
>cancels out the part that are marked with conflict markers in
>the virtual common ancestor (this is the cutest part of Fredrik
>merge algorithm).
>
>-
>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
>