[PATCH STABLE checkunknown] merge: respect checkunknown/checkignored when force is True

Pierre-Yves David pierre-yves.david at ens-lyon.org
Sat Jan 30 08:23:43 CST 2016



On 01/23/2016 01:54 AM, Siddharth Agarwal wrote:
> On 1/22/16 16:16, Pierre-Yves David wrote:
>>
>>
>> On 01/22/2016 02:08 PM, Siddharth Agarwal wrote:
>>> # HG changeset patch
>>> # User Siddharth Agarwal <sid0 at fb.com>
>>> # Date 1453500273 28800
>>> #      Fri Jan 22 14:04:33 2016 -0800
>>> # Branch stable
>>> # Node ID ab22c1449e8591635e545b9edea6c8d023b6a606
>>> # Parent  158bdc8965720ca4061f8f8d806563cfc7cdb62e
>>> # Available At http://42.netv6.net/sid0-wip/hg/
>>> #              hg pull http://42.netv6.net/sid0-wip/hg/ -r ab22c1449e85
>>> merge: respect checkunknown/checkignored when force is True
>>>
>>> checkunknown and checkignored are currently respected for updates and
>>> regular
>>> merges, but not for certain kinds of rebases. To be precise, they aren't
>>> respected for rebases when:
>>>
>>> (1) we're rebasing while currently on the destination commit, and
>>> (2) an untracked or ignored file F is currently in the working copy, and
>>> (3) the same file F is in a source commit, and
>>> (4) F has different contents in the source commit.
>>>
>>> This happens because rebases set force to True when calling
>>> merge.update.
>>> Setting force to True makes a lot of sense in general, but it turns
>>> out the
>>> force option is overloaded: there's a deprecated '--force' option in
>>> merge that
>>> allows you to merge in outstanding changes, including changes in
>>> untracked
>>> files. Those are the semantics that _checkunknownfiles follows, and
>>> that's
>>> covered by the 'cm' action.
>>>
>>> I think the behavior during rebases when checkunknown is 'abort' (the
>>> default)
>>> is wrong -- we should abort on or overwrite differing untracked
>>> files, not try
>>> to merge them in. However that would likely be a pretty big BC
>>> change, so I'm
>>> disinclined to do that for stable. I think getting the semantics for
>>> 'warn' and
>>> 'ignore' correct before they're set in stone is more important.
>>
>> From reading this, it seems like `hg merge --force` (deprecated) and
>> `hg rebase` both us a `force=True` parameters down the stack to carry
>> sightly different meaning.
>>
>> The current behavior is built around the `hg merge --force` use case.
>> You series seems to be changing the behavior of this `force=True` to
>> match something fitting the `hg rebase needs`. Correct?
>
> Yes, that's exactly correct.
>
>> If so, could we not get a `forcemerge=True` and a `force=True`
>> parameter that strictly disambiguates the intent here?
>
> That's my plan for after the freeze. I think doing this before the
> freeze is going to be too disruptive.

For the record, we talked to each other in person and we decided to 
undocument the new options until the behavior have been fixed (in 3.8).

Patch undocumenting them have landed.

-- 
Pierre-Yves David


More information about the Mercurial-devel mailing list