tech-repository archive

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

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

On 13 Jan, 2015, at 13:55 , Eric S. Raymond <> wrote:

> Dennis Ferguson <>:
>> 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.

If you look at the revision history of about any file in the NetBSD CVS
repository you'll probably find a bunch of commits on branches that look like

date: 2008-06-17 05:15:03 -0400;  author: yamt;  state: Exp;  lines: +138 -94;
sync with head.
date: 2008-05-18 08:35:11 -0400;  author: yamt;  state: Exp;  lines: +10 -19;
sync with head.
date: 2008-09-18 00:31:45 -0400;  author: wrstuden;  state: Exp;  lines: +3 -2;
Sync with wrstuden-revivesa-base-2.
date: 2008-06-23 00:31:52 -0400;  author: wrstuden;  state: Exp;  lines: +138 -94;
Sync w/ -current. 34 merge conflicts to follow.
date: 2008-12-12 20:15:09 -0500;  author: haad;  state: Exp;  lines: +6 -2;
Update haad-dm branch to haad-dm-base2.

I guess I would argue that every one of those is a "join", in that they
are all merging one branch's development into another.  Like git they
are all losing the identity of the source branch from the metadata but,
unlike git, they are also leaving the entire revision metadata behind
as well.  The end result is that a bunch of work that may span many
revisions on the branch you are merging from looks like one revision
made directly to the branch on the branch you merge to.  If you believe
that all revisions are being indelibly tagged with the name of the
line-of-development branch the work was done one then a CVS branch
can often include many lies.

That's why I think CVS branches are a closer match to git branches
and hg bookmarks in behaviour than they are to hg named branches.

Dennis Ferguson

Home | Main Index | Thread Index | Old Index