Re: git merge (resolve) _is_ stupid

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jul 31, 2006, 11:13 UTC
Message-ID: <Pine.LNX.4.63.0607311307350.29667@wbgn013.biozentrum.uni-wuerzburg.de>
In-Reply-To: <7v7j1u6nsx.fsf@assigned-by-dhcp.cox.net>

Hi,

On Mon, 31 Jul 2006, Junio C Hamano wrote:

Show 7 quoted lines

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > The culprit is the call to parse_commit() in merge_bases(). How about 
> > this?
> 
> Do you mean merge_bases() in commit.c which is called by
> get_merge_bases()?

Yes, the same.

> If so the patch feels like papering over a more grave bug -- the result 
> from make_virtual_commit does not seem to have any proper parent 
> information, so how is merge_bases() expected to return anything 
> sensible?

It is not a grave bug, but very much by design: remember, a recursive merge means that if you have more than one merge base, then the merge bases are merged first. And the result is -- tada -- a virtual commit.

It does have (virtual) parents, but we do _not_ want to traverse them in merge_bases().

However, they have (virtual) children, and _these_ relationships are important: in your case (I guess) that the merge_bases() finds the virtual commit, since (with the virtual history) the other commit is just a fast-forward.

So, a virtual commit is something like a merge base combining two or more merge bases.

> I am confused, but going to bed first.

I know the feeling ;-)

Ciao, Dscho