Version control
Settings → Version Control does exactly one thing: tell Croli which git to use.
Opening the page does two things at once — probe the system for Git, and read the saved custom path. If that read fails, a "Failed to load settings" message appears.
Git configuration
A status box showing the probe result:
- Git detected (green check) plus the version number, with Path on the line below — the executable that will actually be invoked.
- Git not found on this system (red cross). Everything that depends on Git — repository status, branches, diffs, remote operations — is unavailable.
On the right is a Custom Git Path button; the input only appears once you click it.
Custom Git Path
Fill in an absolute path (the placeholder shows /usr/bin/git); leave it empty to go back to automatic detection.
Saving tests first: Croli runs a probe with that path, and if it isn't a valid git executable the save is refused with "Git test failed" — a wrong path never gets written into the configuration. Only after the check passes is it written, and the status box above is re-probed immediately to refresh it.
Cancel, next to it, discards the edit and resets the input to the saved value.
Worth knowing
- These settings live in the backend, and every client of the same Croli backend shares one copy.
- Credentials for remote operations are not configured on this screen: Croli calls the
giton your machine, so whatever thatgitaccepts — agit credentialhelper, an SSH key, a token in your shell environment — Croli accepts too. - Can the custom path point at something that exists on another machine but not this one? No — the check before saving runs on the machine the backend is on, and if the probe fails it is refused. This differs from the Shell path under General, which only warns instead of refusing.
- Git commands the agents run themselves don't necessarily go through this setting: CLIs that bring their own shell (Codex, Claude Code and so on) call
gitinside their own process, using the one they resolved themselves.