Re: git merge (resolve) _is_ stupid

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

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

> Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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

-
: 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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]