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