To understand op's repro look at the last two lines (objects in the tree) in each of their command outputs, not the files shown in the first few lines.
What I think op means is that the `testing` tree pointed in their first example is sorted after `testing.md` even though it's only called `testing` because it's being sorted as `testing/` and `/` is > `.` bytewise.
I'm not at a computer right now but it would be nice to test it with files named `testing.` and `testing0` since they are adjacent bytewise and would show the implicit forward slash more clearly with the tree object sitting between them.
This makes me wonder why Git can't just store an empty tree for empty dirs.
> This makes me wonder why Git can't just store an empty tree for empty dirs.
tl;dr: it can (see my other comment) and the empty tree is hardcoded. But since the index works with file paths and blobs, having no file means that there's no entry in the index
Turns out that Git does somewhat store dirs (in form of trees). See https://git-scm.com/book/en/v2/Git-Internals-Git-Objects (section "Tree Objects").
To understand op's repro look at the last two lines (objects in the tree) in each of their command outputs, not the files shown in the first few lines.
What I think op means is that the `testing` tree pointed in their first example is sorted after `testing.md` even though it's only called `testing` because it's being sorted as `testing/` and `/` is > `.` bytewise.
I'm not at a computer right now but it would be nice to test it with files named `testing.` and `testing0` since they are adjacent bytewise and would show the implicit forward slash more clearly with the tree object sitting between them.
This makes me wonder why Git can't just store an empty tree for empty dirs.
EDIT: did the Gist https://gist.github.com/alvaro-cuesta/bd0234e3e1a66819c7e9e9...
Notice the `git cat-file -p HEAD^{tree}` outputs.