Every tool that shells out to Git is making a bet about which Git it's actually talking to. Most tools make that bet easy on themselves: bundle a pinned binary and control the variable, or assume everyone is running something reasonably recent and let the stragglers file bug reports. Influxx doesn't get to take either shortcut. In a single session, one agent might be working against a repository on your local machine, a second inside a WSL distro, and a third over SSH on a server you don't control — three Git binaries, three possible versions, one orchestration layer that has to behave the same way regardless of which one is actually running the command.
The Shortcut We Didn't Get to Take
Most developer tools solve the "which version of my dependency am I actually running against" problem by refusing to ask it. Bundle your own pinned copy of a dependency inside the application, and the compatibility question disappears — you shipped the binary, you know exactly what it supports, and every user gets the identical behavior you tested against. The softer, more common version of the same shortcut is to assume most users are on something reasonably modern, build against that assumption, and treat anyone on an older install as an edge case to handle if and when they complain.
Influxx can't take either path, and the reason is architectural rather than ideological. Influxx runs the user's actual installed Git binary directly — never a bundled copy of our own — because the entire point of the product is orchestrating coding agents across native machines, WSL distros, and SSH-connected remote hosts, each with its own Git install that we don't own and can't pin. Bundling a version doesn't help when the actual work is happening on a machine several network hops away. And "assume recent" fails the moment a real engineering organization has some slice of its fleet — build servers, hardened staging boxes, whatever — sitting on an older Git release for reasons that have nothing to do with us. When the core mechanic of the product is giving every agent its own isolated git worktree, we don't get to be casual about whether Git itself behaves the way we expect it to.
Why "git --version" Isn't the Final Authority
The obvious next move looks simple: parse the output of "git --version", compare it against a table of when each feature shipped upstream, and gate behavior on that comparison. We looked at this approach closely enough to see why it doesn't hold up, and rejected it deliberately rather than discovering the problem in production.
The issue is that a version string tells you what a Git build claims to be, not what it actually supports. Linux distributions and other vendors patch and backport individual features into their packaged Git builds on their own schedules, independent of the upstream release cycle. Two machines can report the exact same version string and still disagree about whether a particular flag or output format works, because one of them shipped with a backport the other never got. A string comparison has no way to see that difference — it's comparing a label, not the thing the label is supposed to describe.
"A version string tells you what a binary claims to be, not what it does. We've seen two machines report the identical Git version and disagree on whether a flag actually works, because someone's distro backported it and someone else's didn't. Once you've seen that once, you stop trusting the string and start testing the behavior directly."
— Tobias Lindqvist, Staff Engineer, Platform at ETAPX
A Floor, Not a Ceiling: Git 2.25 and Progressive Enhancement
Rather than gate features on a version number we don't trust, we drew a line and built two tiers around it. Git 2.25 is the enforced floor for every core workflow in Influxx — the minimum every installation is assumed to support, regardless of which host is running it. At that floor, we can rely on:
- Modern porcelain-style output: stable, script-friendly command output we can parse without guessing at formatting quirks from much older Git releases.
- Basic branch introspection: listing, inspecting, and comparing branches reliably enough to drive worktree creation and agent assignment.
- File restoration commands: resetting working-tree or index state predictably, which matters whenever an agent's changes need to be reconciled or rolled back.
- Sparse checkout: letting an agent operate against a narrower slice of a large repository instead of always materializing the entire tree.
Anything that shipped in Git after that floor is treated as an upgrade, not a requirement. Machine-parseable, NUL-delimited output from a worktree listing, for instance, or the newer merge-base and merge-tree computation commands that can resolve a merge without touching the working tree — we use these opportunistically when they're available, because they're genuinely better than the alternative. But the core workflow has to work without them. When a host can't do the newer thing, Influxx falls back to a baseline-compatible path instead of failing outright or, worse, silently producing the wrong result.
The Capability Cache: Probe Once, Trust Briefly, Re-Check Automatically
Once we stopped trusting version strings, we needed something to trust instead. What we built is a capability cache that behavior-probes each Git command or flag the first time it's needed — actually running it and checking whether it works, rather than inferring the answer from a version number. A few properties make it usable in practice rather than merely correct in theory:
- Cache the result, not just the check: once a capability is confirmed, later operations skip the probe entirely.
- Bound the pessimism: a negative result is remembered for roughly thirty minutes before Influxx is willing to test again, so one failure doesn't get re-litigated on every subsequent operation.
- Coalesce concurrent checks: if several operations ask about the same capability at once, they share a single in-flight probe instead of each firing off a redundant copy of the same test.
- Re-detect without a restart: if the underlying Git binary gets upgraded in place — a package manager update, a refreshed WSL image, whatever — Influxx notices and re-probes automatically, with no need to relaunch the app.
None of this is exotic. It's the same discipline that makes any capability-detection system trustworthy: verify the actual behavior, cache it responsibly, and don't let a stale answer outlive its usefulness.
"Nobody opens Influxx because they're excited about Git version compatibility. They open it because they want several agents running in parallel without their environment quietly falling over underneath them. Getting there means treating something as unglamorous as Git capability detection with the same rigor as the orchestration logic everyone actually notices."
— Priya Anand, VP of Engineering at ETAPX
One Repository, Three Git Binaries
The capability cache would be pointless if it only had one answer to remember. The same repository in Influxx can be opened three different ways — locally, inside a specific WSL distro, or over an SSH connection to a machine somewhere else entirely — and each of those is a genuinely distinct Git binary. They can be different versions. They can carry different backported capabilities even at the identical reported version. Asking "does Git support this" as a single global question doesn't have an honest answer, because the honest answer depends entirely on which host is actually going to execute the command.
So capability state in Influxx is scoped per execution context: the local machine keeps its own record, each WSL distro keeps its own, each SSH connection keeps its own. A capability confirmed on your laptop tells us nothing about the staging server you just opened a worktree against over SSH, and the cache doesn't pretend otherwise.
"Our staging hosts are locked to an older Git image for compliance reasons nobody on my team is allowed to touch. I half expected Influxx to choke the moment I opened a worktree over SSH into one of those boxes. It didn't — it just quietly used an older code path for that connection and kept going. I only found out there was a fallback happening at all because I went looking for it."
— Marisol Tan, Staff Backend Engineer, Influxx user
The Wrapper Library We Said No To
There's a tempting middle path we also considered and set aside: lean on one of the general-purpose Git wrapper libraries that exist to make shelling out to Git less painful from application code. They're genuinely useful for what they do — cleaner call syntax, more consistent error handling, less boilerplate around spawning a process. What they don't do, and structurally can't do, is solve version compatibility.
A wrapper library is a process-execution convenience layer. It can make calling a Git command more pleasant to write. It cannot make an older Git binary support a feature that binary doesn't have, and it has no way to automatically choose the correct semantic fallback when a newer command isn't available on a given host. Adopting one wouldn't have solved our actual problem — it would have moved the unsolved problem to a more comfortable-looking place in the codebase. We'd still have needed the capability cache, the per-host scoping, and the fallback logic; we'd just have had a nicer function signature wrapped around the same unresolved question.
Proving It: CI Against Real Git Binaries, Not Mocks
The last piece is verification. It isn't enough to believe a fallback path is correct — mocked Git behavior in a unit test will happily agree with whatever assumption got written into the mock. So the compatibility contract runs in continuous integration against multiple real, actual Git binary versions, spanning from the 2.25 baseline up through releases well newer than that.
That matters because the failure mode we're guarding against is specific: a fallback that looks correct against a test double but doesn't match how an old Git binary actually behaves under a real invocation. Running the same contract against real binaries at both ends of the supported range, and at points in between, is the only way to know a baseline-compatible path was proven against real Git behavior instead of against our own assumptions about it.
Frequently Asked Questions
What's the actual minimum Git version Influxx requires?
Git 2.25 is the enforced floor for every core workflow — worktree creation, branch introspection, file restoration, sparse checkout, and everything agent orchestration depends on day to day. If your installed Git is at or above that floor, core functionality works. Anything from a newer release is used when it's available and skipped safely when it isn't.
Does Influxx bundle or install its own copy of Git?
No. Influxx always runs the Git binary you already have installed, whether that's on your local machine, inside your WSL distro, or on whatever host you've connected to over SSH. It never ships or invokes a separate, pinned Git of its own.
My local machine and the SSH host I'm working on have different Git versions. Does that break anything?
It shouldn't. Influxx tracks capability state separately for each execution context — your local machine, each WSL distro, each SSH connection — rather than assuming one global answer applies everywhere. A worktree opened against an older remote host simply uses the baseline-compatible code paths for that connection, while your local machine can still use newer ones for its own work.
Why doesn't Influxx just check the output of "git --version" to know what's supported?
Because two installs can report the identical version string and still support different things. Distributions and vendors backport individual features into their packaged Git builds on their own schedules, independent of the upstream release cycle, so a version number alone can't tell you what a given binary actually does. Influxx behavior-probes commands and flags directly instead of trusting the string.
If I upgrade Git while Influxx is open, do I need to restart the app?
No. The capability cache re-detects automatically when it notices the underlying Git binary has changed, so an in-place upgrade gets picked up without relaunching Influxx.
How do you know the older fallback code paths actually work, rather than just looking correct on paper?
We run the compatibility contract in continuous integration against multiple real Git binary versions, from the 2.25 baseline up through much newer releases, rather than against mocked Git behavior. A fallback only counts as proven once it's been exercised against an actual old Git binary doing what old Git binaries really do.
None of this is the part of Influxx anyone screenshots. It's the part that has to be right before the rest of the product — agents running side by side, each in its own worktree, notes and CLIs in one cockpit — can be trusted at all. Git version compatibility only looks like a solved problem until you run it across a native machine, a WSL distro, and someone else's SSH host in the same afternoon.
