[PATCH] .gitattributes: Enable cpp diff parsing for .[ch] files

The Linux Kernel source tree is certainly a C language repository.
As a maintainer and code reviewer I would like too, for example:
See function names as hunk headers and not goto labels. And all
the other goodies a language specific diff parser gives me.

Add a .gitattributes file to the Linux tree to enable cpp parsing
of the source files.

People are welcome to add other parsers for other type of files
if needed. (Like Makefile or Kconfig ...)

CC: Jeff King <redacted>
CC: Junio C Hamano <redacted>
Signed-off-by: Boaz Harrosh <redacted>
---
 .gitattributes |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)
 create mode 100644 .gitattributes

diff --git a/.gitattributes b/.gitattributes
new file mode 100644
index 0000000..6d2b620
--- /dev/null
+++ b/.gitattributes

@@ -0,0 +1,2 @@
+*.h diff=cpp
+*.c diff=cpp

-- 
1.7.6

On Thu, Aug 25, 2011 at 3:37 PM, Boaz Harrosh [off-list ref] wrote:

Add a .gitattributes file to the Linux tree to enable cpp parsing
of the source files.

Hmm. I'm not entirely conviced. If people really think that the hunk
description matters that much, maybe we should just instead improve on
the automatic diff detection, and extend it from just binary-vs-text,
to also do the common hunk-headers.

After all, not having a diff pattern already *does* mean "automatic",
so it would be just a rather trivial extension to that.

Junio?

                     Linus

On 08/26/2011 01:27 PM, Linus Torvalds wrote:

On Thu, Aug 25, 2011 at 3:37 PM, Boaz Harrosh [off-list ref] wrote:

quoted

Add a .gitattributes file to the Linux tree to enable cpp parsing
of the source files.

Hmm. I'm not entirely conviced. If people really think that the hunk
description matters that much, maybe we should just instead improve on
the automatic diff detection, and extend it from just binary-vs-text,
to also do the common hunk-headers.

After all, not having a diff pattern already *does* mean "automatic",
so it would be just a rather trivial extension to that.

Junio?

There was a patch submitted for new git version to auto detect file
extensions and do the right thing. 
(Look for the thread "git diff annoyance / feature request" on the git
 mailing list)

But this patch is for all the people and distributions that are going
to use the old git versions for a while, (Years).

It is important for the Linux mailing-list review, because you get
patches with:

@@@ lable out:
-	change foo
+	to bazz

And how the hell are you suppose to know where in the file it is.
This is such a trivial addition, that can help unify everyone's
usage. I don't see the down sides.

Thanks
Boaz

                     Linus

On Fri, 2011-08-26 at 13:55 -0700, Boaz Harrosh wrote:

But this patch is for all the people and distributions that are going
to use the old git versions for a while, (Years).

It is important for the Linux mailing-list review, because you get
patches with:

@@@ lable out:
-	change foo
+	to bazz

And how the hell are you suppose to know where in the file it is.
This is such a trivial addition, that can help unify everyone's
usage. I don't see the down sides.

Ah, I'm using:

# cat ~/.gitconfig 
[diff "default"]
                xfuncname = "^[[:alpha:]$_].*[^:]$"


For this.

On 08/29/2011 06:32 AM, Peter Zijlstra wrote:

On Fri, 2011-08-26 at 13:55 -0700, Boaz Harrosh wrote:

quoted

But this patch is for all the people and distributions that are going
to use the old git versions for a while, (Years).

It is important for the Linux mailing-list review, because you get
patches with:

@@@ lable out:
-	change foo
+	to bazz

And how the hell are you suppose to know where in the file it is.
This is such a trivial addition, that can help unify everyone's
usage. I don't see the down sides.

Ah, I'm using:

# cat ~/.gitconfig 
[diff "default"]
                xfuncname = "^[[:alpha:]$_].*[^:]$"


For this.

It looks like a lost cause so I'll try for the last time.

Everyone is suggesting that each one do his own cooked up secrets and solutions.
And those that are stupid and know nothing like me are un-lucky. But what I'm
proposing is that by just doing a "git clone" you'll be using these settings
that we like to see, when you send us your patches.

Adding a .gitattributes file to the Linux git tree is a very simple message.
"In the linux git tree all .c and .h files are c-source files" (And git will
treat them that way)

Now that was not so hard was it? Really, no one said anything bad or negative
about the patch, only excuses how it can be achieved, very difficultly, in
another way. So for the last time:
  What are you guys afraid of? what possibly could be bad about this patch?

Sigh

Good bye to this subject
Boaz

On Mon, 2011-08-29 at 13:57 -0700, Boaz Harrosh wrote:

Adding a .gitattributes file to the Linux git tree is a very simple message.
"In the linux git tree all .c and .h files are c-source files" (And git will
treat them that way) 

I'm all for it, I hate those labels in git-diff output.. 

On Mon, Aug 29, 2011 at 1:57 PM, Boaz Harrosh [off-list ref] wrote:

 What are you guys afraid of? what possibly could be bad about this patch?

I just detest filling the kernel tree with git stuff.

Right now, the only git-specific file we have in the kernel tree is
the ".gitignore" files, afaik. And if you were to use some other SCM,
the "ignore" model at least translates directly to just about anything
else (with the problem that the .gitignore model tends to be more
powerful than most other SCM's have, but whatever).

I'd hate to start populating the project with more stuff.

                     Linus

On 08/29/2011 03:02 PM, Linus Torvalds wrote:

I'd hate to start populating the project with more stuff.

                     Linus

OK Thanks for the answer. That I can understand
Boaz