Resolve note dates from git for git-backed vaults, keep mtime only for Local

[BattermanZ]

Summary

For a git-backed vault, the repository already holds the real dates. Hatchdoor currently ignores them and reads mtime_ns instead, which is a proxy that git actively destroys. Propose a date-resolution strategy chosen by vault source: git-backed vaults ask git, Local vaults keep the filesystem.

Why mtime is the wrong source specifically for git vaults

Git stores no mtime. Checkout stamps every file with the moment it ran. I cloned a repo with three years of history and checked:

113 .rs files    mtime 2026-09-10 08:52    every one, to the minute

The same files in the original working tree: Jun 6, Jul 14, Aug 40, Sep 53.

So a git-backed vault loses its entire writing history the first time it is cloned onto a new host, restored into a fresh container, or re-provisioned. Meanwhile the real dates were sitting in the repo the whole time, untouched.

A Local vault has no such alternative, which is why the two cases deserve different treatment rather than one lowest-common-denominator answer.

The discriminator already exists

VaultSource at src/vault_registry.rs:201:

• Local { path } has no history. Keep mtime, protected by Backlink rewrites stamp a fresh mtime on every referring note, destroying the vault's writing history #299.
• ExistingGit { .. } and ManagedGit { .. } have a repository. Ask it.

ExistingGit in LocalHistory mode still has a working repository, so it qualifies. Only Local falls back.

What to read, and the trap to avoid

Measured on a real 625-note vault, four candidate sources for the same chart:

month	mtime (current)	frontmatter created:	git first-add	net lines written
Feb	4	168	184	11,815
Mar	1	35	38	4,323
Apr	3	34	36	2,482
May	3	52	56	6,147
Jun	5	39	45	3,795
Jul	8	45	75	4,825
Aug	2	18	65	4,388
Sep	630	145	179	16,355

I would use first-add date per note, walking history forward with -M so renames carry the original date across. It answers "notes created per month", it is stable, and no bulk operation can move it.

The trap is the metric that looks like a drop-in replacement. "Last content-changing commit per note" is the obvious git analogue of mtime, and it does not work. Excluding pure renames entirely, September still comes out at 717 notes on my vault, because a backlink rewrite is a genuine content modification as far as git is concerned. #299 protects mtime from those rewrites, but nothing hides them from git history. Last-change from git inherits the same disease in a form that cannot be filtered, since Hatchdoor batches real edits and mechanical rewrites into the same auto-commit under the same author.

Net lines added per month is the honest option if the chart is meant to measure volume rather than count notes. September reads as busy at 3.4x the median, which is fair, because it was.

Caveats

• A shallow clone has no early history. Detect it and fall back rather than reporting everything as created at the graft point.
• vault_subdirectory means the walk must be scoped to the subdirectory, and rename following has to cope with a note moving in or out of it.
• One history walk over the whole repo, cached, not one git log per note. On my vault the full rename-tracking walk is fast enough to do at index time.
• This changes what the chart means, from last touched to created, so it needs the label changing to match. Ties into Writing Activity chart shows the 6 most recent months containing notes, not the last 6 months #298.

Related

• Writing Activity chart shows the 6 most recent months containing notes, not the last 6 months #298, the chart window
• Backlink rewrites stamp a fresh mtime on every referring note, destroying the vault's writing history #299, protecting mtime for the Local case