Re: git diff <-> diffstat

From: Linus Torvalds
Date: Sun Sep 24 2006 - 22:09:47 EST




On Mon, 25 Sep 2006, Adrian Bunk wrote:
>
> Is there any way for "git diff" to handle additional options diffstat
> handles? I'm a big fan of the -w72 diffstat option.

No, I think we've got the width fixed at 80 columns.

> Oh, and with git 1.4.2.1,
> git diff -M --stat --summary v2.6.18..master
> in your tree gives me some funny lines like:
>
> .../netlabel/draft-ietf-cipso-ipsecurity-01.txt | 791 +
> .../{cpu_setup_power4.S => cpu_setup_ppc970.S} | 103
> .../powerpc/platforms}/iseries/it_exp_vpd_panel.h | 6
> .../powerpc/platforms}/iseries/it_lp_naca.h | 6
>
> I don't know what's going wrong here, but diffstat doesn't produce this.

Nothing is going wrong, and diffstat doesn't produce it, exactly because
diffstat cannot understand renames.

So what happened is that you had files (and directories) that got renamed,
and "git diff --stat" will show that.

For example, one was just a rename within one directory: that's the

.../{cpu_setup_power4.S => cpu_setup_ppc970.S}

thing. In the other cases, the file got renamed at the directory level
(the two final pathnames remained the same, but the file got moved from
one directory to another). That's what he

prefix/{dir => dir2}/file.c

syntax means. It's renaming "file.c" from "prefix/dir/file.c" to
"prefix/dir2/file.c".

With long path-names, it can get a bit confusing, since we then truncate
the end result and just show the last parts to make it fit, of course.

This is _hugely_ superior to a regular diffstat, btw. If you have a
regular diffstat, and you moved a file and made some changes, it will look
something like

one/dir/file.c | 278 -------------
another/file.c | 280 ++++++++++++++

but with rename detection on (remember, you need "-M" to enable it in
git), you'd get

{one/dir => another}/file.c | 7 +++--

ie it would show the rename and the (much smaller) change that was
associated with it.

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/