Development

Development

Building and testing

cargo build                       # build both binaries (git-task, gtask)
cargo build --tests               # compile tests without running (fast error check)
cargo test                        # unit tests + integration tests
cargo test --lib                  # unit tests only (fast, no subprocess/git overhead)
cargo test --test sync            # one integration test file: basic | cross_repo | sync
cargo test diverged_edits_merge   # a single test by substring match, across any file
cargo install --locked --path .   # install git-task + gtask to ~/.cargo/bin
git task completions bash > ...   # also: zsh, fish, powershell, elvish

No lint/format step is currently wired into the repo (no clippy/rustfmt config checked in).

A known rustc/dependency gotcha

If cargo build fails immediately after a dependency version bump with an "is not supported by rustc" error, it's very likely a toolchain-lag issue rather than broken code: a couple of dependencies (time, comfy-table) have needed a cargo update -p <crate> --precise <version> downgrade in the past when the local rustc sat one minor version behind current stable. Pin the dependency back and confirm before assuming the code itself regressed.

Version bump on every PR

CI on pull requests rejects a PR whose Cargo.toml version isn't strictly above the latest release tag. Bump it, and rebuild once so Cargo.lock picks up the change, as part of any PR, even a small one.

Architecture, in brief

See Core Concepts for the event-sourcing model itself. The codebase layers roughly bottom-up:

• domain/: pure data and logic, no I/O. Operation is the closed vocabulary of every mutation that can happen to a task; fold replays an ordered operation list into a Task.
• store/: the only code that touches the git object database for task data. Handles create/append/load/resolve, and the merge reconciliation pull uses when a task has diverged.
• config/: per-repo config is event-sourced under the reserved refs/tasks/config ref, exactly like a task (see Configuration); user-level config stays plain TOML.
• automation/: the rules engine, matching conditions and executing actions as a new, attributed operation package.
• sync/: the machinery behind the auto-sync built-in, a detached background push+pull triggered after a mutating command's rule cascade settles.
• cli/: one file per subcommand, each a thin argument struct plus a run() that wires the layers above together and prints, in text or JSON.
• web/: the process manager behind git task web (install/spawn/stop/status of the companion git-task-web server). See Web Server Integration.

Test structure

Integration tests (tests/basic.rs, tests/cross_repo.rs, tests/sync.rs, tests/automation.rs, and others) drive the real, compiled git-task binary as a subprocess against real temporary git repositories, not mocks. Each test gets its own GIT_TASK_CONFIG_DIR, so the default parallel test execution is safe: no shared global state between tests. Auto-sync is disabled by default in the test harness (GIT_TASK_DISABLE_AUTO_SYNC=1) so no test accidentally spawns a real background sync worker; a handful of tests in automation.rs opt back in specifically to exercise it.