BUG? in --dirstat when rearranging lines in a file

[Johan Herland <johan@herland.net>]

Hi,

(CCed the two main authors of --dirstat and diffcore-delta.c)

Consider the following sequence of commands:

$ git init
$ mkdir dir
$ echo -e "foo\nbar" > dir/file
$ git add dir
$ git commit -m "first"
$ # Rearrange lines in dir/file
$ echo -e "bar\nfoo" > dir/file
$ git diff
diff --git a/dir/file b/dir/file
index 3bd1f0e..1289765 100644
--- a/dir/file
+++ b/dir/file
@@ -1,2 +1,2 @@
-foo
 bar
+foo
$ git diff --stat
 dir/file |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
$ git diff --dirstat
$ # WTF!?

"git diff" and "git diff --stat" generates the expected output, but "git 
diff --dirstat" unexpectedly generates no output at all. I've traced 
this down through show_dirstat(), to diffcore_count_changes() which 
processes the pre-image and post-image to accumulate two counts:

- src_copied (#lines (or 64-byte chunks) copied from pre- to post-)

- literal_added (#lines/chunks added in post-).

When the diff consists only of rearranging lines (like the above 
example) the line-based hashing and subsequent sorting in 
diffcore-delta.c ends up hiding he fact that lines have been moved 
around, and the resulting --dirstat reports less changes than expected.

Is this a bug or a feature? :)


(This issue was originally found by a colleague at $dayjob who wrote a 
script (using --dirstat) to produce a summary of the areas of the 
source tree touched by a given commit)


Have fun! :)

...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net