Re: git diff <-> diffstat

[Linus Torvalds]

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/