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

[David Holland <dholland-tech%netbsd.org@localhost>]

(this part is important enough to warrant its own reply, I think)

On Wed, Jan 07, 2015 at 05:50:50AM -0500, Eric S. Raymond wrote:
 > Apologies for the slightly belated reply; I'm not subscribed to this
 > list yet and found David Holland's comments when checking the list
 > archives to make sure my technical proposal had come through.

Oops; I assumed you would have by then. My fault.

 > >So, because git doesn't have real branches (only git-branches) the
 > >current conversion loses branch information. Is this limitation also
 > >present in the git-fast-export format? If so, is there a way to avoid
 > >throwing away branch information when converting to hg?
 > 
 > I don't understand what is "real" about CVS branches that isn't "real"
 > about git branches.  Both are simply labels pointing to tip revisions
 > in a tree.  Can you clarify what "branch information" you believe is
 > being lost?

In git, a branch is a self-moving tag that names the head of the
branch, that is, a branch is a version.

In CVS, Mercurial, Subversion, and virtually every other SCM I know
of, branches are subgraphs, that is, sets of commits. E.g. in CVS when
you create a branch, it gets a number, and then every commit on the
branch is numbered relative to the branch number. And in Mercurial,
the branch a commit is on is part of the commit metadata and thus a
permanent property.  (I am told that Monotone handles branches more or
less the same way as Mercurial, but have no direct experience.)

These are not isomorphic models; while a git branch induces a subgraph
(all commits in the ancestry of the branch head) this subgraph is not
the same subgraph people usually intend when talking about the commits
on a branch. In particular, for a diverging branch (such as a release)
it doesn't stop at the branch point; and for a converging branch (such
as for feature development) once the branch is merged back into the
trunk the induced subgraph contains the whole trunk in addition to the
commits originally made on the branch.

And, as best I can tell if you create a feature branch, hack for a
while, and then merge, there's no automated way to tell afterwards
which of the various chains of commits were your feature commits on
your feature branch, and which were something else. (Reading the
commit messages by hand doesn't scale.)

This loses information. Losing information is bad.

Since I would like to avoid losing this information, particularly if
converting the repository to something other than git, my questions
are:

   (1) Am I missing something in git's branch model? I don't think so
       but it's always possible.

   (2) Does this same limitation/problem affect git-fast-import
       streams?

   (3) If so, is there a way to augment the data to avoid losing the
       information in the case where the target is not git?

and implicitly also:

   (4) Do your tools avoid this problem?


Note to the peanut gallery: responses of the form "you don't need that
information" or "you are wrong for wanting this" will be ignored.

 > Vendor branches are a defect attractor. The remaining trouble spots 
 > likely cluster around those.

s/attractor// :-)

-- 
David A. Holland
dholland%netbsd.org@localhost