"Marco Costalba" <mcostalba@xxxxxxxxx> writes: > While testing qgit with the new rename/copy support I found this > (possible) bug playing on git tree. > > $ git-diff-tree -r --stat 6973dca > 6973dcaee76ef7b7bfcabd2f26e76205aae07858 > Makefile | 2 > diff-files.c | 212 +---- > diff-lib.c | 1862 ++--------------------------------------- > diff.c | 1795 ++++++++++++++++++++++++++++++++++++++++ > diff.h | 7 > t/t1001-read-tree-m-2way.sh | 2 > t/t1002-read-tree-m-u-2way.sh | 2 > 7 files changed, 1929 insertions(+), 1953 deletions(-) > > $ git-diff-tree -r --stat -C 6973dca > 6973dcaee76ef7b7bfcabd2f26e76205aae07858 > Makefile | 2 > diff-files.c | 212 +---- > diff-lib.c | 1862 ++--------------------------------------- > diff-lib.c => diff.c | 0 > diff.h | 7 > t/t1001-read-tree-m-2way.sh | 2 > t/t1002-read-tree-m-u-2way.sh | 2 > 7 files changed, 134 insertions(+), 1953 deletions(-) > > IMHO the bug is > > "diff-lib.c => diff.c | 0" > > instead of > > "diff-lib.c => diff.c | 1795" > > because, after the patch applied, in the repository we have > 1953-1929=24 lines of code more, not 1953-134= 1819 less. Interesting. That's really a matter of taste and interpretation. If it were a straight rename without changing a single line, then would you say 1795 lines were removed (from the LHS file) and 1795 lines were added (to the RHS file)? I personally find that output would be useless and would prefer it to say "I renamed file A to file B. Content-wise, there were N lines added and M lines removed, compared to the straight rename case, by the way". And that is what the current output does. I do not see why it should be different in the case of a copy instead of a rename. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html