.profile/public/content/projects/git-fleet.md

title, slug, summary, label, date, status, featured, order, github, tags

title	slug	summary	label	date	status	featured	order	github	tags
git-fleet	git-fleet	A Git extension written in OCaml for managing repositories across multiple Git hosts, keeping a single remote mirrored to several push destinations.	Project	2026-10-17	Active	true	1	https://git.sowinski.dev/SowinskiBraeden/git-fleet	OCaml, CLI, Git, Dune, Developer Tools

Overview

git-fleet is a native CLI that simplifies the Git workflows I use across self-hosted Git services and public hosts. I run my own Gitea instance but still mirror most repositories to GitHub, and keeping both in sync meant hand-editing remote configuration in every new project.

The project started as a handful of personal shell scripts for configuring dual-push repositories, and is being rebuilt in OCaml as a single, reusable command. Because Git exposes any git-* executable on PATH as a subcommand, the tool installs as git fleet.

How It Works

Rather than inventing its own state, git-fleet configures ordinary Git remotes. A remote fetches from one URL and may push to several, which is how one repository stays mirrored across more than one host.

The subtlety is that a remote with no pushurl pushes to the URL it fetches from, but as soon as it has one pushurl, Git pushes only to the URLs listed there. So git fleet add writes out the existing destination before adding a new one, and git fleet remove collapses the configuration back to plain Git behaviour once the only destination left is the fetch URL.

git fleet status
git fleet add git@github.com:user/project.git
git fleet remove git@github.com:user/project.git --dry-run

Focus Areas

• Modelling remote configuration as a plan that can be previewed before it is applied, so --dry-run works on every command that changes something
• Invoking Git directly as a subprocess rather than through a shell, avoiding quoting and injection problems entirely
• Keeping the resulting configuration indistinguishable from what someone would write by hand
• Testing against temporary repositories so the test suite never touches the configuration of the repository it runs in

Notes

This is my first real project in OCaml, and the language has been a good fit for it. The remote state is a small, closed set of shapes, and the type system makes it awkward to forget a case — which matters when the tool's whole job is rewriting configuration that people's pushes depend on.

Version 0.2.0 covers remote management: status, add, and remove. The longer-term goal is to cover the rest of the multi-host workflow, starting with creating a repository on several hosts at once.