Problems converting from git to mercurial

[0x138^2]

Matt Mackall wrote:
> On Thu, Dec 13, 2007 at 11:37:54AM -0600, 0x138^2 wrote:
>>>> 1) After the conversion, 'hg branches' returns a single named
>>>>    branch, default.  The original git repository had 70+ named
>>>>    branches.  'hg heads' does return close to the correct number
>>>>    of heads (60+), but not quite (more on this in 1b).  This
>>>>    breaks down into two subparts:
>>>>
>>>> 	a) The convert extension does not appear to be creating
>>>> 	   a named branch for every named branch in the source
>>>> 	   git repository.  Almost all git branches do appear
>>>> 	   to be represented as mercurial heads though.
>>> Turns out it's actually impossible to do this right, because git
>>> doesn't store enough information. Consider a repo with two branches in
>>> git, each with a number of commits. Because git doesn't record which
>>> branch each commit originated on, there isn't enough information in
>>> the tree to label each changeset. A git user can swap the names of the
>>> two branches and nothing is recorded to say it was ever different. If
>>> two branches have a common ancestor (and they almost certainly will),
>>> what branch is that ancestor on? We don't know.
>>>
>>> The best we can do in the general case is to label each branch head as
>>> being on that branch. Then if you do an incremental conversion, we'll
>>> probably do the right thing. But git's concept of branches aren't a
>>> perfect match to hg's so this conversion won't be perfect either.
>> There are two cases here though, right?
>>
>> 1) Continual mirroring of a git tree .
>> 2) Doing a one time conversion with no desire to pull from the
>>    git tree again.
>>
>> What you say makes total sense in the context of the first case
>> but couldn't the second case be made to work?
> 
> Consider a tree that looks like this:
> 
>         o-o-o-o-o-o-b <- branch foo
>        /
>  -o-o-a
>        \
>         o-o-c <- branch bar
> 
> What branch are "a" and its ancestors on? We haven't the slightest
> clue. In fact, the only changesets we have any certainty about are b
> and c because branch names aren't part of history.

Ok, so it sounds like branches in mercurial must be part of
a commit, while in git they're fully represented in meta data.

If this is indeed the case then I would argue that for 95% of
cases the choice in branch name for 'a' could be made arbitrarily
during the conversion without any dire consequences.  For the
other 5%, going back to work in a's ancestry after the convert
could result in a surprise for the developer who was expecting
a different branch name.

- Josh