Nguyễn Thái Ngọc Duy  <> 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?
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to