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

MALAISE Pascal [off-list ref] 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?

Junio C Hamano [off-list ref] wrote:

MALAISE Pascal [off-list ref] writes:

quoted

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.

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:

Junio C Hamano <gitster <at> pobox.com> wrote:
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.

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:

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

quoted

Junio C Hamano <gitster <at> pobox.com> wrote:
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.

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.

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 [off-list ref] 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.

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.

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

Jeff King [off-list ref] wrote:

quoted

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.

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.

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:

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.

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:

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

quoted

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.

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

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:

quoted

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

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.

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