.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 ...)

---
 .gitattributes |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)
 create mode 100644 .gitattributes

new file mode 100644
index 0000000..6d2b620
@@ -0,0 +1,2 @@
+*.h diff=cpp
+*.c diff=cpp

1.7.6

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

Not quite sure what you exactly mean by "extend it from just binary-vs-text". Do you mean update buffer_is_binary() and add source language detection?

See also:

    http://thread.gmane.org/gmane.comp.version-control.git/180103/focus=180113

Yes. Except the "detection" would be just "if we auto-detect it as text, then use the standard file extensions to also make an automatic hunk rule detection".

So it would do the most common cases (*.[Cch] etc)

Linus

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

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

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

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

OK Thanks for the answer. That I can understand
Boaz