Your dotfiles are not tracked by default

.tovioignore uses gitignore syntax. Its defaults are nothing like gitignore's, and this is the difference that surprises people hardest after an import.

The default ignores

The dot rule is by name — a leading dot — never by an operating-system hidden attribute, so tracking is identical on every platform. It also stops the walker descending into hidden trees at all, which is why a broken symlink buried in .venv cannot abort a scan.

Note the consequence for the ignore file itself: .tovioignore starts with a dot, so it is untracked unless you negate it.

Negating them

These are defaults, not hard exclusions. A repository-root .tovioignore overrides any of them with an ordinary gitignore negation:

!.tovioignore

!.github/

!.editorconfig

!.gitattributes

Do this before your first native commit after an import. Import writes trees straight from Git's object database, so those files are in your imported history — but the working-copy snapshot builds each new tree from a walk that skips them, so they will not be in the next commit's tree.

What no negation can re-include

Two paths are hard exclusions and are never snapshotted, whatever any ignore file or policy says:

• .tovio/, the repository's own metadata.
• Any file named tovio-recovery-key.txt.

That keeps local state and plaintext recovery material out of the content-addressed object store, which is a rule the system will not let you break by accident.

Ignoring is not hiding, and never protecting

Two things follow from that, and both matter.

First, a read policy wins over an ignore rule. If a path is both ignored and covered by an effective protective policy, it is tracked and sealed anyway — the walker will enter an otherwise-ignored directory precisely so a protected descendant cannot be missed. An ignore rule can never silently suppress encryption.

Second, and more important: .tovioignore is not access control. It is a convenience tracking filter. If you are reaching for it to keep a secret out of the repository, the right answer is a read policy, which lets the secret live in the repository encrypted, with a recorded list of who can read it. Ignoring a file protects nothing about the copy already on your disk.