The single git tool — a thin, honest proxy to the host git binary.
ONE built-in Python function, git, runs a SERIAL batch of git <args…> commands
in the active workspace root and returns a TOTAL, string-keyed result the model reads
directly: {"commands" [{"command", "args", "stdout", "stderr", "exit", "duration_ms", "timed_out"} …]}. Every key is present for every command
(stderr "" when empty, exit None only when that command timed out), so no
field ever KeyErrors. A non-zero exit is DATA, not a tool failure; later commands
still run, so a batch reports partial outcomes exactly like a terminal script.
This REPLACES the old JGit-backed git_* surface (foundation-git): no
embedded git implementation, no SSH/BouncyCastle stack — the only git is
the one already on the user's PATH, so behaviour matches their shell
exactly. Nor is there a second process runner: every command goes through
foundation.shell's run-argv, so git inherits the shell tool's working
directory resolution, process jail, capped capture and timeout. Read-only
workspace facts (branch/dirty/ahead-behind for the footer, env block, file
picker) still flow through com.blockether.vis.internal.git; this namespace
is purely the model-facing command tool.
Built-in (bare git in the sandbox, next to cat/rg), active when
the workspace sits inside or contains a repository.
The single `git` tool — a thin, honest proxy to the host `git` binary.
ONE built-in Python function, `git`, runs a SERIAL batch of `git <args…>` commands
in the active workspace root and returns a TOTAL, string-keyed result the model reads
directly: `{"commands" [{"command", "args", "stdout", "stderr", "exit",
"duration_ms", "timed_out"} …]}`. Every key is present for every command
(`stderr` "" when empty, `exit` None only when that command timed out), so no
field ever KeyErrors. A non-zero exit is DATA, not a tool failure; later commands
still run, so a batch reports partial outcomes exactly like a terminal script.
This REPLACES the old JGit-backed `git_*` surface (foundation-git): no
embedded git implementation, no SSH/BouncyCastle stack — the only git is
the one already on the user's PATH, so behaviour matches their shell
exactly. Nor is there a second process runner: every command goes through
`foundation.shell`'s `run-argv`, so git inherits the shell tool's working
directory resolution, process jail, capped capture and timeout. Read-only
workspace facts (branch/dirty/ahead-behind for the footer, env block, file
picker) still flow through `com.blockether.vis.internal.git`; this namespace
is purely the model-facing command tool.
Built-in (bare `git` in the sandbox, next to `cat`/`rg`), active when
the workspace sits inside or contains a repository.(git opts)await git({"commands": [["status", "--short"], ["diff", "--stat"]]}) await git({"commands": [["add", "-A"], ["commit", "-m", "message with spaces"]]})
Run host Git serially from the workspace root. Pass ONE map whose non-empty commands is a list of non-empty argv lists, with git omitted; each token is one literal argument, so paths and messages with spaces are safe. Never pass a positional array. Later commands see earlier mutations. Result: {"commands": [{"command", "args", "stdout", "stderr", "exit", "duration_ms", "timed_out"}, ...]}; output stays with its command. Non-zero exit is data, and later commands still run.
await git({"commands": [["status", "--short"], ["diff", "--stat"]]})
await git({"commands": [["add", "-A"], ["commit", "-m", "message with spaces"]]})
Run host Git serially from the workspace root. Pass ONE map whose non-empty `commands` is a list of non-empty argv lists, with `git` omitted; each token is one literal argument, so paths and messages with spaces are safe. Never pass a positional array. Later commands see earlier mutations. Result: `{"commands": [{"command", "args", "stdout", "stderr", "exit", "duration_ms", "timed_out"}, ...]}`; output stays with its command. Non-zero `exit` is data, and later commands still run.cljdoc builds & hosts documentation for Clojure/Script libraries
| Ctrl+k | Jump to recent docs |
| ← | Move to previous article |
| → | Move to next article |
| Ctrl+/ | Jump to the search field |