atom feed26 messages in com.selenic.mercurial-develRe: [PATCH 2 of 4] clone to master bo...
FromSent OnAttachments
arne...@web.deNov 4, 2011 2:41 am 
arne...@web.deNov 4, 2011 2:41 am 
arne...@web.deNov 4, 2011 2:41 am 
arne...@web.deNov 4, 2011 2:41 am 
Gilles MorisNov 6, 2011 2:11 am 
Arne BabenhauserheideNov 6, 2011 2:24 am 
Arne BabenhauserheideNov 6, 2011 3:58 am 
Matt MackallNov 6, 2011 11:37 am 
Matt MackallNov 6, 2011 12:28 pm 
Sean FarleyNov 6, 2011 12:34 pm 
Victor SubaNov 10, 2011 10:07 am 
Arne BabenhauserheideNov 10, 2011 1:01 pm 
Victor SubaNov 10, 2011 6:00 pm 
Victor SubaNov 11, 2011 12:29 am 
Victor SubaNov 11, 2011 12:56 am 
timelessNov 11, 2011 5:35 am 
Sean FarleyNov 11, 2011 8:04 am 
Victor SubaNov 11, 2011 8:20 am 
timelessNov 11, 2011 1:41 pm 
timelessNov 13, 2011 4:32 am 
Martin GeislerNov 13, 2011 7:38 am 
Arne BabenhauserheideNov 13, 2011 11:12 pm 
Victor SubaNov 13, 2011 11:56 pm 
Sean FarleyNov 15, 2011 8:47 am 
Arne BabenhauserheideNov 29, 2011 7:21 am 
Arne BabenhauserheideDec 2, 2011 5:06 pm 
Subject:Re: [PATCH 2 of 4] clone to master bookmark if available
From:Matt Mackall (
Date:Nov 6, 2011 11:37:37 am

On Fri, 2011-11-04 at 10:42 +0100, wrote:

# HG changeset patch # User Arne Babenhauserheide <> # Date 1320398369 -3600 # Node ID 8f614fd777b7190329b9fe705b6e1f518d9193ab # Parent 0cc7332a0bb20c3daf003f3fe0a140f5925f0eb8 clone to master bookmark if available.

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