{"thread":{"id":"37611","subject":"[Bug] git status -unormal -- 'foo[b]/' won't display content of 'foo[b]/","startedAt":"2014-09-21T18:04:08Z","lastAt":"2014-09-22T13:01:44Z","messageCount":4,"participants":["Rémi Vanicat","Torsten Bögershausen","Duy Nguyen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"249726","messageId":"87vbogq293.dlv@gmail.com","threadId":"37611","inReplyTo":null,"subject":"[Bug] git status -unormal -- 'foo[b]/' won't display content of 'foo[b]/","fromName":"Rémi Vanicat","fromEmail":"vanicat@debian.org","sentAt":"2014-09-21T18:04:08Z","receivedAt":"2014-09-21T18:04:08Z","isPatch":false,"sender":{"key":"vanicat@debian.org","avatar":"https://gravatar.com/avatar/cd491a7f4c221349809a60f88fc21326b97cce2a705e318898aa74851db92409?d=mp&s=160"},"body":"Hello,\n\nI found what look like a bug in git status:\n`git status -unormal foo[b]/` won't output the content of the directory\nfoo[b] when `git status -unormal foo/` will output the content of the\ndirectory foo: \n\n $ mkdir 'foo[b]'\n $ touch 'foo[b]/bar'\n $ git status -unormal 'foo[b]/'\n On branch master\n Untracked files:\n (use \"git add ...\" to include in what will be committed)\n\n foo[b]/\n\n nothing added to commit but untracked files present (use \"git add\" to track)\n $ mkdir 'foo'\n $ touch 'foo/bar'\n $ git status -unormal 'foo/'\n On branch master\n Untracked files:\n (use \"git add ...\" to include in what will be committed)\n\n foo/bar\n\n nothing added to commit but untracked files present (use \"git add\" to track)\n\nThe documentation of git status contain nothing about treating bracket\nspecially. Quoting the brackets do not solve the problem.\n\nsee https://github.com/magit/magit/issues/1512 for discussion about it\n(in the case of git status --porcelain).\n-- \nRémi Vanicat\n"},{"id":"249727","messageId":"541F2C96.6050101@web.de","threadId":"37611","inReplyTo":"87vbogq293.dlv@gmail.com","subject":"Re: [Bug] git status -unormal -- 'foo[b]/' won't display content of 'foo[b]/","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2014-09-21T19:52:54Z","receivedAt":"2014-09-21T19:52:54Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On 2014-09-21 20.04, Rémi Vanicat wrote:\n> Hello,\n> \n> I found what look like a bug in git status:\n> `git status -unormal foo[b]/` won't output the content of the directory\n> foo[b] when `git status -unormal foo/` will output the content of the\n> directory foo: \n> \n> $ mkdir 'foo[b]'\n> $ touch 'foo[b]/bar'\n> $ git status -unormal 'foo[b]/'\n> On branch master\n> Untracked files:\n> (use \"git add ...\" to include in what will be committed)\n> \n> foo[b]/\n> \n> nothing added to commit but untracked files present (use \"git add\" to track)\n> $ mkdir 'foo'\n> $ touch 'foo/bar'\n> $ git status -unormal 'foo/'\n> On branch master\n> Untracked files:\n> (use \"git add ...\" to include in what will be committed)\n> \n> foo/bar\n> \n> nothing added to commit but untracked files present (use \"git add\" to track)\n> \n> The documentation of git status contain nothing about treating bracket\n> specially. Quoting the brackets do not solve the problem.\n> \n> see https://github.com/magit/magit/issues/1512 for discussion about it\n> (in the case of git status --porcelain).\n>\ngit status takes a \"pathspec\" as a parameter, which is not the same as a filename.\nA pathspec can contain wildcards like '*' or '?' or things like \"*[ch]\".\nThis is known as shell glob syntax (or so), and used automatically by all shells.\n\nGit allows to use \"git add *.[ch]\" (where the shell expands the glob) or\n\"git add '*.[ch]'\" where Git does the expansion.\n\nYou can turn of the glob handling in a pathspec by using this: \n \nGIT_LITERAL_PATHSPECS=1 git status -unormal 'foo[b]/'\nOn branch master\n\nInitial commit\n\nUntracked files:\n (use \"git add ...\" to include in what will be committed)\n\n foo[b]/bar\n-------------------\nSide note:\nIf somebody feels that the documentation can be better: we appreciate patches.\n"},{"id":"249732","messageId":"CACsJy8AyUKKhsdij6HAf_G=+v5xhio2-KS7HGAGY-1kzOnhf2w@mail.gmail.com","threadId":"37611","inReplyTo":"541F2C96.6050101@web.de","subject":"Re: [Bug] git status -unormal -- 'foo[b]/' won't display content of 'foo[b]/","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2014-09-22T01:24:49Z","receivedAt":"2014-09-22T01:24:49Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Mon, Sep 22, 2014 at 2:52 AM, Torsten Bögershausen wrote:\n> git status takes a \"pathspec\" as a parameter, which is not the same as a filename.\n> A pathspec can contain wildcards like '*' or '?' or things like \"*[ch]\".\n> This is known as shell glob syntax (or so), and used automatically by all shells.\n>\n> Git allows to use \"git add *.[ch]\" (where the shell expands the glob) or\n> \"git add '*.[ch]'\" where Git does the expansion.\n\nFrom the top of my head, pathspec should match as if it's literal\nstring too. Not sure if it applies to this case. I'll check later..\n-- \nDuy\n"},{"id":"249733","messageId":"CACsJy8Dv9QxFyW32+vFQ+GE2QZyXHzoG-_ABMx3ARW=WSti2ng@mail.gmail.com","threadId":"37611","inReplyTo":"CACsJy8AyUKKhsdij6HAf_G=+v5xhio2-KS7HGAGY-1kzOnhf2w@mail.gmail.com","subject":"Re: [Bug] git status -unormal -- 'foo[b]/' won't display content of 'foo[b]/","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2014-09-22T13:01:44Z","receivedAt":"2014-09-22T13:01:44Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Mon, Sep 22, 2014 at 8:24 AM, Duy Nguyen wrote:\n> On Mon, Sep 22, 2014 at 2:52 AM, Torsten Bögershausen wrote:\n>> git status takes a \"pathspec\" as a parameter, which is not the same as a filename.\n>> A pathspec can contain wildcards like '*' or '?' or things like \"*[ch]\".\n>> This is known as shell glob syntax (or so), and used automatically by all shells.\n>>\n>> Git allows to use \"git add *.[ch]\" (where the shell expands the glob) or\n>> \"git add '*.[ch]'\" where Git does the expansion.\n>\n> From the top of my head, pathspec should match as if it's literal\n> string too. Not sure if it applies to this case. I'll check later..\n\nFWIW the \"problem\" is in dir.c, function common_prefix_len(). We use\nthis one to determine a shared parent directory, e.g. foo/bar and\nfoo/baarr share \"foo/\", so that we could start looking for untracked\nfiles from \"foo\" instead of \".\". The shared directory search only\ncares about non-wildcard letters. So in the case of \"foo/\" it finds\nthe \"shared\" dir \"foo\", but in \"foo[b]/\" it stops at '[' and decides\nthe shared dir is \".\".\n\nBut this difference should not lead to any differences in output\nbecause that's more about traversal optimization. But somehow we treat\nthe first directory different than subdirs. If a subdir is entirely\nuntracked/ignored, we show \"subdir/\" (with -unormal) but if it's the\nfirst examined directory then we show everything inside. This is\nsomething we should fix if you guys really depend on a consistent\nbehavior. But if it's fixed, then \"foo/\" case above would show \"foo/\"\nnot \"foo/bar\". Or just call it a quirk of -unormal and magit should\nuse -uall instead.\n-- \nDuy\n"}]}