Re: Newbie grief

From: Mark Brown <broonie@opensource.wolfsonmicro.com>
Date: May 4, 2012, 16:29 UTC
Message-ID: <20120504162947.GA2311@sirena.org.uk>
In-Reply-To: <6211a2de-a545-41c3-9fb5-e7e3033b45f4@mail>

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

Show 6 quoted lines

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

Show 7 quoted lines

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