The merkle root folds sorted file records - what else can change it besides content edits?

[camillejackson]

merkleRoot sorts the file records by path before folding, which makes it independent of discovery order. But I am trying to understand the full surface: if I move a file to a different directory without touching its bytes, does the root change? And what about file metadata like permissions or timestamps?

[michellsilva]

The root changes on three axes - path, size, and content digest - and the sort only removes discovery order from the equation, not placement.

1. A move changes the root. The fold includes the path field, so renaming or relocating a file with identical bytes produces a different root. That is intentional: provenance is about the artifact as it sits in the workspace, and a move is a real change to what you would ship.

2. Sorting makes the root canonical, nothing more. Two scans that find the same set of files in different order must produce the same root; that is what the sort guarantees. It does not normalize paths - ./a.txt and a.txt are different strings unless the scanner normalizes before the record is built.

3. Size is in the fold but is not redundant. Because the fields are length-prefixed, a path/digest pair cannot bleed into its neighbor; the explicit size also makes truncation detectable without re-hashing. The digest itself is streamed SHA-256 (hashFile), so an edit anywhere flips it.

4. What is deliberately not in the root: permissions, ownership, extended attributes, and timestamps. The root is content-and-placement only, which is exactly what makes it deterministic across machines - the same workspace copied to a different filesystem yields the same root. If you ever need mode bits in provenance you would add a field, but then you inherit platform differences in exchange.

So: bytes edit, size change, and move/rename all change the root. mtime churn alone does not - which is the property that makes verify useful after a checkout.