{"thread":{"id":"53987","subject":"ls-files bug report","startedAt":"2020-08-05T15:55:06Z","lastAt":"2020-08-12T17:48:57Z","messageCount":7,"participants":["christian w","Kyle Meyer","Elijah Newren"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"402908","messageId":"CADjceoQxoL932W4mkfhG6VOgrQBhs9k6tXkWSkraKVPmUP+uCw@mail.gmail.com","threadId":"53987","inReplyTo":null,"subject":"ls-files bug report","fromName":"christian w","fromEmail":"usebees@gmail.com","sentAt":"2020-08-05T15:15:56Z","receivedAt":"2020-08-05T15:55:06Z","isPatch":false,"sender":{"key":"usebees@gmail.com","avatar":null},"body":"Thank you for filling out a Git bug report!\nPlease answer the following questions to help us understand your issue.\n\nWhat did you do before the bug happened? (Steps to reproduce your issue)\n\ngit ls-files --others 'some/path/*.some.extension'\n\nWhat did you expect to happen? (Expected behavior)\n\nonly list files under some/path/ that had .some.extension\n\nWhat happened instead? (Actual behavior)\n\nIt listed those files and also all untracked folders underneath some/path/\n\nWhat's different between what you expected and what actually happened?\n\nThe folders did not match the grep pattern but were still listed.\n\nAnything else you want to add:\n\nPlease review the rest of the bug report below.\nYou can delete any lines you don't wish to share.\n\n\n[System Info]\ngit version:\ngit version 2.28.0\ncpu: x86_64\nno commit associated with this build\nsizeof-long: 8\nsizeof-size_t: 8\nshell-path: /bin/sh\nuname: Darwin 17.7.0 Darwin Kernel Version 17.7.0: Thu Jun 18 21:21:34\nPDT 2020; root:xnu-4570.71.82.5~1/RELEASE_X86_64 x86_64\ncompiler info: clang: 10.0.0 (clang-1000.11.45.5)\nlibc info: no libc information available\n$SHELL (typically, interactive shell): /bin/bash\n\n\n[Enabled Hooks]\npre-commit\ncommit-msg\npost-commit\npost-checkout\npost-merge\npre-push\npost-rewrite\n"},{"id":"403010","messageId":"878ses4pay.fsf@kyleam.com","threadId":"53987","inReplyTo":"CADjceoQxoL932W4mkfhG6VOgrQBhs9k6tXkWSkraKVPmUP+uCw@mail.gmail.com","subject":"Re: ls-files bug report","fromName":"Kyle Meyer","fromEmail":"kyle@kyleam.com","sentAt":"2020-08-05T23:59:33Z","receivedAt":"2020-08-05T23:59:42Z","isPatch":false,"sender":{"key":"kyle@kyleam.com","avatar":"https://avatars.githubusercontent.com/u/1297788?v=4"},"body":"christian w writes:\n\n> Thank you for filling out a Git bug report!\n> Please answer the following questions to help us understand your issue.\n>\n> What did you do before the bug happened? (Steps to reproduce your issue)\n>\n> git ls-files --others 'some/path/*.some.extension'\n>\n> What did you expect to happen? (Expected behavior)\n>\n> only list files under some/path/ that had .some.extension\n>\n> What happened instead? (Actual behavior)\n>\n> It listed those files and also all untracked folders underneath some/path/\n\nI tried to follow your description, and I don't see this on my end.  In\na fresh repository:\n\n    $ mkdir -p some/path/d0\n    $ mkdir -p some/path/d1\n    $ touch some/path/f0 some/path/d0/f0 some/path/f1.some.extension\n    \n    $ git ls-files --others\n    some/path/d0/f0\n    some/path/f0\n    some/path/f1.some.extension\n    \n    $ git ls-files --others 'some/path/*.some.extension'\n    some/path/f1.some.extension\n    \n    $ git version\n    git version 2.28.0\n\nCould you provide a more detailed recipe to reproduce the issue?\n\n> [System Info]\n> git version:\n> git version 2.28.0\n"},{"id":"403012","messageId":"CADjceoRtFmM2H1z48HcmvWBF1KmMrwMnE6YdC9HJGFjdXXivJw@mail.gmail.com","threadId":"53987","inReplyTo":"878ses4pay.fsf@kyleam.com","subject":"Re: ls-files bug report","fromName":"christian w","fromEmail":"usebees@gmail.com","sentAt":"2020-08-06T00:27:42Z","receivedAt":"2020-08-06T00:27:57Z","isPatch":false,"sender":{"key":"usebees@gmail.com","avatar":null},"body":"Sorry for the insufficient reproduction steps.\n\nI managed to figure out it has something to do with git repos within\ngit repos. It happened to us because of go packages that are inside\nour repo. These are the reproduction steps that work for me\nconsistently using Go version go1.14.4 darwin/amd64. This is the repo\nthat gets cloned into src/golang.org/x/debug by the go get command:\nhttps://github.com/golang/debug/tree/66ec140f2f72d15dc6133502edd2bb7238b1740c\n\n$ mkdir testdir\n$ cd testdir\n$ git init .\n$ GOPATH=$(pwd) go get -u golang.org/x/debug/ || true\n$ git ls-files --others '*.txt'#\nsrc/golang.org/x/debug/\n\nOn Wed, Aug 5, 2020 at 7:59 PM Kyle Meyer <kyle@kyleam.com> wrote:\n>\n> christian w writes:\n>\n> > Thank you for filling out a Git bug report!\n> > Please answer the following questions to help us understand your issue.\n> >\n> > What did you do before the bug happened? (Steps to reproduce your issue)\n> >\n> > git ls-files --others 'some/path/*.some.extension'\n> >\n> > What did you expect to happen? (Expected behavior)\n> >\n> > only list files under some/path/ that had .some.extension\n> >\n> > What happened instead? (Actual behavior)\n> >\n> > It listed those files and also all untracked folders underneath some/path/\n>\n> I tried to follow your description, and I don't see this on my end.  In\n> a fresh repository:\n>\n>     $ mkdir -p some/path/d0\n>     $ mkdir -p some/path/d1\n>     $ touch some/path/f0 some/path/d0/f0 some/path/f1.some.extension\n>\n>     $ git ls-files --others\n>     some/path/d0/f0\n>     some/path/f0\n>     some/path/f1.some.extension\n>\n>     $ git ls-files --others 'some/path/*.some.extension'\n>     some/path/f1.some.extension\n>\n>     $ git version\n>     git version 2.28.0\n>\n> Could you provide a more detailed recipe to reproduce the issue?\n>\n> > [System Info]\n> > git version:\n> > git version 2.28.0\n"},{"id":"403018","messageId":"8736504k06.fsf@kyleam.com","threadId":"53987","inReplyTo":"CADjceoRtFmM2H1z48HcmvWBF1KmMrwMnE6YdC9HJGFjdXXivJw@mail.gmail.com","subject":"Re: ls-files bug report","fromName":"Kyle Meyer","fromEmail":"kyle@kyleam.com","sentAt":"2020-08-06T01:54:01Z","receivedAt":"2020-08-06T01:54:09Z","isPatch":false,"sender":{"key":"kyle@kyleam.com","avatar":"https://avatars.githubusercontent.com/u/1297788?v=4"},"body":"christian w writes:\n\n> Sorry for the insufficient reproduction steps.\n>\n> I managed to figure out it has something to do with git repos within\n> git repos. It happened to us because of go packages that are inside\n> our repo. These are the reproduction steps that work for me\n> consistently using Go version go1.14.4 darwin/amd64. This is the repo\n> that gets cloned into src/golang.org/x/debug by the go get command:\n> https://github.com/golang/debug/tree/66ec140f2f72d15dc6133502edd2bb7238b1740c\n>\n> $ mkdir testdir\n> $ cd testdir\n> $ git init .\n> $ GOPATH=$(pwd) go get -u golang.org/x/debug/ || true\n> $ git ls-files --others '*.txt'#\n> src/golang.org/x/debug/\n\nOkay, removing Go from the equation:\n\n     $ # in fresh repo\n     $ mkdir a\n     $ git init a/d0\n     $ touch a/f0.txt\n     $ git ls-files --others 'a/*.txt'\n     a/d0/\n     a/f0.txt\n\nIt looks like the spurious a/d0/ entry doesn't show up until v2.27.0, in\nparticular 95c11ecc73 (Fix error-prone fill_directory() API; make it\nonly return matches, 2020-04-01).  Adding the author to the Cc.  (Sorry,\nElijah, I recall your frustration with dir.c from a previous ls-files\nissue that I reported [1]).\n\n[1] https://lore.kernel.org/git/CABPp-BFG3FkTkC=L1v97LUksndkOmCN8ZhNJh5eoNdquE7v9DA@mail.gmail.com/\n\n"},{"id":"403116","messageId":"CABPp-BEmrcY8wr_rb+Y4gacNEeeEPTUxWw2Mq0A9LMzpx2bQnA@mail.gmail.com","threadId":"53987","inReplyTo":"8736504k06.fsf@kyleam.com","subject":"Re: ls-files bug report","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2020-08-07T04:10:59Z","receivedAt":"2020-08-07T04:11:13Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Wed, Aug 5, 2020 at 6:54 PM Kyle Meyer <kyle@kyleam.com> wrote:\n>\n> christian w writes:\n>\n> > Sorry for the insufficient reproduction steps.\n> >\n> > I managed to figure out it has something to do with git repos within\n> > git repos. It happened to us because of go packages that are inside\n> > our repo. These are the reproduction steps that work for me\n> > consistently using Go version go1.14.4 darwin/amd64. This is the repo\n> > that gets cloned into src/golang.org/x/debug by the go get command:\n> > https://github.com/golang/debug/tree/66ec140f2f72d15dc6133502edd2bb7238b1740c\n> >\n> > $ mkdir testdir\n> > $ cd testdir\n> > $ git init .\n> > $ GOPATH=$(pwd) go get -u golang.org/x/debug/ || true\n> > $ git ls-files --others '*.txt'#\n> > src/golang.org/x/debug/\n>\n> Okay, removing Go from the equation:\n>\n>      $ # in fresh repo\n>      $ mkdir a\n>      $ git init a/d0\n>      $ touch a/f0.txt\n>      $ git ls-files --others 'a/*.txt'\n>      a/d0/\n>      a/f0.txt\n>\n> It looks like the spurious a/d0/ entry doesn't show up until v2.27.0, in\n> particular 95c11ecc73 (Fix error-prone fill_directory() API; make it\n> only return matches, 2020-04-01).  Adding the author to the Cc.  (Sorry,\n> Elijah, I recall your frustration with dir.c from a previous ls-files\n> issue that I reported [1]).\n\nThanks for digging in and coming up with a smaller list of steps to\nreproduce.  You are right that I dread reports that touch dir.c -- if\nI would have just ignored the first report back in March of 2018,\nthere's a really, really long list of problems I could have avoided...\n\nI'll try to take a look in the next week.\n\n>\n> [1] https://lore.kernel.org/git/CABPp-BFG3FkTkC=L1v97LUksndkOmCN8ZhNJh5eoNdquE7v9DA@mail.gmail.com/\n"},{"id":"403458","messageId":"CABPp-BFWfwkYAPyySjWOMZ02_+YLf=TJ_aVMaHaizJWAsCL67g@mail.gmail.com","threadId":"53987","inReplyTo":"CABPp-BEmrcY8wr_rb+Y4gacNEeeEPTUxWw2Mq0A9LMzpx2bQnA@mail.gmail.com","subject":"Re: ls-files bug report","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2020-08-12T14:50:31Z","receivedAt":"2020-08-12T14:50:48Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Thu, Aug 6, 2020 at 9:10 PM Elijah Newren <newren@gmail.com> wrote:\n>\n> On Wed, Aug 5, 2020 at 6:54 PM Kyle Meyer <kyle@kyleam.com> wrote:\n> >\n> > christian w writes:\n> >\n> > > Sorry for the insufficient reproduction steps.\n> > >\n> > > I managed to figure out it has something to do with git repos within\n> > > git repos. It happened to us because of go packages that are inside\n> > > our repo. These are the reproduction steps that work for me\n> > > consistently using Go version go1.14.4 darwin/amd64. This is the repo\n> > > that gets cloned into src/golang.org/x/debug by the go get command:\n> > > https://github.com/golang/debug/tree/66ec140f2f72d15dc6133502edd2bb7238b1740c\n> > >\n> > > $ mkdir testdir\n> > > $ cd testdir\n> > > $ git init .\n> > > $ GOPATH=$(pwd) go get -u golang.org/x/debug/ || true\n> > > $ git ls-files --others '*.txt'#\n> > > src/golang.org/x/debug/\n> >\n> > Okay, removing Go from the equation:\n> >\n> >      $ # in fresh repo\n> >      $ mkdir a\n> >      $ git init a/d0\n> >      $ touch a/f0.txt\n> >      $ git ls-files --others 'a/*.txt'\n> >      a/d0/\n> >      a/f0.txt\n> >\n> > It looks like the spurious a/d0/ entry doesn't show up until v2.27.0, in\n> > particular 95c11ecc73 (Fix error-prone fill_directory() API; make it\n> > only return matches, 2020-04-01).  Adding the author to the Cc.  (Sorry,\n> > Elijah, I recall your frustration with dir.c from a previous ls-files\n> > issue that I reported [1]).\n>\n> Thanks for digging in and coming up with a smaller list of steps to\n> reproduce.  You are right that I dread reports that touch dir.c -- if\n> I would have just ignored the first report back in March of 2018,\n> there's a really, really long list of problems I could have avoided...\n>\n> I'll try to take a look in the next week.\n\nShould be solved by this fix:\nhttps://lore.kernel.org/git/11a286b071ca8a6b96f4fba6658e9bafb9314be4.1597216356.git.gitgitgadget@gmail.com/\n"},{"id":"403479","messageId":"CADjceoREZm4BrdAApqnsb_uX_QBaEKC=qs7Zk0uD6L-o907hDA@mail.gmail.com","threadId":"53987","inReplyTo":"CABPp-BFWfwkYAPyySjWOMZ02_+YLf=TJ_aVMaHaizJWAsCL67g@mail.gmail.com","subject":"Re: ls-files bug report","fromName":"christian w","fromEmail":"usebees@gmail.com","sentAt":"2020-08-12T17:48:42Z","receivedAt":"2020-08-12T17:48:57Z","isPatch":false,"sender":{"key":"usebees@gmail.com","avatar":null},"body":"that's great to hear, thanks for jumping on this so quickly!\n\nOn Wed, Aug 12, 2020 at 10:50 AM Elijah Newren <newren@gmail.com> wrote:\n>\n> On Thu, Aug 6, 2020 at 9:10 PM Elijah Newren <newren@gmail.com> wrote:\n> >\n> > On Wed, Aug 5, 2020 at 6:54 PM Kyle Meyer <kyle@kyleam.com> wrote:\n> > >\n> > > christian w writes:\n> > >\n> > > > Sorry for the insufficient reproduction steps.\n> > > >\n> > > > I managed to figure out it has something to do with git repos within\n> > > > git repos. It happened to us because of go packages that are inside\n> > > > our repo. These are the reproduction steps that work for me\n> > > > consistently using Go version go1.14.4 darwin/amd64. This is the repo\n> > > > that gets cloned into src/golang.org/x/debug by the go get command:\n> > > > https://github.com/golang/debug/tree/66ec140f2f72d15dc6133502edd2bb7238b1740c\n> > > >\n> > > > $ mkdir testdir\n> > > > $ cd testdir\n> > > > $ git init .\n> > > > $ GOPATH=$(pwd) go get -u golang.org/x/debug/ || true\n> > > > $ git ls-files --others '*.txt'#\n> > > > src/golang.org/x/debug/\n> > >\n> > > Okay, removing Go from the equation:\n> > >\n> > >      $ # in fresh repo\n> > >      $ mkdir a\n> > >      $ git init a/d0\n> > >      $ touch a/f0.txt\n> > >      $ git ls-files --others 'a/*.txt'\n> > >      a/d0/\n> > >      a/f0.txt\n> > >\n> > > It looks like the spurious a/d0/ entry doesn't show up until v2.27.0, in\n> > > particular 95c11ecc73 (Fix error-prone fill_directory() API; make it\n> > > only return matches, 2020-04-01).  Adding the author to the Cc.  (Sorry,\n> > > Elijah, I recall your frustration with dir.c from a previous ls-files\n> > > issue that I reported [1]).\n> >\n> > Thanks for digging in and coming up with a smaller list of steps to\n> > reproduce.  You are right that I dread reports that touch dir.c -- if\n> > I would have just ignored the first report back in March of 2018,\n> > there's a really, really long list of problems I could have avoided...\n> >\n> > I'll try to take a look in the next week.\n>\n> Should be solved by this fix:\n> https://lore.kernel.org/git/11a286b071ca8a6b96f4fba6658e9bafb9314be4.1597216356.git.gitgitgadget@gmail.com/\n"}]}