wishlist: git gui not listing untracked files in unstaged list

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]

but it would be nice to make this behavior tunable via the "Options..." menu.

MALAISE Pascal <malaise@magic.fr> writes:

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?

Junio C Hamano <gitster@pobox.com> wrote:

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.

I am not saying that the ignore lists don't work. They certainly work very well. I am just looking for a behavior of git-gui like "git status -uno" and "git ls-files", which both don't attempt to scan untracked files.

My problem is that my build makes a lib_Linux/ and a bin_linux/ subdirectory of my source dir - I could declare them in a gitignore, OK. But my build also makes a symlink for each <exe> from bin_Linux/<exe> to . and I don't want to declare these links one by one in an ignore list.

I this is too problematic or un-natural for git-gui I will see if can generate a .gitignore automatically in each source dir. In my makefile I have the list of <exe>.

Regards 

Shawn O. Pearce <spearce <at> spearce.org> writes:

I'm seeing a similar problem. For me, it's caused by defining core.excludesfile to "~/.gitexcludes". The git config documentation says that this will be expanded to my home directory. It appears that git gui doesn't do this and instead runs "git ls-files --others -z --exclude-from='~/.gitexcludes'"

That chokes with:

fatal: cannot use ~/.gitexcludes as an exclude file

Changing core.excludesfile to use a fully-qualified path instead of ~/ fixes the problem for me.

On Wed, Mar 10, 2010 at 10:00:41PM +0000, Patrick Higgins wrote:

This is an inconsistency in the way that tilde-expansion is handled. The core.excludesfile config variable is expanded internally with the "pathname" magic (git_config_pathname). But handing the filename directly to ls-files --exclude-from does not do that expansion.

So either there is a bug in ls-files, which should expand from the command line, or one in git-gui, which should be using "git config --path core.excludesfile" to get the path.

-Peff

Jeff King <peff@peff.net> wrote:

I'd say its git-gui, yes? Doesn't my shell automatically do --exclude-from=~/my.list for me? Its not the command's job to do that expansion.

"Shawn O. Pearce" <spearce@spearce.org> writes:

I'd agree.

On Wed, Mar 10, 2010 at 02:14:03PM -0800, Shawn O. Pearce wrote:

It depends on the shell. Bash will expand it in _some_ cases (but not this one). Dash never will:

  $ echo $BASH_VERSION
  4.1.0(1)-release
  $ echo foo=~/foo ;# expands
  foo=/home/peff/foo
  $ echo --foo=~/foo ;# does not
  --foo=~/foo
  $ dash -c 'echo foo=~/foo' ;# does not
  foo=~/foo

That being said, my gut feeling is for git-gui to fix it, too. Shell callers can use $HOME if they want.

-Peff

On Wed, Mar 10, 2010 at 05:32:10PM -0500, Jeff King wrote:

By the way, the only reason I hesitated on that in the first mail is that it feels a little unelegant. If a config variable grows --path semantics, _all_ script callers have to be updated. It might be nice to have "git config --dwim core.excludesfile" which does the "normal" expansion. But that would mean a central DWIM-list, and git config is sprinkled throughout the codebase, so it's probably not worth the refactoring effort.

-Peff

Jeff King schrieb:

This is wrong, FWIW. Tilde expansion must happen only at the beginning of a word or, when in an assignment, at the beginning of the assigned value or after any unquoted ':'. Note that in `echo foo=~/foo`, what looks like an assignment is *not* an assignment in POSIX shell lingo because it comes after the command name.

http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_01

-- Hannes

On Thu, Mar 11, 2010 at 08:08:04AM +0100, Johannes Sixt wrote:

Thanks for the reference. I thought it was a bit funny when I wrote the above, but just assumed it was implementation defined.

I think it doesn't change our outcome, though. Even though we cannot rely on the shell to do such an expansion, it is still probably not sane to assume ls-files will do it. Git's expansion is connected with the config entry, not the use in ls-files, and it is git-gui's responsibility to correctly expand as it reads the config.

-Peff

Johannes Sixt <j.sixt@viscovery.net> writes:

It's a bash extension and disabled in POSIX mode.

Andreas.