git diff - no newline after @@ ?

git diff - no newline after @@ ?

[Petr Sebor]

Hello,

has anyone noticed that the 'git diff' output somehow lacks the newline 
after the @@ tag?

The linux-kernel list is full of diffs whose hunks begin like:

@@ -1475,6 +1475,7 @@ int do_coredump(long signr, int exit_cod

@@ -1516,22 +1517,34 @@ int do_coredump(long signr, int exit_cod

@@ -1428,7 +1442,7 @@ static int elf_core_dump(long signr, str

instead of:

@@ -1475,6 +1475,7 @@
 int do_coredump(long signr, int exit_cod

@@ -1516,22 +1517,34 @@
 int do_coredump(long signr, int exit_cod

@@ -1428,7 +1442,7 @@
 static int elf_core_dump(long signr, str


It is not only a problem of the linux-kernel, my local git installation 
suffers from this as well...

Regards
Petr

Re: git diff - no newline after @@ ?

[Alex Riesen]

On 8/18/06, Petr Sebor <petr@scssoft.com> wrote:
> Hello,
>
> has anyone noticed that the 'git diff' output somehow lacks the newline
> after the @@ tag?
>

Why should it? It's hunk comment.

Re: git diff - no newline after @@ ?

[Petr Sebor]

Alex Riesen wrote:
> On 8/18/06, Petr Sebor <petr@scssoft.com> wrote:
>> Hello,
>>
>> has anyone noticed that the 'git diff' output somehow lacks the newline
>> after the @@ tag?
>>
>
> Why should it? It's hunk comment.
Hunk comment? Maybe we don't understand each other...

check another example:

--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -13,6 +13,7 @@ #include <linux/stddef.h>
 #include <linux/types.h>
 #include <linux/compiler.h>
 #include <linux/bitops.h>
+#include <linux/memleak.h>
 #include <asm/byteorder.h>
 #include <asm/bug.h>

whereas gnu diff would output

--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -13,6 +13,7 @@
 #include <linux/stddef.h>
 #include <linux/types.h>
 #include <linux/compiler.h>
 #include <linux/bitops.h>
+#include <linux/memleak.h>
 #include <asm/byteorder.h>
 #include <asm/bug.h>

Petr

Re: git diff - no newline after @@ ?

[Jakub Narebski]

Petr Sebor wrote:

> Alex Riesen wrote:
>> On 8/18/06, Petr Sebor <petr@scssoft.com> wrote:
>>> Hello,
>>>
>>> has anyone noticed that the 'git diff' output somehow lacks the newline
>>> after the @@ tag?
>>>
>>
>> Why should it? It's hunk comment.
> Hunk comment? Maybe we don't understand each other...

Hunk comment as in "diff -p":

  -p     Show which C function each change is in.

(which is simpliefied to: show first line preceding hunk which begins with
word character in first column). 

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: git diff - no newline after @@ ?

[Jeff King]

On Fri, Aug 18, 2006 at 02:37:42PM +0200, Petr Sebor wrote:

> >>has anyone noticed that the 'git diff' output somehow lacks the newline
> >>after the @@ tag?
> >Why should it? It's hunk comment.
> Hunk comment? Maybe we don't understand each other...

The intent of a hunk comment is to give the user some context. Note how
it's usually the C function name, even if the declaration of that
function isn't the line right before the context lines?

> check another example:
> 
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -13,6 +13,7 @@ #include <linux/stddef.h>
> #include <linux/types.h>
> #include <linux/compiler.h>
> #include <linux/bitops.h>
> +#include <linux/memleak.h>
> #include <asm/byteorder.h>
> #include <asm/bug.h>

The function detection is very simple (I believe it just looks for the
closest preceding line without any prior whitespace).

> whereas gnu diff would output

Try diff -p to get a hunk comment.

-Peff

Re: git diff - no newline after @@ ?

[Petr Sebor]

Jeff King wrote:
> Try diff -p to get a hunk comment.
>
> -Peff
>   

Ouch.... got it. Is there a way to turn the comment generation off btw?

Sorry for the noise...

Petr

Re: git diff - no newline after @@ ?

[Jakub Narebski]

Petr Sebor wrote:

> Jeff King wrote:
>> Try diff -p to get a hunk comment.
>>
>> -Peff
>>   
> 
> Ouch.... got it. Is there a way to turn the comment generation off btw?

Other than GIT_DIFF_OPTS (although how to turn off present -p option), or
GIT_EXTERNAL_DIFF (see git-diff-tree(1))?

Why do you want to turn it off? patch understands this format...
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git