On Fri, 2011-11-04 at 10:42 +0100, arne...@web.de wrote:

(this is not at all the standard commit summary style)

I think making this built-in default behavior is mildly interesting, but I really don't like the git nomenclature here. The progressive in me has always winced at master/slave terminology in computing and while this usage is arguably partly in the sense 'master key', I think it's still mostly in the sense of 'ruler'. Since I have a say here (unlike in SCSI, DMA, and SPI specs), I'd prefer to pick something more neutral. (This is not an invitation to debate or nitpick my politics of language, folks.)

The precedent in Mercurial of course is "default": default path and default branch. It's obviously a bit problematic to have both a default branch and a default bookmark since they're both in the lookup namespace, so perhaps a simple variant of that is needed. We could perhaps have a notion of the default bookmark on the default branch, ie default/default'.

Also, I think that there are some other loose ends with bookmarks that need to be tied up before we get too far thinking about this.

For instance, Alice clones Bob's bookmark B. Alice and Bob both commit and advance B. Now when Alice pulls, she gets a warning that her B bookmark is 'divergent'. Now Alice has an extra head but only one bookmark (her own). This works fine if she now has only two heads on her branch: merge picks the right one, then B points to the merge and push pushes it.

But if her current branch already had several heads, 'hg merge' won't have a default choice, nor will 'hg merge B' do anything useful. She may end up merging with the wrong head and then push will refuse to move B on the server. And if B is actually your 'master' concept, things are now a bit messy.

..which all suggests we need to figure out a nice way to track multiple bookmarks of the same name first. Git does this with a "namespace" notion, which is one possibility.