[PATCH 0 of 2 RFC] forward current bookmark on hg update

[Idan Kamara]

On Wed, Apr 20, 2011 at 11:41 PM, Matt Mackall <mpm at selenic.com> wrote:

> On Wed, 2011-04-20 at 23:24 +0300, Idan Kamara wrote:
> > On Wed, Apr 20, 2011 at 10:51 PM, Kevin Bullock <
> > kbullock+mercurial at ringworld.org> wrote:
> >
> > > On Apr 20, 2011, at 12:59 PM, Idan K wrote:
> > >
> > > On Wed, Apr 20, 2011 at 8:18 PM, Kevin Bullock <
> > > kbullock+mercurial at ringworld.org> wrote:
> > >
> > >> On Apr 20, 2011, at 11:29 AM, Idan K wrote:
> > >>
> > >> If I'm working on something using a bookmark and I incidentally decide
> to
> > >> pull,
> > >> that doesn't mean my next step would be a 'hg update' (or merge for
> that
> > >> matter).
> > >> So if I continue working without a hg update, I basically need to 'hg
> > >> bookmark -f...' to
> > >> get it back.
> > >> I would expect it to move when (if) I actually decide to update my
> working
> > >> copy to what I just pulled.
> > >>
> > >>
> > >> If I'm working on a branch that's bookmarked (we'll call it
> 'feature'),
> > >> and someone else has newer work on that branch, it makes sense to
> update the
> > >> (shared) bookmark on pull.
> > >>
> > >
> > > I still see this differently. Yes, there might be newer work on that
> branch
> > > that I'd be interested in at some point. I'm not sure pulling is the
> right
> > > one. I see this similarly to how pull isn't 'pull + update' (in the
> > > 'fast-forward' case).
> > >
> > >
> > > But if the bookmark is shared, then it still seems to me that the right
> > > point at which to update the shared status is exactly when the rest of
> the
> > > sharing happens—on pull. Right now there is no way to have a separation
> > > between a shared bookmark and an unshared bookmark of the same name.
> With
> > > this series, all we do is go from the situation where I don't know the
> > > current state of my own work, to one where I don't know the current
> state of
> > > upstream work. In the former (current) case, I have more contextual
> > > information to work with to resolve the confusion.
> > >
> >
> > My logic is kind of the opposite on that last sentence. If I'm in the
> middle
> > of a feature, with a corresponding bookmark 'feature', then a pull will
> only
> > cause myself to lose track of my own work (by moving the bookmark for
> me).
> > Plus, it kind of breaks the notion of a `current bookmark`, since I have
> to
> > follow up with a `hg update` to get back to it. What if I decide to do
> some
> > commits, then merge? I just lost my feature marker.
> >
> > I think the main problem here is the lack of separation between local and
> > remote bookmarks. Since Mercurial treats them all the same, it has to
> resort
> > to these kind of decisions that some feel uncomfortable with.
>
> I think you're confusing the issue.
>
> If the remote repo has a bookmark X that is a descendant of your local
> bookmark X, then X -is not your bookmark- (as evidenced by the fact that
> someone else has moved it and you haven't). In this case, Mercurial is
> right to move X on pull.
>

I still find this behavior confusing. But I don't feel very strongly about
this and like I said it's not the reason I initially sent this series.


> I think the real issue is what happens when:
>
> - you've got local bookmark X
> - you pull new changesets descended from X
> - remote has never heard of your bookmark.
>
> Do we linearly advance the bookmark on pull or not?
>

We do in 1.8.1. Seemed to have been fixed by this
http://selenic.com/repo/hg/rev/80d6e1f63ed9
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20110421/5e8f92f4/attachment.htm>