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

[Dennis Ferguson <dennis.c.ferguson%gmail.com@localhost>]

On 12 Jan, 2015, at 21:51 , Eric S. Raymond <esr%thyrsus.com@localhost> wrote:
> This is the problem you are observing.  Better translation tools cannot
> fix it; it is intrinsic to any VCS with true merges.  There are only two
> options here: the VCS can either implement branches as stored and 
> persistent node colors a la Mercurial, or accept that line-of-development 
> information will be lost at merges a la git.
> 
> Therefore, the practical solution to your problem is that you should advocate 
> for the conversion target to be Mercurial rather than git.  (Supposing you
> succeed, we'll need to find an importer that maps import-stream branches
> to Mercurial node colors.)

I would also guess that the reason an importer from cvs or git might not
need or want to map branches to Mercurial named branches is that Mercurial
supports more than one kind of branch that can be used for the conversion.
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).  In fact I think hg additionally
supports "anonymous" branches, which are like unnamed bookmark branches that
need to be referred to by the commit hash or something; you can do this with
git too, I guess, but git thinks it is a mistake and will garbage collect them.

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.

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

What I have noticed is that the few hg repositories I've looked at make
very sparing use (if any) of named branches, though that may well be a
biased sample, and even the hg documentation discourages their use a bit.
The hg repository for Mercurial itself only has two, "default" and "stable".
It may be that many people find the light-weight, git-style bookmark
branches to be better suited to their needs in most cases anyway.

Dennis Ferguson