Introducing open-git · open-git Blog

What this is

I am building open-git.com as an alternative to mainstream code hosting. You may be thinking: "Huh, doesn't that already exist?" It does. One more can't hurt, right? Everyone does it a little differently, and I want to as well.

The pitch on the home page is simple: a code host, in the open. Push over HTTPS, open pull requests, browse public repositories. I am not trying to clone every feature on day one. There is a lot I would love to add - and I will, over time - but the core loop (host code, collaborate, ship) is what I am focused on first.

You can sign up at https://open-git.com/sign-up - email, password, then a username. That username becomes your namespace. Repositories live at :namespace/:repo, and you create them from the app before you push.

You can make repos public or private. Public repos are browsable without signing in; private ones need auth for git and the web UI. You can also create organizations if you want a shared namespace separate from your personal account - useful when a project outgrows a single username.

Push a repository

Git traffic goes through git.open-git.com, not the main web app. I use a dedicated git-gateway for that. It was an early decision to keep the Next.js app separate from whatever handles git over HTTP. The gateway talks back to the web app for permissions (who can push, who can read). I suspect that split will go away eventually; for now it stays, and it works.

Typical flow: create an empty repo in the UI, add the remote, push your first branch.

git remote add origin https://git.open-git.com/you/my-app.git
git push -u origin main

For local dev:

git remote add origin http://localhost:4321/you/my-app.git
git push -u origin main

For private repos, push auth is HTTP Basic: username is your open-git username, password is a git token from /settings/developer. Generate a token there, treat it like a password, and revoke it if something leaks.

Open a pull request

You can open a pull request on a repo much like you would on GitHub - pick source and target branches, add a title and description, and go. You can open PRs within the same repo or from a fork when you need a separate copy to work from.

Once the PR exists, the page is split into three tabs: Conversation (comments and timeline), Commits, and Files changed. Campfire is not part of that flow; it is its own tab on the repository, only when you enable it. I wanted review to stay focused on the diff and the thread, not mixed with chat.

Review and merge

I use Pierre for diffs and file trees across the app. Taking inspiration from their Diffshub work, I try to stay close to that experience - side-by-side or unified views, file tree navigation, that kind of thing. So far it works well on real PRs, but it has not been fully stress-tested at scale.

Review comments support the usual markdown. If you leave a fenced suggestion block, it can render as a small inline diff preview so reviewers can see what "apply this change" would look like. Behind the scenes the app also runs mergeability checks and queues diff jobs when a PR is opened or updated.

Merges are fast-forward when the target branch allows it - no merge commits by default. If the source branch has not absorbed the target tip, merge is blocked until you rebase or otherwise catch up. Three-way merge is on the wish list; not there yet.

Campfire

Campfire is early. Think Discord, but scoped to a repository when you turn it on in Settings → General. It shows up as its own Campfire tab next to Code, Issues, and Pull requests - not inside a PR.

Messages go over WebSocket through campfire.open-git.com (with a short-lived token from the web app). There are channels, quote-replies, and the basics of realtime chat. It will evolve a lot - more features, better polish. The UI is fairly rudimentary today. Expect bugs and a long list of improvements ahead: permissions, identity, notifications, moderation, and more.

CI

CI is implemented end-to-end: workflow files under .opengit/workflows/, runners, status on PRs, the works. But until ops are more solid, production only runs CI for repos on an allowlist. Right now that is basically madison/open-git - I run CI on every PR there and do not merge until it passes. That keeps the main project honest while I tighten isolation and runner security.

Workflows are YAML in the repo, GitHub Actions–ish in shape. Triggers like push and pull_request are supported; the open-git repo's own CI installs deps and runs pnpm test. Enabling CI site-wide is mostly a security and ops call at this point; flip the allowlist (or * when I am ready) and the plumbing is already there.

Where things are rough

All over, honestly. I patch things day by day, but I can only move so fast. Some tabs are placeholders or thin - Insights is early, Docs is optional per repo and still growing. Campfire and CI are the two biggest "works, but young" areas.

There will be bugs, sharp edges, and missing features you expect from a mature host. If you hit one, please report it on the issues page: https://open-git.com/madison/open-git/issues - repro steps help a lot.

Try it

Sign up, create a repo, push something, open a PR if you want to kick the tires. Browse public repositories without an account if you just want to look around. I would love to hear what breaks or what you wish existed - issues on https://open-git.com/madison/open-git/issues are the fastest way to get it to me.