[Bug] git status -unormal -- 'foo[b]/' won't display content of 'foo[b]/

Hello,

I found what look like a bug in git status: `git status -unormal foo[b]/` won't output the content of the directory foo[b] when `git status -unormal foo/` will output the content of the directory foo:

  $ mkdir 'foo[b]'
  $ touch 'foo[b]/bar'
  $ git status -unormal 'foo[b]/'
  On branch master
  Untracked files:
    (use "git add <file>..." to include in what will be committed)

          foo[b]/

  nothing added to commit but untracked files present (use "git add" to track)
  $ mkdir 'foo'
  $ touch 'foo/bar'
  $ git status -unormal 'foo/'
  On branch master
  Untracked files:
    (use "git add <file>..." to include in what will be committed)

          foo/bar

  nothing added to commit but untracked files present (use "git add" to track)

The documentation of git status contain nothing about treating bracket specially. Quoting the brackets do not solve the problem.

see https://github.com/magit/magit/issues/1512 for discussion about it (in the case of git status --porcelain).

On 2014-09-21 20.04, Rémi Vanicat wrote:

git status takes a "pathspec" as a parameter, which is not the same as a filename. A pathspec can contain wildcards like '*' or '?' or things like "*[ch]". This is known as shell glob syntax (or so), and used automatically by all shells.

Git allows to use "git add *.[ch]" (where the shell expands the glob) or "git add '*.[ch]'" where Git does the expansion.

You can turn of the glob handling in a pathspec by using this:   
 
GIT_LITERAL_PATHSPECS=1 git status -unormal 'foo[b]/'
On branch master

Initial commit

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        foo[b]/bar
-------------------
Side note:
If somebody feels that the documentation can be better: we appreciate patches.

On Mon, Sep 22, 2014 at 2:52 AM, Torsten Bögershausen <tboegi@web.de> wrote:

From the top of my head, pathspec should match as if it's literal string too. Not sure if it applies to this case. I'll check later..

On Mon, Sep 22, 2014 at 8:24 AM, Duy Nguyen <pclouds@gmail.com> wrote:

FWIW the "problem" is in dir.c, function common_prefix_len(). We use this one to determine a shared parent directory, e.g. foo/bar and foo/baarr share "foo/", so that we could start looking for untracked files from "foo" instead of ".". The shared directory search only cares about non-wildcard letters. So in the case of "foo/" it finds the "shared" dir "foo", but in "foo[b]/" it stops at '[' and decides the shared dir is ".".

But this difference should not lead to any differences in output because that's more about traversal optimization. But somehow we treat the first directory different than subdirs. If a subdir is entirely untracked/ignored, we show "subdir/" (with -unormal) but if it's the first examined directory then we show everything inside. This is something we should fix if you guys really depend on a consistent behavior. But if it's fixed, then "foo/" case above would show "foo/" not "foo/bar". Or just call it a quirk of -unormal and magit should use -uall instead.