On Wed, Aug 5, 2020 at 6:54 PM Kyle Meyer [off-list ref] wrote:

christian w writes:

quoted

Sorry for the insufficient reproduction steps.

I managed to figure out it has something to do with git repos within
git repos. It happened to us because of go packages that are inside
our repo. These are the reproduction steps that work for me
consistently using Go version go1.14.4 darwin/amd64. This is the repo
that gets cloned into src/golang.org/x/debug by the go get command:
https://github.com/golang/debug/tree/66ec140f2f72d15dc6133502edd2bb7238b1740c

$ mkdir testdir
$ cd testdir
$ git init .
$ GOPATH=$(pwd) go get -u golang.org/x/debug/ || true
$ git ls-files --others '*.txt'#
src/golang.org/x/debug/

Okay, removing Go from the equation:

     $ # in fresh repo
     $ mkdir a
     $ git init a/d0
     $ touch a/f0.txt
     $ git ls-files --others 'a/*.txt'
     a/d0/
     a/f0.txt

It looks like the spurious a/d0/ entry doesn't show up until v2.27.0, in
particular 95c11ecc73 (Fix error-prone fill_directory() API; make it
only return matches, 2020-04-01).  Adding the author to the Cc.  (Sorry,
Elijah, I recall your frustration with dir.c from a previous ls-files
issue that I reported [1]).

Thanks for digging in and coming up with a smaller list of steps to
reproduce.  You are right that I dread reports that touch dir.c -- if
I would have just ignored the first report back in March of 2018,
there's a really, really long list of problems I could have avoided...

I'll try to take a look in the next week.

[1] https://lore.kernel.org/git/CABPp-BFG3FkTkC=L1v97LUksndkOmCN8ZhNJh5eoNdquE7v9DA@mail.gmail.com/ (local)