Ignore files with .tovioignore

Create a .tovioignore file at the repository root. The syntax is gitignore syntax: one glob per line, # for comments, ! to negate, trailing / for directories.

# build artifactstarget/node_modules/*.log# keep one tracked log!important.log

What is already excluded, with no file at all

This surprises people, so it is worth knowing before you write a single pattern:

• Hidden entries. Anything whose name starts with a dot — .git/, .idea/, .vscode/, .env — and everything beneath a hidden directory, at any depth. The rule is by name, so it behaves identically on every platform.
• Build and scratch directories. target/ and node_modules/ at the repository root.

Those are defaults, not permanent exclusions. Re-include what you actually want tracked with a negation:

# track CI workflows and one hidden file — but nothing else hidden!.github/!.editorconfig# keep the ignore file itself under version control!.tovioignore

Two things no negation and no policy can re-include: TOVIO's own metadata under .tovio/, and tovio-recovery-key.txt. Those are hard exclusions.

Why you notice this sooner than in Git

There is no staging area, so anything not ignored is already part of your current change. In Git an unignored build directory sits in “untracked files” until you add it. In TOVIO it is simply in your change. Set this up early.

Checking what is tracked

tovio status

If files you did not expect appear, they need a pattern.

When the file will not parse

An unparseable .tovioignore is TVO-CLI-008 (“Invalid .tovioignore”, exit 2) and names the offending pattern. It is a hard usage error, not a warning — a silently-ignored ignore file would quietly start tracking your build output.

Already tracked?

Adding a pattern stops future tracking; it does not remove what is already committed. Remove the file and commit that removal.

Ignore is not privacy

Ignoring a file keeps it out of history. It does not protect a file that is committed, and it is not a security boundary. For that you need a policy, which encrypts the content at snapshot time — see the permissions collection. A protective read policy even overrides the hidden default: a hidden path a policy covers is tracked and sealed regardless.