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).
--
Rémi Vanicat
On 2014-09-21 20.04, Rémi Vanicat wrote:
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).
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 [off-list ref] 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.
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..
--
Duy
On Mon, Sep 22, 2014 at 8:24 AM, Duy Nguyen [off-list ref] wrote:
On Mon, Sep 22, 2014 at 2:52 AM, Torsten Bögershausen [off-list ref] wrote:
quoted
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.
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..
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.
--
Duy