Re: Possible bug in git-completion.sh

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

Jon Schewe venit, vidit, dixit 08.01.2010 16:17:

quoted

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