I keep fourteen Git repositories in one folder.
A few services, shared packages, plugins. Most of my work at Blend-ed touches more than one of them, so a normal question like “did I push that fix?” turns into a small tour of my filesystem.
Open a repo. Check the branch. Run git status. Move to the next one. Forget what the first one said.
I wrote about that problem in my first manygit post. The tool started as a way to put every repo’s state on one screen. Since then, I’ve added a way to ask for Git operations in plain English, across that same tree of repositories.
That’s the AI part of manygit. You describe the work, read the commands it proposes, and decide whether to run them.
First, I needed to see what was going on
Before any AI request makes sense, I need to know what I’m asking it to change.
manygit walks the folder you point it at and discovers the repositories underneath. There’s no list of repos to maintain in a config file. It groups them by parent directory and shows the current branch, changed files, and ahead/behind counts.
Press F and the clean, synced repos disappear. Now the list is just the ones that need attention. Press / and filter by repo name or current branch.
This was the original relief for me: I could stop remembering the state of fourteen directories. The screen held it.
The usual operations are still one key away. s fetches and does a fast-forward-only pull on the highlighted repo. p pushes it. f fetches one; r refetches the tree.
Then there are the requests that take a little more explaining.
“Sync everything in this folder”
Press : and manygit opens a prompt for your configured AI CLI. You can type something like:
sync everything in other/
Or, for the repo under the cursor:
rebase current onto master
Those are requests, not fixed shortcuts. The proposed commands depend on the repositories and their state, so you still need to read the result.
The useful detail is the context manygit already has. It sends a snapshot of the repo tree: names, parent groups, current branches, each repo’s main reference, ahead/behind counts, and dirty-file counts. It also includes the selected repo and its known branches.
That matters when one project uses main and another uses master. Or when “everything in other/” means a particular group of repositories. I don’t have to paste a collection of git status outputs into a separate chat just to explain the workspace.
Tab completes repo, folder and branch names while you type. The up and down arrows recall earlier requests from the session.
The pause before anything runs
This is the bit I care about most.
The AI returns a structured plan: a repository name and Git arguments for each step. manygit checks the plan, then shows the proposed commands in the Output pane with a [y/N] confirmation.
I can read which repository each command applies to before pressing y. If the interpretation is wrong, I cancel and ask again.
There are also checks in the code, beyond the instructions sent to the model. Force pushes and remote-ref deletions are refused. So are several Git options that can execute shell commands or redirect an operation into a different repository. The planned Git commands run as argument lists rather than a shell string.
These checks don’t make every proposed operation harmless. A rebase changes history. A hard reset can lose local work. The confirmation is there because the command still needs judgment.
Once confirmed, the steps run in order. If one fails, the rest are skipped. A conflict in the first repo shouldn’t leave three more repos halfway through their own operations.
The repo list updates as changes are detected, and manygit refreshes the state again when the run finishes. I stay in the same interface to see what happened.
It uses the AI CLI you already have
manygit supports Claude Code and Codex. It looks for the installed CLI and uses that tool’s existing authentication and default model settings. There’s no separate API key to configure inside manygit.
You can choose the installed AI CLI from the settings in ?.
The AI features make calls through that CLI, so its account, usage limits and data handling still apply. The request includes repository metadata; if you reference a file with @path, its contents go into the prompt too.
For example, if you have a script describing a wider update process, you can ask:
@scripts/update-all.sh only the frontend apps from this
manygit reads the file as context for the request. This mode proposes Git steps; it doesn’t blindly execute the whole script. File references are restricted to paths inside the scanned tree.
Without either AI CLI installed, the repo list, branches, graph, scripts and normal Git actions still work.
A small news feed for the workspace
The other AI feature is quieter.
manygit gathers recent commits from the repositories’ main branches and asks the configured CLI to turn them into short headlines. They appear in the top bar; n opens the full feed.
It’s a quick way to get some context across the workspace before opening individual commit histories. The summary is cached for about four hours, so restarting the tool doesn’t make a fresh AI call every time.
For the actual history, there’s a commit graph. If gh is installed and signed in, there’s also a pull-request pane for your open PRs and review requests. You can check out a PR’s branch in its matching local clone without hunting for the folder first.
Try the interface first
I built a browser demo so you can try the layout and keybindings before installing anything. The repositories there are simulated. It’s a preview of the interface, not a connection to your real Git repos or AI account.
manygit is written in Go, open source under the MIT license, and available for Linux, macOS and Windows.
With Go 1.24 or later:
go install github.com/rabeeh-ta/manygit@latest
Then point it at your workspace:
manygit --root ~/work
The README has the binary installers and Homebrew instructions too.
I built the first version because I was tired of walking through fourteen repos to answer one question. The AI command mode grows out of the same problem: once I can see the workspace, I want to act on it without reconstructing that context somewhere else.
If you work across several repos, I’d like to hear which Git task you keep repeating between them.
Top comments (0)