terminology confusion: bookmark vs named head

[anatoly techtonik]

On Tue, Dec 17, 2013 at 3:20 AM, Stephen Lee <sphen.lee at gmail.com> wrote:
> On Mon, Dec 16, 2013 at 8:28 PM, Martin Geisler <martin at geisler.net> wrote:
>> anatoly techtonik <techtonik at gmail.com> writes:
>>
>>>  On Mon, Dec 16, 2013 at 4:54 AM, Stephen Lee <sphen.lee at gmail.com> wrote:
>>>
>>>> The only command that causes bookmark confusion for me is a bare (no
>>>> arguments) "hg up" which moves the active bookmark to the head you
>>>> are updating to. This has been a point of discussion in the past, but
>>>> no conclusions were made.
>>>
>>> Even "hg push/pull" still doesn't look great for my original purpose
>>> for bookmarks and "hg up" as you describe is really awful, but I guess
>>> it at least doesn't move bookmarks between named branches?
>>
>> Only because 'hg up' itself doesn't move between named branches. It's
>> important to understand that the behavior of bookmarks is bolted onto
>> the existing behavior of Mercurial -- for better and for worse.
>>
>> I've had great trouble with the distinction between 'hg up' and 'hg up
>> default' introduced by bookmarks. I'm only very rarely using 'hg up'
>> without giving it an explicit revision. My thinking is something like
>> this: why would I want to update without telling update where to go to?
>> After a pull, I look at the graph and decide where to go. This meant
>> that I again and again "lost" (deactivated and left behind) my active
>> bookmark. That is probably a problem with my workflow and maybe
>> bookmarks work fine if you've been used to them from the beginning.
>>
>
> It's not a problem with your workflow Martin - we have been having
> this problem too. :(
>
> In an all bookmarks workflow, "hg up" aborts with "all heads are
> bookmarked" so you always have to name the head, and the move
> behaviour never triggers.
> This means a linear merge ('fast-forward merge' from Git) needs to be
> done as two steps "hg up x; hg book y" which is less than ideal.
>
> As you said: bookmark behaviour is bolted onto normal Mercurial
> behaviour. Mercurial does not distinguish the "checkout" usage of "hg
> up" from it's linear merge usage and hence bookmarks cannot either.

Seems like I'm stepping on these rakes just now with hg-git.

I made three "feature branches"
(https://github.com/techtonik/recordscreen/branches)and mastered in
moving commits between them with Mercurial without making backups
of clones in fear that I'll break something again. Now I've tried to merge
all my feature branches into "master".

    $ hg up -r master
    ...
    $ hg merge fixes
    abort: nothing to merge
    (use: 'hg update' or check 'hg heads')

That's because "fixes" is a descendant of "master". These bookmarks
are not intuitive, and even more confusing with 'hg up'. My branches
were:

    fixes:33
    master:29  (common ancestor)
    vlc:37  (experimental, don't want to merge)
    webm:34    (need to merge on top of fixes)

I run 'hg up' and now my master is at 'vlc', which is not what I want.
I reverted, run 'hg up -r fixes', and 'master' didn't change. So I had to
do `hg bookmark -f master'

That's pretty much a syntax sugar for 'git reset and co' commands,
not something that is friendly to user, which needs totally care to
understand how bookmarks work, how git branches work and what
state his repository is now in.

The final recipe to merge three feature branches to 'master':
    $ hg up -r fixes
    $ hg bookmark -f master   # only when master in ancestor of fixes
    $ hg merge webm

And it seems that information that I've merged from "fixes" to master
is lost, but I don't know - it may be the way Git works.
--
anatoly t.