git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Possible bug in git-completion.sh

From
Jeff King <peff@peff.net>
Date
Jan 8, 2010, 16:24 UTC
Message-ID
<20100108162404.GA5799@coredump.intra.peff.net>
In-Reply-To
<4B4751EA.8060707@drmicha.warpmail.net>
On Fri, Jan 08, 2010 at 04:40:26PM +0100, Michael J Gruber wrote:
Show 19 quoted lines
> 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
Previous: Michael J GruberNext: Junio C Hamano
Message 3 of 28 in “Possible bug in git-completion.sh”
  1. Jon ScheweJan 8, 2010
  2. Michael J GruberJan 8, 2010
  3. Jeff KingJan 8, 2010
  4. Junio C HamanoJan 8, 2010
  5. Jeff KingJan 8, 2010
  6. Junio C HamanoJan 8, 2010
  7. Junio C HamanoJan 8, 2010
  8. Jeff KingJan 8, 2010
  9. Jeff KingJan 8, 2010
  10. Junio C HamanoJan 8, 2010
  11. Junio C HamanoJan 8, 2010
  12. ls-files: fix overeager pathspec optimizationJunio C Hamano, Jan 8, 2010
  13. Linus TorvaldsJan 8, 2010
  14. Junio C HamanoJan 8, 2010
  15. Junio C HamanoJan 9, 2010
  16. Linus TorvaldsJan 9, 2010
  17. Junio C HamanoJan 9, 2010
  18. Linus TorvaldsJan 9, 2010
  19. Jeff KingJan 9, 2010
  20. Junio C HamanoJan 9, 2010
  21. 1/4 t3001: test ls-files -o ignored/dirJunio C Hamano, Jan 9, 2010
  22. 2/4 read_directory_recursive(): refactor handling of a single path into a separate functionJunio C Hamano, Jan 9, 2010
  23. 3/4 read_directory(): further split treat_path()Junio C Hamano, Jan 9, 2010
  24. 4/4 ls-files: fix overeager pathspec optimizationJunio C Hamano, Jan 9, 2010
  25. Jeff KingJan 12, 2010
  26. Junio C HamanoJan 9, 2010
  27. Linus TorvaldsJan 9, 2010
  28. Junio C HamanoJan 10, 2010

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.