Ben Peart <peartben@xxxxxxxxx> 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.
