(Kinda) Leaving Overleaf

I plan to make a plain Git project repository (e.g., from this template) the default for all new papers from my group, instead of Overleaf. I won’t leave Overleaf entirely; collaborators who live in it will keep me there for some papers. But I have always reached for a git repo when I could, and now I want to make it the norm. This is less about Overleaf getting worse than about the alternative becoming far more viable.

I already preferred git#

This isn’t a conversion. I preferred a simple git repo even before Overleaf existed, mainly for the control, the explicitness, and the workflow it gives me. Overleaf was a concession: easy onboarding for collaborators who don’t know git, a link I could send to anyone, nothing to install. I do see the appeal of real-time co-editing, so my position has been “I don’t mind using it” when a project calls for it. But the reasons for that concession are evaporating.

What a git repo gives you#

Three things, all of which predate any AI agent.

Control, cost, and no lock-in#

On Overleaf your work is tethered to a service and a live connection: no Overleaf, no internet, no writing. And it does go down; when it does, an approaching deadline turns into a disaster you can do nothing about. A temporary outage is the mild version, though; the real risk is a sudden shutdown or permanent data loss on their side, and there is no easy way to bulk-export everything you keep on Overleaf. A git repo has no such single point of failure: the files live on my disk and on a remote I choose, fully usable offline, every clone is already a complete backup of the full history, and the plain text and .bib will still open in thirty years with or without any particular company.

It’s also cheaper. The Overleaf features that matter for serious work—git sync, more collaborators, longer compiles, full version history—sit behind a per-seat subscription that adds up, and you’re paying to be more locked in. With a repo I use any package and any tool I want.

Explicit, more observable history#

Git’s history is what I value most here. Every change is a readable diff, and a whole ecosystem of tooling lets you navigate and examine that history to pinpoint exactly what happened and when. Branches let you try a big reorganization without endangering the paper, and rewinding to any earlier state is trivial.

When everyone edits one live document at once, a change can slip by unnoticed; a git workflow makes each change explicit instead. You commit each unit of edits, or open a pull request to turn a set of them into a proposal others can review and discuss. Either way the change lands as a concrete, attributed commit you can examine with any tool. Overleaf’s track-changes and version history are a pale imitation of git’s Version control ecosystem—diffing, bisecting, blame, signed history, and everything built on top of it.

One repo, one workflow#

Using git repos, the paper and the whole research codebase behind it can live together—analysis code, data (or pointers to it), figure-generation scripts, and the manuscript in a single history. Furthermore, you can wire the whole chain into a workflow tool like Snakemake so figures, tables, and the PDF rebuild from source with one command. Take the most ordinary task: you spot a problem in a figure. With Overleaf the figure and the code that made it live in different places, so you fix and run the script somewhere else, regenerate the image, and then re-upload it into Overleaf by hand. In a project repo the figure is already an output of the build, so you just fix the code and rebuild—no upload step, and no way for the PDF to drift from the script that produced it.

From that one source you also produce every version you need—the arXiv build, the journal template, the response to reviewers, a beamer/MARP deck—either as branches or tags, or as explicit folders (which I prefer), with macros and .bib reused across papers. Overleaf nominally supports this by letting you pin a main source file, but juggling multiple .tex files is a hassle, and the pin glitches often enough that you frequently end up editing an outdated copy of the manuscript. A single project regularly spawns several Overleaf projects (main manuscript, extended abstract, a submission to a different journal), and they get lost in the depths of the project list. In a repo, building several documents at once is trivial, and it nudges you toward explicit, named versions instead of pinning whichever main file you happen to be working on.

None of that needed an AI agent; it was always the reason git beat a browser editor for me. To be honest, I can’t always realize the full pipeline in practice; the figures still rot into stale PNGs more often than I’d like. But even a half-wired pipeline gives me a lot of Reproducible research for free, since the code, data, and manuscript already share one versioned history. Full automation is always within reach. Edit in Neovim with my own keybindings, snippets, and linters, compile locally with Latexmk, and let CI compile the PDF and run automated checks (e.g., see Claude Scholar). More than that, the whole text-processing toolchain is available to the manuscript: latexdiff to show a reviewer exactly what changed, spell and grammar linters, ripgrep and sed across the entire paper, word-count and style scripts, pre-commit hooks—none of which a browser editor can provide.

The barriers that made Overleaf worth it#

Overleaf does two things very well: lowering friction and facilitating collaboration. It delivers both at once—a browser, a project, live co-editing, nothing to install. Against that, local LaTeX plus Git always carried a tax: a working TeX distribution, a remote (e.g., GitHub), knowing how to resolve a merge, and so on. Not everyone is comfortable with git and a command-line toolchain, and for many people that tax was severe enough to justify the walled garden.

AI agents drastically lower the barrier#

Coding agents are removing that tax. The setup, the build wiring, the occasional merge conflict—an agent fluent in git and the command line handles all of it. So I no longer think a browser-based, locked-in editor has enough of an edge to justify the cost and the drawbacks.

Once the paper lives in a repo, the agent can handle the unglamorous work that used to make local setup annoying: it can scaffold the project, wire up the build system (the Makefile, the latexmk -pvc monitor and compilation scripts), run all the supporting tools and presubmit checks, handle the git complexities including the occasional merge conflict, and make helpful suggestions along the way. And since an agent works on files in a repo, not inside a sealed browser tab, staying on Overleaf means forgoing that help entirely—to save the very setup the agent would have handled for you.

Some practical tips for migration#

Suppose you’re convinced. Git still can’t match the thing Overleaf does best: real-time, Google-Docs-style co-editing with nothing to install for anyone. And the biggest hurdle is social rather than technical. Some collaborators won’t adopt a command-line, AI-driven workflow, and others are simply more productive in a browser; it isn’t reasonable to make them learn a toolchain they don’t want just to write with you.

A few small tips. The most important one isn’t about git or AI at all: communicate. Conflicts and stale-version problems are mostly coordination failures, not tooling failures—they happen just as easily on Overleaf. Agree on who is editing what and when, and most of the trouble never appears.

For git specifically, settle on a workflow (here’s mine): commit and push often, keep branches short-lived, and stay aware of what others are touching. Co-authors usually take turns rather than typing over each other, and a pull request fits that rhythm; each work session is a branch, with review as line-anchored comments on the PR instead of % TODO notes buried in the source. One tiny habit helps too: write one sentence per line (semantic line breaks), so git’s line-by-line diffs and merges stay clean and two people can edit the same paragraph without colliding. You can also split the manuscript into per-section files pulled in with \input, so collaborators working on different sections rarely touch the same file at all.

For the collaborator who just wants a browser, Overleaf can stay in the loop without trapping the work there. Every Overleaf project exposes a git remote (a premium feature), so at minimum you can clone the paper as a standalone, paper-only repo and sync it with ordinary pull and push. Better, keep the paper as its own GitHub repo linked to Overleaf via GitHub sync and pull it into the main research repo as a submodule: the co-author edits in the browser, you get their commits in git, and the rest of your pipeline stays put. The one catch is that Overleaf compiles only its own project, so any code-generated figure has to be committed as a built file. None of this brings back simultaneous typing, but for how papers actually get written, I think the tradeoff is worth it.