W dniu 06.09.2016 o 19:03, Stefan Beller pisze:
> On Tue, Sep 6, 2016 at 7:05 AM, Jakub Narębski <jnareb@xxxxxxxxx> wrote:
>> If not for `color.moved`, I would have thought that instead of adding
>> new command line option `--color-moved` (and the fact that it is on
>> by default), we could simply reuse duplication of code movement
>> detection as a signal of stronger detection, namely "-M -M" (and also
>> "-C -C" to handle copy detection) that git-blame uses...
>
> Can you please elaborate on how you'd use that as a user?
>
> The -M and -C options only operate on the file level, e.g.
> these options are very good at things introduced via:
>
> git mv A B
> $EDIT B # only a little.
>
> So these options make no sense when operating only on one
> file or on many files that stay the same and only change very little.
>
> The goal of my patch here is to improve cases like 11979b98
> (2005-11-18, http.c: reorder to avoid compilation failure.)
>
> In that case we just move code around, not necessarily across file
> boundaries.
>
> So that seems orthogonal to the -M/-C option as it operates on another
> level. (file vs line)
The idea for an alternative way of turning on color marking of moved
lines was to follow an example of "git blame", where _doubling_
of a command means more extensive move / copy detection (accompanied
by new values for `diff.renames`).
>From git-blame(1) manpage:
-C|<num>|
In addition to -M, detect lines moved or copied from other files
that were modified in the same commit. [...]. 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.
Color marking of moved lines may be considered enhancing of exiting
whole-file movement and whole-file copy detection.
But it is not a good UI if the feature is to be turned on by default.
Your proposal of adding `--color-moved` and `color.moved` is better.
> In another email you asked whether this new approach works in the
> word-by-word diff, which it unfortunately doesn't yet, but I would think
> that it is the same problem (line vs word granularity).
I don't know how it is done internally, but I think word diff is done
by using words (as defined by `diff.<driver>.wordRegex`) in place
of lines...
Best,
--
Jakub Narębski