git bug?

git bug?

[Jeff Garzik]

Just upgraded to the latest git, pulled the latest Linux kernel tree, 
and made a local modification.  Here is the strange git-diff-cache output:

> [jgarzik@pretzel libata-dev]$ git-diff-cache -p HEAD 
> diff --git a/arch/arm/mm/minicache.c b/arch/arm/mm/minicache.c
> deleted file mode 100644
> diff --git a/drivers/scsi/libata-core.c b/drivers/scsi/libata-core.c
> --- a/drivers/scsi/libata-core.c
> +++ b/drivers/scsi/libata-core.c
> @@ -3059,8 +3059,6 @@ static void __ata_qc_complete(struct ata
>         struct ata_port *ap = qc->ap;
>         unsigned int tag, do_clear = 0;
>  
> -       WARN_ON(!assert_spin_locked(&ap->host_set->lock));
> -
>         if (likely(qc->flags & ATA_QCFLAG_ACTIVE)) {
>                 assert(ap->queue_depth);
>                 ap->queue_depth--;

The libata-core part is correct, the arch/arm/mm part is not.

I pulled using unmodified, upstream git scripts.  No sugar added. 
Here's what the repo looks like:

> [jgarzik@pretzel libata-dev]$ git-rev-list --pretty HEAD ^master | git-shortlog 
> Jeff Garzik:
>   Merge /spare/repo/linux-2.6/
>   Automatic merge of /spare/repo/linux-2.6/.git branch HEAD
> 
> Jens Axboe:
>   libata: fix spinlock bug introduced by NCQ code
>   libata: ncq support update
>   libata-scsi: better placement of cmd completion on err
>   SATA NCQ support

It's mirroring to kernel.org right now, at 
rsync.kernel.org://...jgarzik/libata-dev.git if somebody wants to poke 
at it.  Top of tree is d032ec9048ff82a704b96b93cfd6f2e8e3a06b19 (when 
fully uploaded and mirrored).

	Jeff

Re: git bug?

[Jeff Garzik]

Jeff Garzik wrote:
> 
> Just upgraded to the latest git, pulled the latest Linux kernel tree, 
> and made a local modification.  Here is the strange git-diff-cache output:
> 
>> [jgarzik@pretzel libata-dev]$ git-diff-cache -p HEAD diff --git 
>> a/arch/arm/mm/minicache.c b/arch/arm/mm/minicache.c
>> deleted file mode 100644
>> diff --git a/drivers/scsi/libata-core.c b/drivers/scsi/libata-core.c
>> --- a/drivers/scsi/libata-core.c
>> +++ b/drivers/scsi/libata-core.c
>> @@ -3059,8 +3059,6 @@ static void __ata_qc_complete(struct ata
>>         struct ata_port *ap = qc->ap;
>>         unsigned int tag, do_clear = 0;
>>  
>> -       WARN_ON(!assert_spin_locked(&ap->host_set->lock));
>> -
>>         if (likely(qc->flags & ATA_QCFLAG_ACTIVE)) {
>>                 assert(ap->queue_depth);
>>                 ap->queue_depth--;
> 
> 
> The libata-core part is correct, the arch/arm/mm part is not.
> 
> I pulled using unmodified, upstream git scripts.  No sugar added. Here's 
> what the repo looks like:
> 
>> [jgarzik@pretzel libata-dev]$ git-rev-list --pretty HEAD ^master | 
>> git-shortlog Jeff Garzik:
>>   Merge /spare/repo/linux-2.6/
>>   Automatic merge of /spare/repo/linux-2.6/.git branch HEAD
>>
>> Jens Axboe:
>>   libata: fix spinlock bug introduced by NCQ code
>>   libata: ncq support update
>>   libata-scsi: better placement of cmd completion on err
>>   SATA NCQ support
> 
> 
> It's mirroring to kernel.org right now, at 
> rsync.kernel.org://...jgarzik/libata-dev.git if somebody wants to poke 
> at it.  Top of tree is d032ec9048ff82a704b96b93cfd6f2e8e3a06b19 (when 
> fully uploaded and mirrored).


Well, after switching branches and switching back, the behavior is gone. 
  <shrug>

	Jeff

Re: git bug?

[Junio C Hamano]

Jeff, I assume you are talking about this part:

>> diff --git a/arch/arm/mm/minicache.c b/arch/arm/mm/minicache.c
>> deleted file mode 100644
>> diff --git a/drivers/scsi/libata-core.c b/drivers/scsi/libata-core.c

that does not have anything between "deleted file..." and the
next diff about libata-core.c.

In short, this is not really a "bug", but I am open to
suggestions for improvements (but you need to talk Linus into
accepting the changes, because changing this would also affect
his "git-apply" program as well).

The current "diff-patch" format is generated this way:

 (0) if a modification is between different kind of objects
     (e.g. a regular file changed to a symlink), then the
     following steps are done twice; one "deletion" of the
     original, and another "creation" of the result.

 (1) "diff --git a/oldname b/newname" line is shown first and it
     is always shown.  Unless it is a rename/copy diff, oldname
     and newname always match.  We never say /dev/null on this
     line to represent creation/deletion.

 (2) Next, optional "diff --git extended headers" appear.  See
     apply.c for the list of things to expect.

 (3) Next, the output from "diff -u -L<oldname> -L<newname>"
     between the two file contents follows.  Here, oldname and
     newname are usually of the form "a/oldname" and
     "b/oldname", but we _do_ follow /dev/null convention for
     file creation and deletion here.  That is, you would see

         --- /dev/null
         +++ frotz.c
         @@ ...

     for a file creation, and the opposite for a file deletion.

     Unfortunately, if "diff" finds nothing to report, you would
     not even see these ---/+++ lines.  I think that is what
     puzzled you.

By the way, this is all documented (?) behaviour, reported first
by Linus in this message.

  Message-ID: <Pine.LNX.4.58.0505261214140.2307@ppc970.osdl.org>
  From: Linus Torvalds <torvalds@osdl.org>
  Subject: git full diff output issues..
  Date: Thu, 26 May 2005 12:19:21 -0700 (PDT)
  Cc: Git Mailing List <git@vger.kernel.org>

  While testing my "git-apply" thing (coming along quite nicely, thanks for
  asking), I've hit a case that is nasty to parse.

  This is from the 2.6.12-rc4 -> 2.6.12-rc5 patch:

          diff --git a/arch/um/kernel/checksum.c b/arch/um/kernel/checksum.c
          deleted file mode 100644
          diff --git a/arch/um/kernel/initrd.c b/arch/um/kernel/initrd.c
          new file mode 100644
          --- /dev/null
          +++ b/arch/um/kernel/initrd.c
          @@ -0,0 +1,78 @@

  and the magic here is that deleted file that was empty to begin with, so 
  it didn't have a patch, just a note on deletion.

  Why is that nasty? Because we don't have the file _name_ in any good 
  format. The filename only exists int he "diff --git" header, and that one 
  has the space-parsing issue, which makes it less than optimal.

  (the rest omitted)

We had a handful of back-and-forth back then and the resolution
was this:

  Message-ID: <Pine.LNX.4.58.0505261316250.2307@ppc970.osdl.org>
  From: Linus Torvalds <torvalds@osdl.org>
  Subject: Re: git full diff output issues..
  Date: Thu, 26 May 2005 13:33:26 -0700 (PDT)
  Cc: Junio C Hamano <junkio@cox.net>, Git Mailing List <git@vger.kernel.org>

  (some omitted)

  However, I ended up just validating the name parsing by making sure that 
  when I parse the "git --diff" line, I only take the name if I can see it 
  being the same for both the old and the new. ...

  (the rest omitted)

By the way, this is not just "deleting empty files".  Any change
that does not involve content changes you would see something
similar to what you found.

  Message-ID: <Pine.LNX.4.58.0506050806400.1876@ppc970.osdl.org>
  From: Linus Torvalds <torvalds@osdl.org>
  Subject: Re: git full diff output issues..
  Date: Sun, 5 Jun 2005 08:11:02 -0700 (PDT)
  Cc: git@vger.kernel.org

  (some omitted)

  The only case that was special was literally the "same name, no content 
  changes, new mode" case, which looked like

          diff --git a/oldname.c b/oldname.c
          new mode 100755
          old mode 100644

  and thus _only_ had the name in the (normally ambiguous wrt whitepsace)  
  header line.

Re: git bug?

[Jeff Garzik]

Junio C Hamano wrote:
> Jeff, I assume you are talking about this part:
> 
> 
>>>diff --git a/arch/arm/mm/minicache.c b/arch/arm/mm/minicache.c
>>>deleted file mode 100644
>>>diff --git a/drivers/scsi/libata-core.c b/drivers/scsi/libata-core.c
> 
> 
> that does not have anything between "deleted file..." and the
> next diff about libata-core.c.
> 
> In short, this is not really a "bug", but I am open to
> suggestions for improvements (but you need to talk Linus into
> accepting the changes, because changing this would also affect
> his "git-apply" program as well).

It's a bug and a new behavior.

'git-diff-cache -p HEAD' should not show files that I have not modified.

This screws up
	git-diff-cache -p HEAD | diffstat -p1 | awk '{print $1}'
for example.

	Jeff

Re: git bug?

[Junio C Hamano]

>>>>> "JG" == Jeff Garzik <jgarzik@pobox.com> writes:

JG> 'git-diff-cache -p HEAD' should not show files that I have not modified.
JG> This screws up
JG> 	git-diff-cache -p HEAD | diffstat -p1 | awk '{print $1}'
JG> for example.

Agreed 100%.  If there is a file exists (rather, if the git
thinks the file is there), then diff-cache should not say it is
deleted.  That would be wrong.

Sorry for not having a crystal ball to poke into your terminal,
so let me get something straight.  I am still unsure the problem
you are reporting is coming from diff-cache bug, or somehow
yesterday's (well it is 01:13AM where I sit ;-)) merge updates
trashed your work tree or index file, so these questions would
help me tell which.  When "diff-cache" reports the file
"deleted":

 - Do you have that arch/arm/mm/minicache.c file in your working
   directory?

 - Does git-ls-files know about the file?  Does the path show in:
   git-ls-files --stage | grep arch/arm/mm/minicache.c

 - Does the HEAD tree have the path as well?  Does it show in:
   git-ls-tree -r HEAD | grep arch/arm/mm/minicache.c

git bug?

[PANEL Christian]

hello,

Using .git/info/exclude file to ignore some of my directories, I notice a curious think I took for a bug :

I wanted to exclude all except that is inside my /TED/ directory
I wrote a file exclude first as this


*
!/TED/


but this doesn't work and is dangerous because no warning, and git status said (after I realize commit and push on server)
working copy is clear.
fortunately looking at repository I realize the mistake and trying a "git add" tells me there is something wrong in the
exclude file
I changed it as this

/*
!/TED/

and it works
but I don't know exactly why 
Have you a begin of answer ?

thanks a lot in advance for any answer