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

[Idan Kamara]

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.


> [...]
>
>>
>> Also, I may be thinking ahead here but if we ever introduce bookmark
>> namespaces
>> (per entry in paths for example), the way I see things the consequence of
>> a pull would be to move
>> the remote bookmark rather than the local one (much like git does for that
>> matter).
>> Only if I follow up with a 'hg upd/merge remote/bookmark-name', the local
>> bookmark should be moved.
>>
>>
>> I'm not keen on on having `update` move bookmarks. So I'm -1 on this
>> series. As Alexander pointed out, `update` should be a working-dir-only
>> operation (debate on the current functioning wrt subrepos notwithstanding).
>>
>> Giving `merge` the ability to do so, OTOH, makes sense to me, even in the
>> trivial 'merge'-with-descendent case (which Git calls a fast-forward merge).
>>
>
> But this is exactly what I suggested. In the scenario I was talking about
> `hg update` is the equivalent of a git fast-forward merge. If hg had
> fast-forward merges rather than plain `hg update`, my suggestion would only
> affect `hg merge`.
>
>
> A special-case of merge behavior was recently implemented for named
> branches, to allow you to do a (true) merge with a descendant on a different
> branch. Since this wouldn't involve a true merge, it might be better to add
> something like `hg update --bookmarks`, so that an update _can_ do this. But
> doing it without some indication from the user feels wrong to me.
>

When I thought of this change I was mainly thinking that when I'm on a
bookmark and I update to a descendant, it's obvious that I'd like the
bookmark to move with me.
I can't think of a situation where I would want to bookmark to stay where it
was so in my eyes the indication from the user is his choice to `hg update`.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20110420/3d0d6a9f/attachment.htm>