[PATCH 2 of 4] clone to master bookmark if available

[Arne Babenhauserheide]

Am Montag, 7. November 2011, 14:59:34 schrieb Matt Mackall:
> I skipped the explanation of how to scale it as I assumed the
> conventions of prime notation were familiar to everyone. But that's not
> the point: the point is that we don't really need to 'name' these other
> bookmarks. They should by their nature be short-lived and not numerous,
> much like unmerged heads.

I think that this is an assumption which does not hold in all cases. Many 
people don’t work completely organized, and merging the bookmarks will likely 
be postponed from time to time, so it becomes important to know, from whom we 
pulled the bookmark X.

> Last path segment isn't a terribly good one, as that will often be the
> same. Hostname and IP address have similar issues. Even full paths can
> collide if the remote repository gets rebased or someone forcibly pushes
> another head between your pulls. We could attach usernames from commits,
> but again, those will eventually collide. Nor will they necessarily be
> meaningful on a large project.

Or use [paths] definitions, whis is essentially what git does, it seems. 

> ..which brings me back to your "default bookmark" concept, which could
> be simply:
> 
> @  <- the default bookmark to checkout on clone
> @1 <- its first divergent copy

This looks quite nice and would fit the glog output for ".". 

>  _@/. ]

So we have _ (what many people use in names), @ (which says “here”), / (which 
looks like a listing when used between bookmark and *prefix*; what git uses) 
and . (which already has special meaning as working copy revision). 

Best wishes, 
Arne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 316 bytes
Desc: This is a digitally signed message part.
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20111108/da12e9e3/attachment.pgp>