Some feedback on colo plugin

[Stephen J. Turnbull]

Neil Martinsen-Burrell writes:
 > How should merging from a fasces work?  It would seem to involve too
 > many working trees to fit into the current model of a colocated
 > workspace that has one tree that points to many branches.

In fact, this should normally not be a problem if it's really
colocated branches a la git, or Mercurial named branches.  The reason
is that normally one branch will be active, and others will generally
be fast forwards or new branches.  See description of git, below.

 > How do hg and git deal with repositories with multiple branches?  When I
 > pull from a git repository, do I get all of the heads (=branches) or
 > just the master?  Do they have a way to push multiple heads as
 > well?

I don't know about hg currently.  The last time I tried it (about 18
months ago) the answer was "not well for my workflows".  ISTR that
push would error if you had more than one head, unless you used the
force (-f) flag, in which case it pushes everything.

In the case of git, the answer is somewhat complex.  First, remember
that in git there are no branches as there are in Bazaar.  A branch is
just a reference to a commit (a "ref") which is automatically updated
to point to the new commit when you commit to that branch.

The basic answer is that in both pushing and pulling you need to
specify a source:target ref pair.  There are some implicit defaults.
For example, if you clone a repository, then for each branch of that
repository at the time of cloning you will get a "remote tracking
branch" such as 'origin/master' or 'origin/feature'.  These branches
are supposed to be pristine copies of the remote branches.  They'll
stay that way unless the user does Something Stupid[tm].  There will
also be local branches, 'master' or 'feature', which correspond in the
obvious way to the tracking branches.

If you currently have "master" checked out, then "git pull" (no
arguments) will (1) fetch any objects reachable from the origin's
"master" branch that aren't already in the repo, (2) update
'origin/master' to point to the head of that branch, (3) merge from
'origin/master' into the current workspace, and (4) if no merge
conflicts, commit to 'master'.

"git push" is similar, except that it will fail if the implied merge
is not a fast-forward (and so would create a new head, and cause the
previously referenced commit to become garbage).  This can be forced
with -f, but that's almost always a bad idea, of course.

It is possible to configure a particular repo to have different
defaults, and in particular, to make "git pull" attempt to update
several tracking branches simultaneously.  However, AIUI only the
currently checked out branch will have a merge done.  Other branches
will need to be explicitly merged later.