[PATCH] clone: update to @ bookmark if it exists

[David M. Carr]

On Mon, Oct 15, 2012 at 9:39 AM, Thomas Arendsen Hein
<thomas at intevation.de> wrote:
> * David M. Carr <david at carrclan.us> [20121015 14:29]:
>> On Fri, Oct 12, 2012 at 4:08 PM, Matt Mackall <mpm at selenic.com> wrote:
>> > On Tue, 2012-08-28 at 10:51 -0500, Kevin Bullock wrote:
>> >> # HG changeset patch
>> >> # User Kevin Bullock <kbullock at ringworld.org>
>> >> # Date 1332366819 18000
>> >> # Node ID 579afc1a4378a55f64f6fd185f3de40da5bfbb4a
>> >> # Parent  99a2a4ae35e2180b7f825ef2677c36d538eac4ba
>> >> clone: update to @ bookmark if it exists
>> >
>> > Queued, thanks. Lots of people seem to be choosing bookmark-based
>> > workflows, having a default bookmark seems unavoidable.
>
> At first I thought "Good news", but I guess when cloning the crew
> repository the user would expect the crew bookmark to be checked
> out. Or should the bookmark "crew" be replaced by "@"? If you pull
> from crew you will get "@@crew" (or "@crew", see below).
>
> And the stable repositories (hg-stable, crew-stable) could have the
> @ bookmark to the tip of the stable branch while being identical to
> the default repos otherwise.
>
>> If the @ bookmark is divergent when pulling from remote "foo", do we
>> want the divergent bookmark stored as "@foo" or "@@foo"?  The code
>> currently appears to be using "@@foo".  I think that the double @ sign
>> looks sort of weird and would have expected the other behavior.
>>
>> I suppose the argument in favor of the double @ sign in this case is
>> that it's more consistent.  Whatever the bookmark name is, you append
>> an @ sign to express that it's a divergent bookmark, and then include
>> an identifier to distinguish which remote it refers to.  Reading
>> "@foo" with that mindset would tell you that it's a divergent ""
>> (empty string) bookmark for the remote "foo", which isn't accurate.
>>
>> That being said, I don't think most users will think it through like
>> that.  They'll see the double @ sign and assume it's a bug without
>> further thought.  I think that "@foo" is a perfectly fine way to
>> represent the concept of "the default bookmark at the remote foo".
>
> Whatever we do, @@foo should be accepted by update/--rev for the
> consistency arguments you mentioned above.
>
> Providing a shorter form that is easier to the eyes might not be
> easier for the brain (really nothing at foo?) or when talking about it
> ("Sorry, I did not understand what you said which bookmark @foo you
> meant, I just heard @foo").

For talking about it, I don't think either is particularly good.  For
comparison, let's try out some sentences, in this case using
"feature-foo" as a normal bookmark name and "upstream" as a remote
name:
- Normal Bookmark: When you pull from upstream, feature foo will
diverge.  To resolve that, merge with feature foo at upstream.
- @ with @@ behavior: When you pull from upstream, at will diverge.
To resolve that, merge with at at upstream.
- @ with @ behavior: When you pull from upstream, at will diverge.  To
resolve that, merge with at upstream.

They both sound pretty nonsensical to me.  If our goal is to have it
make sense in conversation, I think we'd be better off calling the
default bookmark "default-bookmark" instead of "@".  I'm not
suggesting "default" so that we at least have some difference between
the name of the default branch and the default bookmark.  With
"default-bookmark", I these sentences might go:

When you pull from upstream, [the] default bookmark will diverge.  To
resolve that, merge default bookmark at upstream.

>
> Regards,
> Thomas
>
> --
> thomas at intevation.de - http://intevation.de/~thomas/ - OpenPGP key: 0x5816791A
> Intevation GmbH, Neuer Graben 17, 49074 Osnabrueck - AG Osnabrueck, HR B 18998
> Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner


-- 
David M. Carr
david at carrclan.us