Closed un-def closed 6 years ago
Thank you for your pull request and I am sorry for not responding for so long!
The problem with this is, it is changing default behaviour of the package without an (easy) option to switch it back. While I understand that ignoring moved code could be helpful I do not necessarily expect that behaviour.
Besides that are expecting of the user to know what the arguments -w -M20
are doing.
Therefore is my proposal is, to remove the command line argument options and add two boolean option:
-w
-M
Would you be ok with that?
Yes, it's definitely OK, but a boolean option for -M
wouldn't be enough, it should be a numeric input/numeric+checkbox combination, because there is an optional parameter:
-M|<num>|
[...]
<num> is optional but it is the lower bound on the number of alphanumeric characters that Git must detect as moving/copying within a file for it to associate those lines with the parent commit. The default value is 20.
Also, there is another useful option:
-C|<num>|
In addition to -M, detect lines moved or copied from other files that were modified in the same commit. This is useful when you reorganize your program and move code around across files. When this option is given twice, the command additionally looks for copies from other files in the commit that creates the file. When this option is given three times, the command additionally looks for copies from other files in any commit.
<num> is optional but it is the lower bound on the number of alphanumeric characters that Git must detect as moving/copying between files for it to associate those lines with the parent commit. And the default value is 40. If there are more than one -C options given, the <num> argument of the last -C will take effect.
I think you have a better vision how to implement these options in plugin config.
This PR adds option for
git blame
command line arguments. Default is-w -M20
, as proposed in https://github.com/kucherenko/blamer/issues/2