Hi, On Mon, 31 Jul 2006, Junio C Hamano wrote: > 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 - 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.htmlReceived on Mon Jul 31 21:35:46 2006
This archive was generated by hypermail 2.1.8 : 2006-07-31 21:36:17 EST