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 <peff@peff.net>
CC: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Boaz Harrosh <bharrosh@panasas.com>
---
 .gitattributes |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)
 create mode 100644 .gitattributes

On Thu, Aug 25, 2011 at 3:37 PM, Boaz Harrosh <bharrosh@panasas.com> wrote:

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

Linus Torvalds <torvalds@linux-foundation.org> writes:

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

On Fri, Aug 26, 2011 at 1:54 PM, Junio C Hamano <gitster@pobox.com> wrote:

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

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

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

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

Ah, I'm using:

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

For this.

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

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:

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

On Mon, Aug 29, 2011 at 1:57 PM, Boaz Harrosh <bharrosh@panasas.com> wrote:

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:

OK Thanks for the answer. That I can understand Boaz