git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
* git bug?
@ 2020-09-26 17:57 PANEL Christian
  0 siblings, 0 replies; 6+ messages in thread
From: PANEL Christian @ 2020-09-26 17:57 UTC (permalink / raw)
  To: git

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





^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: git bug?
  2005-06-09  8:01     ` Jeff Garzik
@ 2005-06-09  8:15       ` Junio C Hamano
  0 siblings, 0 replies; 6+ messages in thread
From: Junio C Hamano @ 2005-06-09  8:15 UTC (permalink / raw)
  To: Jeff Garzik; +Cc: git

>>>>> "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



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: git bug?
  2005-06-09  7:55   ` Junio C Hamano
@ 2005-06-09  8:01     ` Jeff Garzik
  2005-06-09  8:15       ` Junio C Hamano
  0 siblings, 1 reply; 6+ messages in thread
From: Jeff Garzik @ 2005-06-09  8:01 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

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



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: git bug?
       [not found] ` <7vy89kq96o.fsf@assigned-by-dhcp.cox.net>
@ 2005-06-09  7:55   ` Junio C Hamano
  2005-06-09  8:01     ` Jeff Garzik
  0 siblings, 1 reply; 6+ messages in thread
From: Junio C Hamano @ 2005-06-09  7:55 UTC (permalink / raw)
  To: Jeff Garzik; +Cc: git

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.


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: git bug?
  2005-06-09  6:54 Jeff Garzik
@ 2005-06-09  7:39 ` Jeff Garzik
       [not found] ` <7vy89kq96o.fsf@assigned-by-dhcp.cox.net>
  1 sibling, 0 replies; 6+ messages in thread
From: Jeff Garzik @ 2005-06-09  7:39 UTC (permalink / raw)
  To: Git Mailing List

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



^ permalink raw reply	[flat|nested] 6+ messages in thread

* git bug?
@ 2005-06-09  6:54 Jeff Garzik
  2005-06-09  7:39 ` Jeff Garzik
       [not found] ` <7vy89kq96o.fsf@assigned-by-dhcp.cox.net>
  0 siblings, 2 replies; 6+ messages in thread
From: Jeff Garzik @ 2005-06-09  6:54 UTC (permalink / raw)
  To: Git Mailing List


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




^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2020-09-26 17:57 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-26 17:57 git bug? PANEL Christian
  -- strict thread matches above, loose matches on Subject: below --
2005-06-09  6:54 Jeff Garzik
2005-06-09  7:39 ` Jeff Garzik
     [not found] ` <7vy89kq96o.fsf@assigned-by-dhcp.cox.net>
2005-06-09  7:55   ` Junio C Hamano
2005-06-09  8:01     ` Jeff Garzik
2005-06-09  8:15       ` Junio C Hamano

git@vger.kernel.org list mirror (unofficial, one of many)

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 git git/ https://public-inbox.org/git \
		git@vger.kernel.org
	public-inbox-index git

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.io/gmane.comp.version-control.git
 note: .onion URLs require Tor: https://www.torproject.org/

code repositories for project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git