[PATCH 0 of 8] Move bookmarks extension to core

[Kevin Bullock]

On Jan 17, 2011, at 2:52 AM, David Soria Parra wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 17.01.2011 08:53, Alexander Solovyov wrote:
>> On Sun, Jan 16, 2011 at 23:57,  <dsp at php.net> wrote:
>>> 3. pull behavior changed
>>> Instead of pulling a specific bookmark from a remote repository, hg pull
>>> now pulls all remote bookmarks. I think that we consider bookmarks on a remote
>>> repository always public as there is no notion of a private bookmark. It is also
>>> closer to the behavior I like to have to support feature branches using
>>> bookmarks. hg pull still pulls only a specific bookmark using the -B option.
>> 
>> But what if I have changed some bookmark, will pull move this bookmark to new
>> location? This doesn't seem that desirable. Maybe we want to have specific
>> notation for remote bookmarks right at this point? Like 'path/bookmarkname'.
>> 
> I want to introduce remote bookmarks as soon as possible. at the moment
> there are 3 different situations in which bookmarks are moved or not.
> 
> if we find a remote bookmark with the same name that points to a
> descendant of your local bookmark with that name, we will move the local
> bookmark forward to this point. if it points to a point that is not an
> descendant we warn you that this is a diverging bookmark and will not
> touch it. if there is no remote bookmark with that name and if its the
> current bookmark we will move it forward to the current branch tip.
> 
> I don't think that is a problem at all. usually once you decided to push
> a bookmark you like to have this behaviour. I don't think name clashes
> are often and in that case you will probably just rename your local
> bookmark once and the problem goes away. it's unlikly that you have the
> same bookmark name on remote and local with different meanings.

The current git-style usage of bookmarks relies on bookmarks being local. Consider: I have 'origin/master' and 'master'  bookmarks, which are advanced independently (and still would be after this patch series). The problem is that I decidedly _don't_ want to push 'origin/master': that would result in the remote repo having a redundant marker of its own 'master', possibly overwriting the marker of the remote's _own_ origin's 'master'.

I'll note that the name component of the bookmark isn't local, but the _path_ component ('origin') and the changeset to which the path+name points, are local (in this current usage). Not sure how to reconcile this with your patch series. Perhaps for now, lacking distinct path-marked remote bookmarks, we could do the following (on pull):

1. If a remote bookmark doesn't exist locally, pull it.
2. If a remote bookmark exists locally, don't auto-advance it.
3. If a remote bookmark exists locally and `-B <bookmark>` option is passed, advance that bookmark.

This doesn't totally solve the problem for this use case: when you clone a repo that has an 'origin/master' bookmark, your clone now points to the remote's _origin_'s master. But that can't be solved short of either keeping bookmarks local unless explicitly pushed/pulled, or introducing a way of marking certain bookmarks as local. The latter seems like too much conceptual complexity.

pacem in terris / mir / shanti / salaam / heiwa
Kevin R. Bullock