{"thread":{"id":"22978","subject":"wishlist: git gui not listing untracked files in unstaged list","startedAt":"2010-03-10T19:43:18Z","lastAt":"2010-03-11T12:52:59Z","messageCount":13,"participants":["MALAISE Pascal","Junio C Hamano","Shawn O. Pearce","Patrick Higgins","Jeff King","Johannes Sixt","Andreas Schwab"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"136535","messageId":"loom.20100310T203316-38@post.gmane.org","threadId":"22978","inReplyTo":null,"subject":"wishlist: git gui not listing untracked files in unstaged list","fromName":"MALAISE Pascal","fromEmail":"malaise@magic.fr","sentAt":"2010-03-10T19:43:18Z","receivedAt":"2010-03-10T19:43:18Z","isPatch":false,"sender":{"key":"malaise@magic.fr","avatar":null},"body":"Many projects are organized so that the result of compilation is mixed with\nsources.\nIt would be very useful to configure git gui so that untracked files are not\nlisted in the un-staged list.\nI have patched git gui, function rescan_stage2, line 1414 to do so:\n # set fd_lo [eval git_read ls-files --others -z $ls_others]\n set fd_lo [eval git_read ls-files -z $ls_others]\n\nbut it would be nice to make this behavior tunable via the \"Options...\" menu.\n"},{"id":"136538","messageId":"7vaaugrlqs.fsf@alter.siamese.dyndns.org","threadId":"22978","inReplyTo":"loom.20100310T203316-38@post.gmane.org","subject":"Re: wishlist: git gui not listing untracked files in unstaged list","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-03-10T19:59:39Z","receivedAt":"2010-03-10T19:59:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"MALAISE Pascal writes:\n\n> Many projects are organized so that the result of compilation is mixed with\n> sources.\n> It would be very useful to configure git gui so that untracked files are not\n> listed in the un-staged list.\n> I have patched git gui, function rescan_stage2, line 1414 to do so:\n> # set fd_lo [eval git_read ls-files --others -z $ls_others]\n> set fd_lo [eval git_read ls-files -z $ls_others]\n\nShouldn't this line instead be running this:\n\n ls-files --others --exclude-standard -z $ls_others\n\nso that it would use the usual .gitignore mechanism?\n"},{"id":"136539","messageId":"20100310200728.GD21994@spearce.org","threadId":"22978","inReplyTo":"7vaaugrlqs.fsf@alter.siamese.dyndns.org","subject":"Re: wishlist: git gui not listing untracked files in unstaged list","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2010-03-10T20:07:28Z","receivedAt":"2010-03-10T20:07:28Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> MALAISE Pascal writes:\n> \n> > Many projects are organized so that the result of compilation is mixed with\n> > sources.\n> > It would be very useful to configure git gui so that untracked files are not\n> > listed in the un-staged list.\n> > I have patched git gui, function rescan_stage2, line 1414 to do so:\n> > # set fd_lo [eval git_read ls-files --others -z $ls_others]\n> > set fd_lo [eval git_read ls-files -z $ls_others]\n> \n> Shouldn't this line instead be running this:\n> \n> ls-files --others --exclude-standard -z $ls_others\n> \n> so that it would use the usual .gitignore mechanism?\n\nUh. It does use the normal ignore systems. Above on\nline 1400 we add into the argument list for $ls_others\n--exclude-per-directory=.gitignore,\n--exclude-from=[gitdir info exclude], and\n--exclude-from=[get_config core.excludesfile].\n\nBut this code all predates --exclude-standard. Today we could just\nuse --exclude-standard and bypass all of that.\n\nI have no idea why the original poster isn't getting his ignore\nlist(s) to work. I also have no idea why dropping the --others\nflag from the ls-files command gets him a useful result.\n\nMaybe the problem is, the build artifacts are in a single\nsubdirectory (e.g. \"out/\"), and git status shows only \"out/\"\nas untracked. But git-gui shows all of the files (potentially\nthousands) because ls-files --others exploded the directory\ncontents recursively?\n\nBy dropping --others we hide that directory's contents by listing\nonly files that are already tracked. I'm surprised that didn't\nconfuse git-gui further, since a file was claimed to be both tracked\nand untracked at the same time during the rescan.\n\n-- \nShawn.\n"},{"id":"136541","messageId":"loom.20100310T214108-45@post.gmane.org","threadId":"22978","inReplyTo":"20100310200728.GD21994@spearce.org","subject":"Re: wishlist: git gui not listing untracked files in unstaged list","fromName":"MALAISE Pascal","fromEmail":"malaise@magic.fr","sentAt":"2010-03-10T20:57:03Z","receivedAt":"2010-03-10T20:57:03Z","isPatch":false,"sender":{"key":"malaise@magic.fr","avatar":null},"body":"I am not saying that the ignore lists don't work. They certainly work very well.\nI am just looking for a behavior of git-gui like \"git status -uno\" and\n\"git ls-files\", which both don't attempt to scan untracked files.\n\nMy problem is that my build makes a lib_Linux/ and a bin_linux/ subdirectory\nof my source dir - I could declare them in a gitignore, OK.\nBut my build also makes a symlink for each from bin_Linux/ to . \nand I don't want to declare these links one by one in an ignore list.\n\nI this is too problematic or un-natural for git-gui I will see if can generate\na .gitignore automatically in each source dir. In my makefile I have the list\nof .\n\nRegards \n"},{"id":"136544","messageId":"loom.20100310T225229-469@post.gmane.org","threadId":"22978","inReplyTo":"20100310200728.GD21994@spearce.org","subject":"Re: wishlist: git gui not listing untracked files in unstaged list","fromName":"Patrick Higgins","fromEmail":"patrick133t@yahoo.com","sentAt":"2010-03-10T22:00:41Z","receivedAt":"2010-03-10T22:00:41Z","isPatch":false,"sender":{"key":"patrick133t@yahoo.com","avatar":null},"body":"Shawn O. Pearce spearce.org> writes:\n\n> Junio C Hamano pobox.com> wrote:\n> I have no idea why the original poster isn't getting his ignore\n> list(s) to work. I also have no idea why dropping the --others\n> flag from the ls-files command gets him a useful result.\n\nI'm seeing a similar problem. For me, it's caused by defining\ncore.excludesfile to \"~/.gitexcludes\". The git config documentation\nsays that this will be expanded to my home directory. It appears that\ngit gui doesn't do this and instead runs \"git ls-files --others -z\n--exclude-from='~/.gitexcludes'\"\n\nThat chokes with:\n\nfatal: cannot use ~/.gitexcludes as an exclude file\n\nChanging core.excludesfile to use a fully-qualified path instead of ~/\nfixes the problem for me.\n"},{"id":"136545","messageId":"20100310221228.GA4223@sigill.intra.peff.net","threadId":"22978","inReplyTo":"loom.20100310T225229-469@post.gmane.org","subject":"Re: wishlist: git gui not listing untracked files in unstaged list","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-03-10T22:12:28Z","receivedAt":"2010-03-10T22:12:28Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Mar 10, 2010 at 10:00:41PM +0000, Patrick Higgins wrote:\n\n> Shawn O. Pearce spearce.org> writes:\n> \n> > Junio C Hamano pobox.com> wrote:\n> > I have no idea why the original poster isn't getting his ignore\n> > list(s) to work. I also have no idea why dropping the --others\n> > flag from the ls-files command gets him a useful result.\n> \n> I'm seeing a similar problem. For me, it's caused by defining\n> core.excludesfile to \"~/.gitexcludes\". The git config documentation\n> says that this will be expanded to my home directory. It appears that\n> git gui doesn't do this and instead runs \"git ls-files --others -z\n> --exclude-from='~/.gitexcludes'\"\n> \n> That chokes with:\n> \n> fatal: cannot use ~/.gitexcludes as an exclude file\n> \n> Changing core.excludesfile to use a fully-qualified path instead of ~/\n> fixes the problem for me.\n\nThis is an inconsistency in the way that tilde-expansion is handled. The\ncore.excludesfile config variable is expanded internally with the\n\"pathname\" magic (git_config_pathname). But handing the filename\ndirectly to ls-files --exclude-from does not do that expansion.\n\nSo either there is a bug in ls-files, which should expand from the\ncommand line, or one in git-gui, which should be using \"git config\n--path core.excludesfile\" to get the path.\n\n-Peff\n"},{"id":"136546","messageId":"20100310221403.GF21994@spearce.org","threadId":"22978","inReplyTo":"20100310221228.GA4223@sigill.intra.peff.net","subject":"Re: wishlist: git gui not listing untracked files in unstaged list","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2010-03-10T22:14:03Z","receivedAt":"2010-03-10T22:14:03Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Jeff King wrote:\n> This is an inconsistency in the way that tilde-expansion is handled. The\n> core.excludesfile config variable is expanded internally with the\n> \"pathname\" magic (git_config_pathname). But handing the filename\n> directly to ls-files --exclude-from does not do that expansion.\n> \n> So either there is a bug in ls-files, which should expand from the\n> command line, or one in git-gui, which should be using \"git config\n> --path core.excludesfile\" to get the path.\n\nI'd say its git-gui, yes? Doesn't my shell automatically do\n--exclude-from=~/my.list for me? Its not the command's job\nto do that expansion.\n\n-- \nShawn.\n"},{"id":"136550","messageId":"7v3a07q07a.fsf@alter.siamese.dyndns.org","threadId":"22978","inReplyTo":"20100310221403.GF21994@spearce.org","subject":"Re: wishlist: git gui not listing untracked files in unstaged list","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-03-10T22:30:17Z","receivedAt":"2010-03-10T22:30:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" writes:\n\n> Jeff King wrote:\n>> This is an inconsistency in the way that tilde-expansion is handled. The\n>> core.excludesfile config variable is expanded internally with the\n>> \"pathname\" magic (git_config_pathname). But handing the filename\n>> directly to ls-files --exclude-from does not do that expansion.\n>> \n>> So either there is a bug in ls-files, which should expand from the\n>> command line, or one in git-gui, which should be using \"git config\n>> --path core.excludesfile\" to get the path.\n>\n> I'd say its git-gui, yes? Doesn't my shell automatically do\n> --exclude-from=~/my.list for me? Its not the command's job\n> to do that expansion.\n\nI'd agree.\n"},{"id":"136551","messageId":"20100310223210.GC4223@sigill.intra.peff.net","threadId":"22978","inReplyTo":"20100310221403.GF21994@spearce.org","subject":"Re: wishlist: git gui not listing untracked files in unstaged list","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-03-10T22:32:10Z","receivedAt":"2010-03-10T22:32:10Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Mar 10, 2010 at 02:14:03PM -0800, Shawn O. Pearce wrote:\n\n> Jeff King wrote:\n> > This is an inconsistency in the way that tilde-expansion is handled. The\n> > core.excludesfile config variable is expanded internally with the\n> > \"pathname\" magic (git_config_pathname). But handing the filename\n> > directly to ls-files --exclude-from does not do that expansion.\n> > \n> > So either there is a bug in ls-files, which should expand from the\n> > command line, or one in git-gui, which should be using \"git config\n> > --path core.excludesfile\" to get the path.\n> \n> I'd say its git-gui, yes? Doesn't my shell automatically do\n> --exclude-from=~/my.list for me? Its not the command's job\n> to do that expansion.\n\nIt depends on the shell. Bash will expand it in _some_ cases (but not\nthis one). Dash never will:\n\n $ echo $BASH_VERSION\n 4.1.0(1)-release\n $ echo foo=~/foo ;# expands\n foo=/home/peff/foo\n $ echo --foo=~/foo ;# does not\n --foo=~/foo\n $ dash -c 'echo foo=~/foo' ;# does not\n foo=~/foo\n\nThat being said, my gut feeling is for git-gui to fix it, too. Shell\ncallers can use $HOME if they want.\n\n-Peff\n"},{"id":"136552","messageId":"20100310223650.GA4710@sigill.intra.peff.net","threadId":"22978","inReplyTo":"20100310223210.GC4223@sigill.intra.peff.net","subject":"Re: wishlist: git gui not listing untracked files in unstaged list","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-03-10T22:36:50Z","receivedAt":"2010-03-10T22:36:50Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Mar 10, 2010 at 05:32:10PM -0500, Jeff King wrote:\n\n> It depends on the shell. Bash will expand it in _some_ cases (but not\n> this one). Dash never will:\n> \n> $ echo $BASH_VERSION\n> 4.1.0(1)-release\n> $ echo foo=~/foo ;# expands\n> foo=/home/peff/foo\n> $ echo --foo=~/foo ;# does not\n> --foo=~/foo\n> $ dash -c 'echo foo=~/foo' ;# does not\n> foo=~/foo\n> \n> That being said, my gut feeling is for git-gui to fix it, too. Shell\n> callers can use $HOME if they want.\n\nBy the way, the only reason I hesitated on that in the first mail is\nthat it feels a little unelegant. If a config variable grows --path\nsemantics, _all_ script callers have to be updated. It might be nice to\nhave \"git config --dwim core.excludesfile\" which does the \"normal\"\nexpansion. But that would mean a central DWIM-list, and git config is\nsprinkled throughout the codebase, so it's probably not worth the\nrefactoring effort.\n\n-Peff\n"},{"id":"136556","messageId":"4B9896D4.2020106@viscovery.net","threadId":"22978","inReplyTo":"20100310223210.GC4223@sigill.intra.peff.net","subject":"Re: wishlist: git gui not listing untracked files in unstaged list","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2010-03-11T07:08:04Z","receivedAt":"2010-03-11T07:08:04Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Jeff King schrieb:\n> On Wed, Mar 10, 2010 at 02:14:03PM -0800, Shawn O. Pearce wrote:\n>> I'd say its git-gui, yes? Doesn't my shell automatically do\n>> --exclude-from=~/my.list for me? Its not the command's job\n>> to do that expansion.\n> \n> It depends on the shell. Bash will expand it in _some_ cases (but not\n> this one). Dash never will:\n> \n> $ echo $BASH_VERSION\n> 4.1.0(1)-release\n> $ echo foo=~/foo ;# expands\n> foo=/home/peff/foo\n\nThis is wrong, FWIW. Tilde expansion must happen only at the beginning of\na word or, when in an assignment, at the beginning of the assigned value\nor after any unquoted ':'. Note that in `echo foo=~/foo`, what looks like\nan assignment is *not* an assignment in POSIX shell lingo because it comes\nafter the command name.\n\nhttp://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_01\n\n-- Hannes\n"},{"id":"136558","messageId":"20100311071145.GA5919@sigill.intra.peff.net","threadId":"22978","inReplyTo":"4B9896D4.2020106@viscovery.net","subject":"Re: wishlist: git gui not listing untracked files in unstaged list","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-03-11T07:11:45Z","receivedAt":"2010-03-11T07:11:45Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Mar 11, 2010 at 08:08:04AM +0100, Johannes Sixt wrote:\n\n> > It depends on the shell. Bash will expand it in _some_ cases (but not\n> > this one). Dash never will:\n> > \n> > $ echo $BASH_VERSION\n> > 4.1.0(1)-release\n> > $ echo foo=~/foo ;# expands\n> > foo=/home/peff/foo\n> \n> This is wrong, FWIW. Tilde expansion must happen only at the beginning of\n> a word or, when in an assignment, at the beginning of the assigned value\n> or after any unquoted ':'. Note that in `echo foo=~/foo`, what looks like\n> an assignment is *not* an assignment in POSIX shell lingo because it comes\n> after the command name.\n\nThanks for the reference. I thought it was a bit funny when I wrote the\nabove, but just assumed it was implementation defined.\n\nI think it doesn't change our outcome, though. Even though we cannot\nrely on the shell to do such an expansion, it is still probably not sane\nto assume ls-files will do it. Git's expansion is connected with the\nconfig entry, not the use in ls-files, and it is git-gui's\nresponsibility to correctly expand as it reads the config.\n\n-Peff\n"},{"id":"136581","messageId":"m24oknc95g.fsf@igel.home","threadId":"22978","inReplyTo":"4B9896D4.2020106@viscovery.net","subject":"Re: wishlist: git gui not listing untracked files in unstaged list","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2010-03-11T12:52:59Z","receivedAt":"2010-03-11T12:52:59Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Johannes Sixt writes:\n\n> Jeff King schrieb:\n>> On Wed, Mar 10, 2010 at 02:14:03PM -0800, Shawn O. Pearce wrote:\n>>> I'd say its git-gui, yes? Doesn't my shell automatically do\n>>> --exclude-from=~/my.list for me? Its not the command's job\n>>> to do that expansion.\n>> \n>> It depends on the shell. Bash will expand it in _some_ cases (but not\n>> this one). Dash never will:\n>> \n>> $ echo $BASH_VERSION\n>> 4.1.0(1)-release\n>> $ echo foo=~/foo ;# expands\n>> foo=/home/peff/foo\n>\n> This is wrong, FWIW.\n\nIt's a bash extension and disabled in POSIX mode.\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"}]}