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

[Victor Suba]

Probably has issues, but what if the default bookmark name is the branch
name?

i.e.
 to update to "default/default" you run "hg up default"
 to update to "stable/default" you run "hg up stable"

It looks nice to me, but would mean changing the current behavior of moving
to the "branch/tip".
It gives priority to _your_ branch head instead of what you pull from
remotes.

 a-b-c <-default  (my head)
     \
      d <- "remote/default" tip  (remote's head)

Cheers,
Vic

On Thu, Nov 10, 2011 at 9:44 AM, Victor Suba <vosuba at gmail.com> wrote:

> The gittish way is that the bookmark's pulled from the remote aren't
> merged into your local
> namespace - they're tied to the alias of the remote, and they're treated
> as foreign heads that
> are ignored in push/pull commands.
>
> For example if Bob pulled from Charles and now has "A" and "Charles/A"
> bookmarks in his repo,
> if Alice pulls from Bob she will only get "Bob/A" but not "Charles/A" (nor
> it's changesets).
>
> Similarly if Bob pushed upstream, it'll try to push "A" and not consider
> "Charles/A" so Bob won't
> get slapped for trying to create new heads for "Charles/A" on the remote.
>
> Perhaps in general, all foreign heads and unnamed heads could be ignored
> in push/pull by default.
>
> To satisfy those rules then we would need a "default" bookmark or similar
> on every Mercurial branch.
> Normally one would just merge everything to "tip" then push, but if
> working on multiple topic bookmarks,
> "tip" may move from topic to topic so it wouldn't work.
>
> Cheers,
> Victor
>
>
> On Mon, Nov 7, 2011 at 11:24 PM, Arne Babenhauserheide <arne_bab at web.de>wrote:
>
>> 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
>> _______________________________________________
>> Mercurial-devel mailing list
>> Mercurial-devel at selenic.com
>> http://selenic.com/mailman/listinfo/mercurial-devel
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20111110/fde89f4e/attachment.html>