Re: Possible bug in git-completion.sh

[Jeff King <peff@peff.net>]

On Fri, Jan 08, 2010 at 04:40:26PM +0100, Michael J Gruber wrote:

> Jon Schewe venit, vidit, dixit 08.01.2010 16:17:
> > If I create a directory "build" at the top of my git repository and then
> > add it to .gitignore, git behaves as expected and ignores the build
> > directory when checking status. Now git-completion.sh has some issues. I
> > have GIT_PS1_SHOWUNTRACKEDFILES to "1", so that I will be notified when
> > there are untracked files in my working directory. When I'm in the
> > top-level directory my prompt looks like expected, no '%'. However if I
> > change to the build directory I get a '%', even though git status shows
> > no untracked files. I see that git-completion.sh is using git ls-files
> > to check this and that function does indeed show output when in my build
> > directory. So the question here: Is git-completion.sh using ls-files
> > improperly or is ls-files behaving improperly?
> > 
> 
> Neither, but: output between status and ls-files is inconsistent. More
> specifically, different commands behave differently with respect to the
> treatment of subdirs. ls-files assumes "." implicitly, status does not.
> "git status ." should give you the same behavior is "git ls-files" in
> this regard.

It doesn't, and I think there is a bug in ls-files.

Try this:

  git init
  touch base-cruft
  mkdir subdir
  touch subdir/cruft
  echo subdir >.gitignore
  git status ;# shows gitignore and base-cruft
  git ls-files -o --exclude-standard ;# ditto
  cd subdir
  git status . ;# shows nothing, since everything in subdir is ignored
  git ls-files -o --exclude-standard ;# BUG: shows cruft

Yes, ls-files operates in the subdirectory, which means it should not
show cruft from the root (and it does not). But it should respect
.gitignore directives going all the way back to the root, and it
doesn't.

-Peff