Re: [PATCH v2 0/9] About the trailing slashes

Nguyễn Thái Ngọc Duy  [off-list ref] writes:

While looking at this, I found a funny behavior of fill_directory.

  $ git init
  $ mkdir b
  $ >b/c
  $ >b/d
  $ git status b
  Untracked files:
          b/
  $ git status b/
  Untracked files:
          b/c b/d

Notice how the trailing slash produces different untracked listing.
This is because of common_prefix_len(). In the "b" case,
common_prefix_len() returns empty prefix, so read_directory reads top
directory, traverses through, reaches "b" and eventually calls
treat_directory() on it, which results in "b/" in the output.

In the "b/" case, common_prefix_len() found the prefix "b", so
read_directory() starts at "b" instead of b's parent.
treat_directory() is never called on "b" itself, which results in
"b/c" and "b/d".

Hmm, this feels like a borderline case.

If the user asked "git status ?", or even "git status '?'", it seems
to me that the user wanted to get "git status" output but with a
scope limited to top-level entries with a single letter.  And the
unlimited output asks to consolidate output for directories that
have nothing interesting.  "git status b" and "git status '[b]'" are
asking similar thing, but not just limiting the scope to any one
letter but to 'b'.  So the output you showed above looks correct to
me.  On the other hand, the other request "git status b/" seems to
me that the user is very aware that 'b' is a directory and wants to
look inside, so again the output you showed looks correct to me.

How does "git status '[b]/'" behave?

On Sat, Jan 25, 2014 at 2:22 AM, Junio C Hamano [off-list ref] wrote:

How does "git status '[b]/'" behave?

It outputs "b/" (like "git status b"). I think that's because
common_prefix_len() stops looking at the first wildcard char, '['. So
common prefix is empty, just like "b".
-- 
Duy