Re: [PATCH v3 1/2] merge-recursive: option to disable renames

From: Felipe Gonçalves Assis <felipeg.assis@gmail.com>
Date: Feb 17, 2016, 03:16 UTC
Message-ID: <CALMa68peGr3TsS8bTpsG3Xt5U5VtbLhKryhOSLEYaNZyjRuSgQ@mail.gmail.com>
In-Reply-To: <CAPig+cRCKQ8Vpr11XB-MSNsjDXjMHstaEAz333nMZxuKC8xmEg@mail.gmail.com>

On 16 February 2016 at 23:41, Eric Sunshine <sunshine@sunshineco.com> wrote:

Show 22 quoted lines

> On Tue, Feb 16, 2016 at 8:11 PM, Felipe Gonçalves Assis
> <felipeg.assis@gmail.com> wrote:
>> The recursive strategy turns on rename detection by default. Add a
>> strategy option to disable rename detection even for exact renames.
>>
>> Signed-off-by: Felipe Gonçalves Assis <felipegassis@gmail.com>
>> ---
>> diff --git a/Documentation/merge-strategies.txt b/Documentation/merge-strategies.txt
>> @@ -81,8 +81,14 @@ no-renormalize;;
>> +no-renames;;
>> +       Turn off rename detection.
>> +       See also linkgit:git-diff[1] `--no-renames`.
>> +
>>  rename-threshold=<n>;;
>>         Controls the similarity threshold used for rename detection.
>> +       Re-enables rename detection if disabled by a preceding
>> +       `no-renames`.
>
> I'm not sure that it is necessary to mention the "last one wins" rule
> here, but if you do so, does --no-renames documentation deserve
> similar treatment?
>

It is not so much about the "last one wins" rule, but about the fact that, given the sub-optimal name, it is not obvious that this option even enables renaming. The wording is just the best way I found to explain that without creating additional confusion.

I will apply your suggestion on the second commit. Please see the next patch proposal and tell what you think.

Thanks, Felipe