docs(git): record the verified deployment (task 0015)

Also note that `git config --global` lists only ~/.gitconfig and is not a
view of what git resolves, which misreads as the module's file being
ignored.
This commit was merged in pull request #8.
This commit is contained in:
2026-07-20 12:22:36 -04:00
parent 62eb6286b4
commit 4ecb86052b
2 changed files with 16 additions and 9 deletions

View File

@@ -29,11 +29,14 @@ Enabling it is therefore a step when adding a host.
The commit name is the literal `"alexion"` rather than `config.user.name`, which review raised as duplication.
A Unix login and a commit display name are separate concepts that merely coincide here, so binding them would let a host overriding its login silently rewrite the operator's commit identity.
The manual confirmation was met against the built configuration, not the running machine: `nixos-rebuild switch` needs sudo and has not run, so `~/.config/git/config` does not yet exist on `neogaia`.
The generated gitconfig was built from the `neogaia` toplevel and a commit driven under `env -i` with a scratch `HOME`, producing `alexion <contact@alexion.dev>` with no per-command override.
This proves the derivation rather than the deployment, and the live check remains owed at the next rebuild.
The manual confirmation is met on the running machine.
The operator rebuilt `neogaia`, `~/.config/git/config` is now a home-manager symlink, and a commit in a repository outside this checkout was authored `alexion <contact@alexion.dev>` in the real environment with no per-command override and no identity in the test repository's own config.
Review surfaced an unanticipated hazard that proved harmless.
Home-manager writes `~/.config/git/config`, while an undeclared `~/.gitconfig` also exists and outranks it per key.
It holds only a `tea` credential helper and no `user.*`, so it does not shadow the identity, confirmed by re-running the commit test with both files present.
Home-manager writes `~/.config/git/config`, while an undeclared `~/.gitconfig` also exists and outranks it on any key set in both.
It holds only a `tea` credential helper and no `user.*`, so it does not shadow the identity, confirmed against the deployed configuration.
Declaring that credential helper is a reasonable follow-up, since it will not survive a reimage.
This checkout's `.git/config` still sets the same identity, now redundant.
Removing it would let the module govern here too, so a future breakage surfaces instead of being masked.
It is local, untracked state, so it is left alone rather than changed as part of this task.

View File

@@ -38,10 +38,14 @@ The domain model (Host, Module, Skeleton, Auto-loader, Enable convention, overla
The two coincide here because the dev host runs this flake; they diverge on any machine that does not.
- Git identity is declared in the flake by `modules/git.nix`, which writes `alexion <contact@alexion.dev>` — the identity all history uses — on any host enabling `modules.git`.
Every new host has to enable it, so that a host reads as a full checklist of what it carries.
Once such a host has been rebuilt, a checkout on it needs no hand-written identity and keeps one across a reimage.
Two things mask a broken module, so neither is evidence it works: this checkout's `.git/config` carries the same identity, and home-manager writes `~/.config/git/config` while a `~/.gitconfig` also exists and outranks it per key.
That `~/.gitconfig` holds only a `tea` credential helper and no `user.*`, so it does not shadow the identity today, but it is undeclared and will not survive a reimage.
Verify the module by committing in a repository outside this checkout.
It is deployed on `neogaia` and verified: a commit in a repository outside this checkout is authored `alexion <contact@alexion.dev>` with no override.
Verify it that way rather than from this checkout, whose `.git/config` carries the same identity and would mask a broken module.
Home-manager writes `~/.config/git/config`, and `~/.gitconfig` is a second global file that git also reads, outranking it on any key set in both.
`~/.gitconfig` currently holds only a `tea` credential helper and no `user.*`, so it does not shadow the identity, but it is undeclared and will not survive a reimage.
- `git config --global` is a listing and writing filter over `~/.gitconfig` alone, **not** a view of what git resolves.
With both global files present it prints only `~/.gitconfig`, which reads as proof that `~/.config/git/config` is being ignored entirely.
It is not: drop `--global` and both files appear, each key resolving to the last file that sets it.
A `git config --global <key> <value>` write also lands in `~/.gitconfig`, the file that outranks the flake-managed one.
- The primary build/verify seam for any Host is `nix flake check`, which builds `checks.x86_64-linux.<host>` (the system toplevel); cheap targeted checks use `nix eval .#nixosConfigurations.<host>.config...`.
- A flake only sees **git-tracked** files, so a new file that has not been `git add`ed is invisible to evaluation even though it exists on disk.
The failure names the path and reads as if the file were missing: `error: Path 'secrets/shared.yaml' does not exist in Git repository`.