Automatic batching

Run cor work and leave it running. It watches your project and schedules a sync after one second without a relevant save. Another save resets the quiet period, including another save of the same file.

There is also a five-second maximum batching delay from the first change. Continuous editing therefore triggers regular attempts. Hashing, transfer, file changes during capture, and offline retries can add time after that delay.

cor work --debounce-ms 1000 --max-batch-ms 5000

The maximum must be positive and at least the quiet period. A one-shot cor sync exchanges immediately, so stop the worker first if you need an explicit exchange.

Ignored-file activity does not create or postpone a batch. Remote notifications and periodic scans respect a local batch’s deadline, preserving the whole-package rule. With no local batch, incoming changes are handled immediately.

Use your existing .gitignore

Corotation reads root and nested .gitignore files even if the project is not a Git repository. Patterns are scoped to their containing directory. Anchored paths, directory rules, and negation work as expected.

dist/
coverage/
*.tmp
.env
.env.*
!.env.example

The global Git ignore file in your home directory and .git/info/exclude are not used. The project’s shared files define the rules.

Git metadata, node_modules, Corotation’s internal and temporary paths, and conflicts.laplace.json are always excluded. Negations cannot re-include these paths.

Override a rule for Corotation

A root .laplaceignore uses Gitignore-style syntax and takes priority over .gitignore. For example, include a model that Git excludes while omitting local renders:

!assets/hero.glb
renders/

An excluded parent directory must be re-included before its children. If assets/ is excluded, use:

!assets/
assets/*
!assets/hero.glb

Only the root .laplaceignore is interpreted. Nested .gitignore files are supported. Ignore files themselves are synchronized unless excluded, and changes to them trigger a full rescan.

Ignoring and re-including existing files

Ignoring a previously synchronized file does not delete it from current. New incoming versions for that path are deferred locally; the local edit base does not advance.

When you re-include the path, an unchanged local file catches up to current. If you changed it locally while it was ignored and current also changed, the entire outgoing package is rejected rather than silently replacing the newer remote work. Deferred deletions are handled too.

What is tracked?

Item Behavior
Regular files Content and executable bit are synchronized.
Empty directories Not tracked.
Symlinks and special files Unsupported; exclude them explicitly.
Non-UTF-8 names Unsupported; exclude them or rename them.
Ownership, timestamps, ACLs Not synchronized as metadata.
Case-only renames and Unicode aliases Not supported across differing filesystem conventions.

Efficient reconciliation

The worker deduplicates dirty paths and keeps one long poll outstanding instead of restarting it on every save. Metadata scans reconcile missed notifications every 30 seconds; full rehashing runs every 600 seconds. Watcher overflow schedules a verification pass.

cor work --reconcile-seconds 30 --verify-seconds 600

Large-file changes still require reading the file to discover chunk boundaries. Only missing chunks are transferred, but compressed assets that are re-encoded may have few chunks in common with the old version.