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

[Pierre-Yves David]

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?

If so, could we not get a `forcemerge=True` and a `force=True` parameter 
that strictly disambiguates the intent here?

-- 
Pierre-Yves David