Re: [Possible bug] diff-tree --stat info does not count copies

From: Marco Costalba <mcostalba@gmail.com>
Date: Aug 17, 2006, 10:54 UTC
Message-ID: <e5bfff550608170354i45104458h3b7e2ec8c668fb9c@mail.gmail.com>
In-Reply-To: <7vveorsnt3.fsf@assigned-by-dhcp.cox.net>

On 8/17/06, Junio C Hamano <junkio@cox.net> wrote:

Show 52 quoted lines

> "Marco Costalba" <mcostalba@gmail.com> 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.
>

Because after a copy you have 2 files, not still one. And the 'after copied' file cannot be the original, but a new file, because the original is still alive.

Perhaps I can explain better myself taking in account the _couple_ of files involved in both cases:

Without -C we have

diff-lib.c | 1862 ++--------------------------------------- diff.c | 1795 ++++++++++++++++++++++++++++++++++++++++

With -C option is

 diff-lib.c                    | 1862 ++---------------------------------------
 diff-lib.c => diff.c          |    0

If it was a rename we had something like:

diff-lib.c | 1795 ----------------------------------------- diff.c | 1795 ++++++++++++++++++++++++++++++++++++++++

and, with -C

diff-lib.c => diff.c          |    0

and _this_ is correct. But with copy diff-lib.c => diff.c should not stay at zero lines changed because diff.c is not the same of diff-lib.c, but it's a _new_ file created with the same content of diff-lib.c and _then_ the original and only diff-lib.c file is further modified on his own (in our case changing 1862 lines).

Please tell me where I get wrong.

Thanks Marco