Re: [PATCH v1 2/2] merge: Add merge.aggressive config setting

> Ben Peart <peartben@gmail.com> writes:
> 
>> That said, it makes sense to me to do
>>> this when rename detection is turned off.  In fact, I think you'd
>>> automatically want to set aggressive to true whenever rename detection
>>> is turned off (whether by your merge.renames option or the
>>> -Xno-renames flag).
>>> ...
>>
>> While combining them would work for our specific use scenario (since
>> we turn both on already along with turning off merge.stat), I really
>> hesitate to tie these two different flags and code paths together with
>> a single config setting.
> 
> The cases that non-agressive variant leaves unmerged are not
> auto-resolved only because marking them as merged will rob the
> chance from the rename detection logic to notice which ones are
> "new" paths that could be matched with "deleted" ones to turn into
> renames.  If rename deteciton is not done, there is no reason to
> leave it non aggressive, as "#1 = missing, #2 = something and #3 =
> missing" entry (just one example that is not auto-resolved by
> non-agressive, but the principle is the same) left unmerged in the
> index will get resolved to keep the current entry by the post
> processing logic anyway.
> 
> In fact, checking git-merge-resolve would tell us that we already
> use "aggresive" variant there unconditionally.
> 
> So, I think Elijah is correct---there is no reason not to enable
> this setting when the other one to refuse rename detection is in
> effect.
>