Re: Newbie grief

[Mark Brown <broonie@opensource.wolfsonmicro.com>]

On Fri, May 04, 2012 at 10:59:30AM -0400, Stephen Bash wrote:

> If my hg-foo isn't too out of date...  The hg recipe creates 4000
> "heads" on a single branch, rather than 4000 branches (see the 'hg
> heads' command).  This is basically the point Rich is arguing I
> believe.  hg allows for multiple tip commits all with the same branch
> name (IMO this is important because hg branch names are permanently
> recorded in their version of the commit object).

> This is a *fundamental* difference in the implementation of the two
> tools (and causes confusion because now "branch" has two slightly
> different meanings).  However, IMHO, philosophically it all boils down
> to the same thing: development has forked and has to be merged.
> Whether that fork has a name or not is up to the tool.  In hg it
> doesn't *have* to have a name (multiple heads per branch), in git it
> does (single head per branch).

Ah, this makes some sense - I *think* it's coming down not so much that
you have to name the branches (googling around it seems hg does assign
names, it's just that they're autogenerated numbers) as to the fact that
unless you branch directly from wherever your origin repository is git
doesn't keep track of where you're ultimately trying to merge development
back to.

If the above is right then some UI around remotes and branch --track and
--set-upstream which provides an automated way of saying "this is a
scratch branch for merge into X" and can then do things like helping
with merging and enumerating all the scratch branches for a given
destination, or with bundling up all the scratch branches and dropping
them elsewhere for merge might do the trick?  A "strong" branch kind of
thing.

This does come up a bit with traditional git workflows - I have it a
little when working between my desktop and my laptop - but is IME
usually resolved by publishing frequently to some central location
frequently and then rebasing if lots of local merges aren't approved of
in your workflow.  git (at least in kernel usage) has more of a
"building a patch series" model oriented around preparing things for
review.