Order glob matches by path, not by interning order (fixes #171)

[typeless]

glob_expand sorted its Vec<StringId> results with std::ranges::sort(results). StringId is an enum class over the interning handle, and handles are issued sequentially on first intern, so that sorted by readdir order, not by path. The sort read as a canonicalization and was not one.

That order reaches cmd->inputs unchanged, %f concatenates in it, and compute_command_identity hashes the expanded text — so identical trees on two machines produced different command lines (different binaries), and command identity, the cross-build join key, varied with filesystem enumeration for every glob rule.

Sorting by the interned string matches what the identity hash already assumes, and matches tup: its glob query walks node_dir_index on (dir, name), so matches arrive in name order.

Measured

Directory enumerating (ls -U) as bravo mike zeta yankee alpha charlie, rule : d/*.txt |> echo %f > %o |> order.txt:

before: d/bravo.txt d/mike.txt d/zeta.txt d/yankee.txt d/alpha.txt d/charlie.txt
after:  d/alpha.txt d/bravo.txt d/charlie.txt d/mike.txt d/yankee.txt d/zeta.txt

Index version

15 → 16. Every glob-fed command's identity changes, so v15 identities no longer join. Rejecting them costs the rebuild those commands need anyway, and avoids a scoped build merging the stale twin back in beside the new one.

Test

The new scenario fixes interning order instead of trusting the filesystem to enumerate out of order: it interns the paths in reverse-lexicographic order before globbing, so handle order is deterministically the reverse of path order. It covers both the flat listing and the ** walk. Observed failing first:

test_glob.cpp:312: FAILED:
  REQUIRE( expanded("*.txt") == std::vector<std::string_view>{ paths[0], paths[1], paths[4] } )
with expansion:
  { "gord_zeta.txt", "gord_bravo.txt", "gord_alpha.txt" }
  ==
  { "gord_alpha.txt", "gord_bravo.txt", "gord_zeta.txt" }

make test green (142309 assertions, 616 cases, 32 e2e shards); make tidy and make iwyu clean.

🤖 Generated with Claude Code

https://claude.ai/code/session_01TLob4Ef3qyMd3Dnp9q3XmA

[github-actions]

PR metrics

Performance (gcc example, Linux)

Workload	Instructions	CPU time	Page faults	D1 miss	LL miss	Wall	Peak RSS
parse	1073 M	0.5 s	14.1 k	0.8%	0.1%	0.517 s	30.8 MB (+0.1MB)
dry-run	1786 M (+0.1%)	0.6 s	16.6 k	0.9%	0.1%	0.617 s	40.1 MB

Deterministic signals: instructions (cachegrind-simulated instruction reads — exact across runs, no PMU needed), page faults, peak RSS, and the cachegrind D1/LL miss rates. CPU time is user+sys from time(1).

Internal statistics (gcc example, up-to-date dry run)

Metric	Value
Tupfiles parsed	24
Commands	3545
Commands scheduled	0
Files checked	5818
Files changed	0
Files in index	6087
Graph edges	367913
Index size (bytes)	7264970
Implicit deps	330624
Hash computations	0
Hashes skipped (stat cache)	5818
Stat calls	5869
Parse time (ms)	493.4
Total time (ms)	601.7
Runner CPU	AMD EPYC 9V74 80-Core Processor

Counters from putup -n --stat on the fully-built gcc example (up-to-date dry run): deterministic work measures — a jump in commands scheduled, hash computations, or stat calls is a real behavior change, not noise. Timings are the minimum over repeated runs, compared only against a baseline from the same CPU model; the counters are the regression signal.
Timing deltas suppressed: baseline ran on different hardware (AMD EPYC 7763 64-Core Processor).

Binary size (Linux)

Binary	.text	.data	.bss	File
putup	494 KB (+0.7%)	1.7 KB	98.7 KB	582.8 KB (+0.9%)

Test coverage (lines)

Overall	Median file	Min file	Max file
86.6% (+0.1pp)	94.9%	0.0% src/platform/path-posix.cpp	100.0% include/pup/core/arena.hpp

103 files · 14986/17313 lines covered

Deltas vs main@fa93fb08c.

Updated for a65ea19