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

[Ben Peart <peartben@gmail.com>]

On 4/24/2018 7:57 PM, Junio C Hamano wrote:
> 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.
> 

Thank you. I understand this description and it make sense to me.  I'm 
unfamiliar with the merge code so have to rely on you who are the 
experts for a sanity check.

I will remove the separate merge.aggressive config setting and instead, 
set the aggressive flag when the renames is turned off (whether by the 
new merge.renames setting or by the -Xno-renames flag) as Elijah suggests.