Re: [PATCH v2 03/10] t/unit-tests: convert reftable block test to use clar

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Patrick Steinhardt <ps@xxxxxx> writes:

>     -M[<n>], --find-renames[=<n>]
>         Detect renames. If <n> is specified, it is a threshold on the similarity index (i.e. amount
>         of addition/deletions compared to the file’s size). For example, -M90% means Git should
>         consider a delete/add pair to be a rename if more than 90% of the file hasn’t changed.
>         Without a % sign, the number is to be read as a fraction, with a decimal point before it.
>         I.e., -M5 becomes 0.5, and is thus the same as -M50%. Similarly, -M05 is the same as -M5%.
>         To limit detection to exact renames, use -M100%. The default similarity index is 50%.
>
> What you probably wanted to say is `--find-renames=90%`, but without the
> percentage sign it is read as a fraction, where 1 means "exact copy" and
> 0 means "all different".

I am confused.  -M<number> without trailing %-sign is taken as
fraction against 1 followed by the same number of '0' has the
<number> has digits.  -M5 is 5 over 10, -M50 is 50 over 100.  -M90
is 90 over 100, so -M90 and -M90% should mean the same thing.

But you are right.  When you want to claim your pre- and post- image
files still correspond with each other in a meaningful way, even
after making extensive change, you would want to _lower_, not raise,
your similarity threshold.  If the default is -M50, then -M90 would
be a useful option to reject what Git (mistakenly) thinks are renames
and tell it to instead consider they are removals and creations.

THanks.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux