elmentary (watson): merge (named) branches and/or bookmarks

[David Demelier]

2016-12-18 9:35 GMT+01:00 Arne Babenhauserheide <arne_bab at web.de>:
>
> Uwe Brauer writes:
>
>> Sigh, for me this is another reason to concentrate on named branches,
>> since they behave much more as I expect them to behave. (Besides the
>> evolve extension makes named branches much more flexible.)
>
> Same for me. And I wish I could tell hg-git to use named branches — but
> I know that this doesn’t work.
>
> The trouble you run into is what git calls fast-forward merge, by the
> way. It’s not an actual merge, just a pointer movement.
>
> Maybe we could tell hg merge <bookmark-on-a-child> to simply
> fast-forward, too. It’s what the user requested with "hg merge" (make A
> part of B), though it’s not what merge actually does with the history.

I myself use the following workflow:

If the feature is draft:

hg up feature
hg rebase -b feature -d @
hg book -f @
hg book -d feature

If the feature is public it depends where the bookmark feature is. But
usually it looks like

hg up @
hg merge feature
hg book -d feature

Or possibly if linear:

hg up feature
hg book -f @

I recommend using @ instead of master as it is activated by default on
new clones.

-- 
Demelier David