[PATCH 2 of 2] bookmarks: on a bare merge use config to choose target or choose @

[Stephen Lee]

On Wed, Mar 12, 2014 at 9:16 AM, Matt Mackall <mpm at selenic.com> wrote:
> On Tue, 2014-03-11 at 22:20 +1100, Stephen Lee wrote:
>> # HG changeset patch
>> # User Stephen Lee <sphen.lee at gmail.com>
>> # Date 1394536638 -39600
>> #      Tue Mar 11 22:17:18 2014 +1100
>> # Node ID 44db1ede5c65a0265203f5df063049813d2da8c8
>> # Parent  ff0ffb9855d8e88fbcce967867f2a373eaac581f
>> bookmarks: on a bare merge use config to choose target or choose @
>>
>> When running "hg merge" if there is an active and current bookmark
>> look in config for a key "bookmarks.<name>.track" and it will name
>> the bookmark we should merge with.  If the key is missing, and an
>> @ bookmark exists, merge with it instead.
>
> I have no idea what the rationale here is, but it sounds like a behavior
> change that's going to cause me to accidentally do horrible horrible
> things like merge @ into stable without realizing it. This is worrisome.

I will try to explain the rationale (sorry, these two patches should
have been marked RFC).

Firstly this patch is the less important of the two - the update patch
is fixing a real functionality hole.
This patch was mostly to make the same changes to merge as I made to update.

Currently there is no way to move the active bookmark to a descendant
rev, and update to that rev in a single command _unless that rev
happens to be tip_.
(What Git calls a fast-forward merge).
This is a common thing to want to do in a bookmark-as-feature-branch workflow.
It is a sore point for Git people coming to Mercurial and causes
confusion for beginners: "hg merge @" Just-Works, but "hg up @"
usually is not what you meant...

My idea is to allow a per-bookmark config setting to name the bookmark
that should be used as the target of a bare "hg up".
I called it a 'tracking' bookmark (which is also the term Git uses)
because it implies that your bookmark is 'following behind' some other
bookmark.

A secondary idea is to assume @ if the setting is missing.
In a bookmark workflow where @ is the mainline branch this is a
sensible default, and much less confusing that the current behaviour.
Also @ is already used as the update target of a clone.

In a non-bookmark workflow, the new logic only triggers if you have an
active bookmark and an @ bookmark (which should be rare in a
non-bookmark workflow).

The logic is this patch (for merge) is the same. If you have an active
bookmark and run a bare merge, currently it will abort unless there is
a divergent bookmark.
In this patch it will select the 'tracked' bookmark, or @.
If you have no active bookmark there is no behaviour change (it won't
magically merge @ into stable).

>
> Also, this sort of patch should probably be split into two patches:
>
> - create surprise merge accidents
> - do some mysterious tracking thing

I can split the patch apart if you would prefer - but before that I
would like to get comments/suggestions from other contributors about
the entire idea.
There were lots of people commenting on the thread last time I brought
up this issue!
The only conclusion I came to was "make a patch and go from there".

Steve