Source preview guide · 0.1.0

Protect the history you are about to push

Approve and apply protection to one clone, inspect its outgoing committed history, and understand the exact reason for a block.

Apply protection to the intended clone

Push protection uses an explicitly installed local Git hook. A failing scan or configured project gate does not install that hook. Begin with a connected editor profile, the exact authorized source repository and prepared scanners.

1. Run CodeSecurity: Protect Pushes… in VS Code. The Command Palette asks you to choose a repository; a Source Control repository menu uses its selected clone.
2. Check the repository identity. A stale or ambiguous selection must be resolved before proceeding.
3. Request repository access, then approve that exact editor generation in the paired owner’s browser. Ordinary IDE membership does not grant this permission.
4. Choose the requested On setting and explicitly Apply it in VS Code.
5. Read the reported host state and resolve any hook conflict before relying on protection.

The Web setting records requested state. Change pending · Apply in VS Code means the host has not applied it. This also applies to a request to turn protection Off: an already applied On hook may still block until that change is applied. On · last verified and Off · last applied describe the last observation.

The local hook invokes a separately bundled helper, so it can operate while the editor is closed when its required backend is available. Installation preserves unrelated hooks and local hook-path configuration; a conflict that cannot be safely composed is refused. It does not change global Git settings or remotes.

Review outgoing commits before pushing

Run CodeSecurity: Check Outgoing Commits… from the Command Palette or the intended repository’s Source Control menu. Select the configured destination, local branch or tag, and explicit remote reference. Review that scope before its snapshots and scans are submitted. This command performs a check, not a push.

The check binds the canonical repository, outgoing ref and object pairs, immutable source trees, authorized coverage, current policy and scanner evidence. A workspace scan, file scan, folder scan or the workbench’s last selected scan cannot substitute for that committed history.

For example, a secret introduced in one outgoing commit and removed by the next still travels in the earlier commit. A clean tip does not erase it. Review the failing historical tree rather than scanning only the latest working files again.

Each repository has an independent outcome. Unchanged immutable content can reuse applicable evidence, but changed refs, policy, finding dispositions or scanner/data identity can invalidate an approval. Checking the curated catalog alone does not install new scanner data. Current readiness still controls whether evidence is usable.

Read the outcome for the exact plan

A source-bearing push requires completed, applicable passing evidence. Missing, failed, stale, partial, cancelled or unavailable verification blocks it. Disabling the gate does not produce a pass, and changing dispositions cannot fill gaps in coverage.

A deletion-only or no-op plan has no outgoing source tree to scan. Such a plan can complete without scanner execution, while repository approval and current policy still apply. Read the actual plan rather than inferring that an empty finding list makes it tree-free.

Cancelling a check stops its current cancellable job and retains earlier results. A retained cancelled check can offer Start new check, showing its scope and previous job and scan identities. Accepting that action rechecks current state and can reuse applicable completed evidence. It does not relabel the cancelled check as passing.

Diagnose a blocked push

Normal Git or GitLens notifications may offer generic advice to pull. Open Show Command Output in VS Code or Open Output Channel in GitLens and inspect the actual result. When it says Lomo blocked this push, return to protection and the outgoing check for that clone.

Use Review blocking findings after a completed failed outgoing scan. It opens the exact committed-tree scan; choose the intended scan if several trees failed. Historical evidence cannot open your current workspace file as though that file were the checked tree. Open protection settings opens the repository’s record without changing a gate or permission.

An unpublished branch, missing remote setup or Nothing to push can stop a client before the hook runs. These messages do not establish a CodeSecurity allow decision. Confirm the normal Git branch and destination as well as the security outcome.

Recognize coverage limits

Coverage concerns regular-file content in newly outgoing commit trees. Commit messages, tag messages and other non-file metadata are not scanner file inputs. Unsupported symlinks, submodules, shallow repositories, alternate object stores or unverifiable coverage are refused.

An existing remote ref needs its old commit available locally. A new branch has no old base, so all history reachable from its tip counts toward the commit limit even if another remote branch contains some of it. The check does not silently fetch missing objects or truncate history.

A limit refusal approves no push. Reduce the ref selection where that resolves a ref-count limit, or arrange a separately approved review and enforcement path for unsupported history or trees. A smaller workspace scan cannot supply the missing evidence.

Turn protection off or remove it

Turning Off requires its warning and explicit host application. Cancelling leaves the setting unchanged. Once Off is applied, the helper does not read source, require an online API or impose On-only source and ref limits. The registration and hook configuration remain available for explicit re-enabling.

Removal is a separate action. In the exact owning profile, choose Protect Pushes… > Remove push protection from this clone… and confirm the repository. Removal targets only the unchanged Lomo-owned hook, protection registration and repository-specific grants and bindings. Projects, scans, findings, retained snapshots, general pairing, remotes and other tools’ hooks remain.

A project still used by protection or its Git snapshot source cannot be deleted, even with protection Off. Remove the registration first if you intend a separate project deletion.

If local removal succeeds while server cleanup is unavailable, retry removal from the same profile when the service returns. Changed or unknown hook files are preserved. After revoking and re-enrolling an editor, request approval for its new generation and explicitly Apply again; it does not inherit the old repository grant.

Test without publishing source

For a deliberate manual check, use a disposable repository and an exact local bare remote. Use synthetic findings and verify the remote refs before and after ordinary Git pushes. A block should leave them unchanged; an allowed push should change only the intended refs. Include problematic earlier history followed by a clean tip so that a tip-only check cannot appear sufficient.

A local hook can be bypassed by its owner or avoided through another clone. Keep appropriate remote controls where enforcement must be unavoidable. A successful manual check covers the cases you exercised, not every platform, ref type or recovery path.

Read gate decisions, finding review and the Git protection API for the related controls.