Re: wishlist: git gui not listing untracked files in unstaged list

["Shawn O. Pearce" <spearce@spearce.org>]

Junio C Hamano <gitster@pobox.com> wrote:
> MALAISE Pascal <malaise@magic.fr> writes:
> 
> > Many projects are organized so that the result of compilation is mixed with
> > sources.
> > It would be very useful to configure git gui so that untracked files are not
> > listed in the un-staged list.
> > I have patched git gui, function rescan_stage2, line 1414 to do so:
> >   # set fd_lo [eval git_read ls-files --others -z $ls_others]
> >   set fd_lo [eval git_read ls-files -z $ls_others]
> 
> Shouldn't this line instead be running this:
> 
>     ls-files --others --exclude-standard -z $ls_others
> 
> so that it would use the usual .gitignore mechanism?

Uh.  It does use the normal ignore systems.  Above on
line 1400 we add into the argument list for $ls_others
--exclude-per-directory=.gitignore,
--exclude-from=[gitdir info exclude], and
--exclude-from=[get_config core.excludesfile].

But this code all predates --exclude-standard.  Today we could just
use --exclude-standard and bypass all of that.

I have no idea why the original poster isn't getting his ignore
list(s) to work.  I also have no idea why dropping the --others
flag from the ls-files command gets him a useful result.

Maybe the problem is, the build artifacts are in a single
subdirectory (e.g. "out/"), and git status shows only "out/"
as untracked.  But git-gui shows all of the files (potentially
thousands) because ls-files --others exploded the directory
contents recursively?

By dropping --others we hide that directory's contents by listing
only files that are already tracked.  I'm surprised that didn't
confuse git-gui further, since a file was claimed to be both tracked
and untracked at the same time during the rescan.

-- 
Shawn.