问题
I install latest git and configure it to highlight moved code:
$ git config diff.colormoved default
Here is how it looks when code is moved (see 1->2)
But 3-4 is not highlighted as moved code.
Here is standalone changes:
回答1:
See the documentation for --color-moved
/colormoved
in git-diff(1):
--color-moved[=<mode>]
Moved lines of code are colored differently. It can be changed by the
diff.colorMoved
configuration setting. The<mode>
defaults tono
if the option is not given and tozebra
if the option with no mode is given. The mode must be one of:
no
Moved lines are not highlighted.default
Is a synonym for zebra. This may change to a more sensible mode in the future.plain
Any line that is added in one location and was removed in another location will be colored with color.diff.newMoved. Similarly color.diff.oldMoved will be used for removed lines that are added somewhere else in the diff. This mode picks up any moved line, but it is not very useful in a review to determine if a block of code was moved without permutation.zebra
Blocks of moved text of at least 20 alphanumeric characters are detected greedily. The detected blocks are painted using either the color.diff.{old,new}Moved color or color.diff.{old,new}MovedAlternative. The change between the two colors indicates that a new block was detected.dimmed_zebra
Similar to zebra, but additional dimming of uninteresting parts of moved code is performed. The bordering lines of two adjacent blocks are considered interesting, the rest is uninteresting.
specifically, that the default is zebra
and that it detects
Blocks of moved text of at least 20 alphanumeric characters
. my $ctx = shift;
doesn’t contain at least 20 alphanumeric characters. If you use git diff --color-moved=plain
, or add # ten more ANs
to the end of the line, your example will be highlighted as moved.
回答2:
Note there is another scenario where colored moved code (when the amount of code is enough) would have an improper side-effect:
"git diff --color-moved --cc --stat -p
" did not work well due to funny interaction between a bug in color-moved and the rest.
This has been fixed in Git 2.21 (Feb. 2019)
See commit dac03b5, commit 04b19fc, commit 8290faa, commit 8817f0c, commit 48edf3a, commit 426fd36 (24 Jan 2019) by Jeff King (peff).
(Merged by Junio C Hamano -- gitster -- in commit 5d2710b, 05 Feb 2019)
diff: clear emitted_symbols flag after use
There's an odd bug when "
log --color-moved
" is used with the combination of "--cc --stat -p
": the stat for merge commits is erroneously shown with the diff of the next commit.The included test demonstrates the issue.
Our history looks something like this:A-B-M--D \ / C
When we run "
git log --cc --stat -p --color-moved
" starting atD
, we get this sequence of events:
The diff for
D
is using-p
, sodiff_flush()
calls intodiff_flush_patch_all_file_pairs()
. There we see thato->color_moved
is in effect, so we pointo->emitted_symbols
to a static local struct, causingdiff_flush_patch()
to queue the symbols instead of actually writing them out.
We then do our move detection, emit the symbols, and clear the struct. But we leaveo->emitted_symbols
pointing to our struct.Next we compute the diff for
M
. This is a merge, so we use the combined diff code.
Infind_paths_generic()
, we compute the pairwise diff between each commit and its parent. Normally this is done withDIFF_FORMAT_NO_OUTPUT
, since we're just looking for intersecting paths. But since "--stat --cc
" shows the first-parent stat, and since we're computing that diff anyway, we enableDIFF_FORMAT_DIFFSTAT
for the first parent. This outputs the stat information immediately, saving us from running a separate first-parent diff later.
But where does that output go? Normally it goes directly to stdout, but becauseo->emitted_symbols
is set, we queue it. As a result, we don't actually print the diffstat for the merge commit (yet), which is wrong.
- Next we compute the diff for
C
. We're actually showing a patch again, so we end up indiff_flush_patch_all_file_pairs()
, but this time we have the queued stat from step 2 waiting in our struct.
We add new elements to it forC
's diff, and then flush the whole thing. And we see thediffstat
fromM
as part ofC
's diff, which is wrong.So triggering the bug really does require the combination of all of those options.
来源:https://stackoverflow.com/questions/48165922/why-moved-code-is-not-colored-in-git-diff