Adopting It

Adopting it on a repository that already exists

The first lgit check on a repository with history will produce findings. That is the tool working. What decides whether it survives the week is what you do in the next hour.

Start with errors only

lgit check .
lgit list -project=$PWD -severity=error

Errors are the things that are wrong by any reading: a tracked .env, an unresolved merge marker, a secret in the tree. There are usually few of them and they are usually worth fixing immediately.

Warnings are next. Info findings are the audit layer and are hidden by default in the extension for good reason: they are context, not a task list.

Use lgit fix before deciding anything

lgit fix <id>

For eight gates it prints the exact commands rather than a paragraph of advice. Before you decide a finding is noise, read what it wants: presence-style gates in particular are usually a one-line fix, and the extension ships quick fixes that write the missing file for you.

The three ways to silence something, in order of preference

1. An inline directive, with a reason.

# l0git: ignore from_latest reason: dev base image, never released
FROM node:latest

This is the best option and the one to reach for first, because it emits an override_accepted finding. The exception stays visible instead of disappearing into a config file nobody opens. In six months the reason is right next to the line it excuses.

2. A gate option, when the gate is right and its parameters are wrong for you:

{ "gate_options": { "large_file_tracked": { "threshold_mb": 20 } } }

Or exclude_paths when a specific directory legitimately contains what the gate hunts for. See When a gate is wrong.

3. Ignoring the gate entirely, in .l0git.json:

{ "ignore": ["changelog_present"] }

Correct when the gate does not apply to this project at all. A repository that genuinely has no changelog because it is not released is not improved by a permanent finding.

There is also a middle setting worth knowing: downgrade the severity rather than ignoring:

{ "severity": { "dead_placeholders": "info" } }

That keeps the finding in the audit layer without it competing for attention with real errors.

What to do in the first hour

1. Fix every error
2. Read the warnings and fix the cheap ones, which on most repositories is the presence gates: LICENSE, CONTRIBUTING, SECURITY, a PR template
3. For each remaining warning, decide once: inline directive, gate option, severity downgrade, or ignore. Write the reason
4. Commit .l0git.json
5. Run it in CI

The goal of the first hour is a clean run, so that the next finding means something. A tool that always reports 40 findings is one nobody reads.

In CI

Everything except lgit fix prints JSON on stdout, so it pipes into jq and into a workflow directly. Gate on errors first, and add warnings once the repository is clean, which is the same ratcheting argument any linter needs and here is easy because the store is shared: what you resolved locally stays resolved.

The opt-in gates

History scanning is off by default:

{ "gate_options": { "secrets_scan_history": { "enabled": true } } }

Turn it on deliberately, once, and be ready for what it finds. A secret still in .git is a real finding with a real remediation cost, and it is not the thing to discover on the morning you are trying to ship.