Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html