* 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
* Re: git bug? 2005-06-09 6:54 git bug? 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
[parent not found: <7vy89kq96o.fsf@assigned-by-dhcp.cox.net>]
* 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 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? 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
* 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
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 -- 2005-06-09 6:54 git bug? 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 -- strict thread matches above, loose matches on Subject: below -- 2020-09-26 17:57 PANEL Christian
Code repositories for project(s) associated with this public inbox https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).