Re: git branches (was: Re: Reply to David Holland's notes and comments)

["Eric S. Raymond" <esr%thyrsus.com@localhost>]

Dennis Ferguson <dennis.c.ferguson%gmail.com@localhost>:
> As I understand it, 'hg branch' creates colored branches while 'hg bookmark'
> creates branches which are pretty much identical to git's (except that git
> lets you track just a single bookmark branch in a remote repository if that
> is all you are interested in, while I couldn't find a way to avoid getting
> all hg bookmark branches in the clone).

That is correct.

> This means the most honest way to convert git or cvs branches to hg would
> probably be to convert them to hg bookmark branches since, like cvs and
> git, hg bookmark branches also throw away line-of-development information
> when merging between that kind of branches (cvs only merges data, and not
> metadata, between branches so it's throwing away even more) and wouldn't
> lead you to believe you knew something about the converted data's development
> history you in fact have no idea about.

This is true if you are converting from a git repo with joins.  But if you are 
converting from a CVS repo or a git repo *without* joins, it's not deceptive
to use hg branch.  In that case you do have all the line-of-development
information, unambiguously, and after conversion Mercurial will maintain it
for you by coloring commits as they are added.

> It also means that if Mercurial is chosen as the repository but you want
> to retain the ability to get the data out of it and into something else
> without information loss you probably want to avoid using all of Mercurial's
> branching features or you'll be limited to conversion targets which have
> a comparable set of features.

That is correct.

And, as a matter of reality, that set consists of ... Mercurial. :-)

>                       I don't know what is done to convert Mercurial
> to git; perhaps convert hg bookmarks to git branches but separate hg
> colored branches into separate repositories (another kind or branch)?
> That wouldn't avoid the loss of color information for merges but would at
> least preserve the distinct separateness of the hg named branches.

The various exporters that exist (and there are at least two, possibly
three) don't document this very well.  One of them, the frej version
on github, says this:

   hg-fast-export supports multiple branches but only named branches with
   exactly one head each. Otherwise commits to the tip of these heads
   within the branch will get flattened into merge commits.

...which seems to imply that it tries to map *named* branches to git
bookmark-like branches.  I have no idea what it does with bookmarks.
-- 
		<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>