I think future changes of DirstateItem internals will be easier if state == 'd' is never something we need to represent in DirstateItem. We can do that by changing directories to return a list of (path, mtime) instead of (path, DirstateItem), and updating the two callers (debugcommands.debugdirstate and dirstate.foldmap).

In D10983#167824, @SimonSapin wrote:

I think future changes of DirstateItem internals will be easier if state == 'd' is never something we need to represent in DirstateItem. We can do that by changing directories to return a list of (path, mtime) instead of (path, DirstateItem), and updating the two callers (debugcommands.debugdirstate and dirstate.foldmap).

I am not too convinced that treating directory in a different way is win. What's your motivation there ?

Currently a dirstatetuple / dirstateitem only exists for paths that are present in dirstate-v1 and for which dirstate.__contains__ returns true. It contains a state whose value is always n, a, r, or m. However we want to move towards not having this state at all other than in dirstate-v1 parsing and serialization. Adding more cases to handle makes that more difficult and isn’t necessary.

In Rust code the DirstateEntry struct corresponds to dirstatetuple / dirstateitem. Current in the tree dirstate map, "directory" nodes don’t have a DirstateEntry at all. (And soon entry-less nodes won’t be just directories but will also potentially include ignored or unknown files.) When adding this directories iterator I only made it create tuples that look kinda like dirstatetuple as a shortcut because that’s what debugcommands.debugstate was already handling.

In D10983#167853, @SimonSapin wrote:

Currently a dirstatetuple / dirstateitem only exists for paths that are present in dirstate-v1 and for which dirstate.__contains__ returns true. It contains a state whose value is always n, a, r, or m. However we want to move towards not having this state at all other than in dirstate-v1 parsing and serialization. Adding more cases to handle makes that more difficult and isn’t necessary.
In Rust code the DirstateEntry struct corresponds to dirstatetuple / dirstateitem. Current in the tree dirstate map, "directory" nodes don’t have a DirstateEntry at all. (And soon entry-less nodes won’t be just directories but will also potentially include ignored or unknown files.) When adding this directories iterator I only made it create tuples that look kinda like dirstatetuple as a shortcut because that’s what debugcommands.debugstate was already handling.

Given that we are moving toward adding more thing in the dirstate(map) in general, having an explicit entry for all of them, instead of various special case, seems simpler. I expect us to introduce dedicated boolean property to differenciate the one Mercurial will directly care about (tracked in wc on in parent) and the other ones.