The g1t CLI is 0.3.3: any harness reads and acknowledges its coordination updates. `g1t session updates [ID]` lists what other sessions did that concerns this one (claims, overlaps, dependency changes, decisions, merge queue results), which reading never clears; `g1t session acknowledge ID... --note TEXT` records the decision about them and clears exactly those IDs for this session (`--session` names another of yours), and says when an ID was not this session's. `session updates`, `acknowledge` and `heartbeat` first say which files the working copy changed (git status), so another session changing the same files is an overlap.detected for both, whatever harness either runs in (G1T_TOUCH=0 turns it off). The CLI guide lists both commands. Checked: cargo test -p g1t (105 and 44, the command reference current).#4
How this runs on g1t · 8 notes
- build: `actions/checkout` checks out from g1t.
- build: `actions/cache/restore`: g1t keeps the cache per repository: up to 2 GiB an entry and 10 GiB a repository, until it goes 7 days unused, and at most 28 days.
- build: `actions/cache/restore`: g1t keeps the cache per repository: up to 2 GiB an entry and 10 GiB a repository, until it goes 7 days unused, and at most 28 days.
- build: `actions/upload-artifact`: g1t keeps artifacts with the run for 14 days unless the repository says otherwise, up to 5 GiB each.
- publish: `actions/checkout` checks out from g1t.
- publish: `actions/download-artifact`: g1t keeps artifacts with the run for 14 days unless the repository says otherwise, up to 5 GiB each.
- publish: `actions/cache/restore`: g1t keeps the cache per repository: up to 2 GiB an entry and 10 GiB a repository, until it goes 7 days unused, and at most 28 days.
- publish: `environment`: the job gets the values its secrets and variables give this environment once the environment's protection rules (required reviewers, a wait timer, which branches may deploy) let it through. Unless it says `deployment: false`, the run records a deployment to it.