[PATCH 1 of 1] rebase: hard-code 'hg pull --rebase' to use internal:fail merge tool

[Steve Borho]

On Thu, May 26, 2011 at 1:17 PM, Adrian Buehlmann <adrian at cadifra.com> wrote:
> On 2011-05-26 20:12, Matt Mackall wrote:
>> On Thu, 2011-05-26 at 19:50 +0200, Adrian Buehlmann wrote:
>>> On 2011-05-26 19:00, Matt Mackall wrote:
>>>> On Thu, 2011-05-26 at 13:58 +0200, Adrian Buehlmann wrote:
>>>>> # HG changeset patch
>>>>> # User Adrian Buehlmann <adrian at cadifra.com>
>>>>> # Date 1306235416 -7200
>>>>> # Node ID c365abdd8ec568b5aeaa658a7765c5969c005801
>>>>> # Parent  0969d91fad5cad68bcf60f85e2e3286acd11ab52
>>>>> rebase: hard-code 'hg pull --rebase' to use internal:fail merge tool
>>>>>
>>>>> If there were changes that modified the same files in both the local and the
>>>>> pulled line of development, the rebase part of 'pull --rebase' will then
>>>>> be aborted (example):
>>>>
>>>> This breaks perfectly reasonable rebases that would normally fly by
>>>> without any interaction because the internal merge just worked, while
>>>> internal:fail doesn't even try. I really can't see us changing the
>>>> default behavior here.
>>>>
>>>
>>> Rather a bit off-topic, but:
>>>
>>> FWIW, TortoiseHg 2.X uses "internal:fail" by default in it's merge dialog:
>>>
>>> Here is what it does (copied from it's command log)
>>>
>>> % hg --repository <path> merge --verbose --tool=internal:fail 8
>>> resolving manifests
>>> getting bar
>>> 1 files updated, 0 files merged, 0 files removed, 1 files unresolved
>>> use 'hg resolve' to retry unresolved file merges or 'hg update -C .' to abandon
>>> [command returned code 1 Thu May 26 19:32:07 2011]
>>>
>>> The user is then notified that there were conflicts that need to be resolved,
>>> and the user is presented a resolve dialog with a button "Mercurial Resolve".
>>> If the user clicks that button, TortoiseHg runs hg resolve with "internal:merge"
>>> on the unresolved files.
>>
>> This seems wrong to me: it's not in agreement with the usual meaning of
>> conflict. A conflict is anything a merge can't resolve without user
>> input.
>>
>> We should not bother users about files that can be merged automatically
>> and internal:fail fails before even attempting a merge. It's intended
>> use is to avoid attempting to merge things like binaries.
>
> I like that new behavior of thg 2.X. It's very similar to how Perforce
> works.
>
> FWIW: I wasn't even involved in that decision.

Judging by feedback, the internal:fail default behavior is popular
with new users.  For more experienced Mercurial users, there is an
option to use internal:merge by default.

-- 
Steve Borho