Bookmarks with hg update question

[Scott Palmer]

> On Jun 28, 2016, at 5:48 PM, Sean Farley <sean at farley.io> wrote:
> 
> <snip>
> There is a metric ton of points to address here but that will take too
> long so I'll just reply to a few of the more important ones.
> 
> The proposed solution is to treat bookmarks as more-or-less a head. 'hg
> up' on an active bookmark will not move you anywhere nor deactivate the
> bookmark. The reason for this is that it's the same behavior as named
> branches.

But they AREN’T named branch.  They don’t have to behave the same, they just have to behave reasonably.  E.g. I can move a bookmark between different named branches if I want.  They are a different thing.  In your example below, I don’t think you can put a ‘C4’ as a descendant of A or B.  You may wish to relocate a bookmark like that.  It depends on the meaning you assign to a particular bookmark. (And I think we all agree that sort of movement should require it be forced.)

> Having three stacked named branches is my usual example:
> 
> A1 <- A2 <- A3 <- B1 <- B2 <- C1 <- C2 <- C3
> 
> If I am at A3, then 'hg up' will not move me anywhere. Yet, if this was
> a bookmark work, it would move me to C3 which is just bonkers.

Well here I have to wonder what is really bonkers… The "stacked named branches” are a rather strange configuration.

In this case the work on A is already included in B and C, so continuing it on C3 is not necessarily bonkers. If B and C are features that are complete, it may not be unreasonable to add a tweak to A on C3.

> 
> Your statement "move the active bookmark forward ... as far as we can"
> is non-deterministic and not possible. Imagine 'hg pull -r BOOKMARK^'.
> You do not have the information you need "as far as possible”.

Got it.  I should have realized that.

> By making
> bookmark movement explicit, we fix this insanely complicated behaviour.

Fix which behaviour, my rather complicated “as far as we can” thing,.. which I now agree is insane, or the original bookmark behaviour which is not complicated, but sometimes a bit too simple for it’s own good?

> I've added a skeleton of an outline here:
> 
> https://www.mercurial-scm.org/wiki/BookmarkUpdatePlan
> 
>> We treat the ‘@‘ bookmark as the destination revision if we can get to it by moving ahead without jumping branches.
> 
> That's usually not enough state.

Could you elaborate on this aspect?  Because my thinking now is that this is the more sane approach to what it means to move a bookmark ahead.


> For this, I implemented 'tracking' in
> my remotebookmarks extension. I'll be slowly moving parts of that into
> core soon (hopefully).
> 
>> <snip>
>> 
>> Of course, if a bookmark is NOT active, let “hg update” tries to go to ‘tip’ as before.
> 
> Point of correction: 'hg update' has always gone to the highest revision
> of the current named branch.


Yes, ‘tip’ was inaccurate, but your correct is not accurate either.  A named branch can have multiple heads and “hg update" does not jump to a different topological branch.  The highest revision of the current named branch might be on a different topological branch from the current revision, in which case “hg update” will not take you there.

I’ll go check out your proposal…
… back

I’m not keen on breaking the backward compatibility, so I would would suggest that it be done initially with a switch in .hgrc and then become the norm for the next major revision.

When issuing “hg update” with an active bookmark there must be a warning that you are on an active bookmark and that if you really want to move it you need to force it with "-B .”
(I wonder if adding a force option to update, as in “hg update -f”, makes sense here?)

As long as “hg update -B .” or whatever it is keeps the behaviour that it won't jump to a different topological branch, I will adapt.

If we can sneak in a way to update the active bookmark to the ‘@‘ bookmark (if present and a descendant of the current revision), that would be exactly what I need to make my workflow simple.  Because ‘@‘ is the “default” revision of a new clone, it is a logical point to consider as a “neutral” revision that doesn’t belong to some feature branch.

If I create and activate a bookmark for a feature, but I haven’t committed my work before some other changes are completed, I would naturally want to move my bookmark before committing. That way I rebase my uncommitted changes and have a linear set of changes.  That has always been my use case for the current bookmark behaviour.  If I’ve already committed a change, “hg update” is harmless because it won’t jump branches.


Regards,

Scott