[BUG] Move tracking in git diff is not as good as in git status
- From
- Scott Schmit <i.grok@comcast.net>
- Date
- Feb 5, 2015, 06:11 UTC
- Message-ID
- <20150205061142.GA31599@odin.ulthar.us>
In my use of git, I've noticed that "git status" is a lot better at tracking moves and renames than "git diff", and this has recently caused me a lot of headaches because a large number of moves were made in a single commit, and it was very difficult to figure out which moves were right and which were wrong.
I was using a fairly old version of git (1.7.11), but was able to reproduce it on git 2.2.1.
Here's a reproduction recipe:
#!/bin/sh -x
# Fill in your git.git working tree path here: GIT_GIT_REPO=
if [ -z "$GIT_GIT_REPO" ]; then
echo Fill in GIT_GIT_REPO
exit 1
figit init mv-test cd mv-test/
# Pick two sample files of non-trivial size, since files that are too small # never get tracked as moves. cp ${GIT_GIT_REPO}/Documentation/asciidoc.conf . cp ${GIT_GIT_REPO}/Documentation/blame-options.txt . git add * git commit -m "Start with two files from git.git/Documentation"
# Now rename them to something. Using 1 & 2 because they're nice & short. git mv asciidoc.conf 1 git mv blame-options.txt 2
# Status sees the rename git status
# So does the summary on the commit git commit -m "Rename both files"
# And move tracking works git diff -M --stat --summary HEAD~.. git diff -C --stat --summary HEAD~..
# Now "shift" the files git mv 2 3 git mv 1 2
# Status knows what's going on git status
# So does commit git commit -m "2=1;3=2;"
# Neither of these commands get it (but -C gets a glimmer of the truth) git diff -M --stat --summary HEAD~.. git diff -C --stat --summary HEAD~..
# Swap the files in place git mv 3 tmp git mv 2 3 git mv tmp 2
# Status gets it git status
# Commit understands git commit -m "Swap 2 & 3"
# Diff has no idea git diff -M --stat --summary HEAD~.. git diff -C --stat --summary HEAD~..
---
At first, I thought it was because the "git mv" command recorded something in the index that's lost once the commit happens.
To check if that was so, I went back to the commit in question, did a "git reset HEAD~1" and "git add -A ." and git status understood what was going on just fine.
-- Scott Schmit