A bit of a strange thing to say in my book. Git isn't SVN and I think these problems are already solved with git. I agree that the interface is not always very intuitive but Git has the infrastructure which is very much focused on supporting alternatives to "one person, one branch, one terminal, one linear flow".

> the problem that Git has solved for the last 20 years is overdue for a redesign.

To me it's not clear what the problem is that would require a redesign.

- It’s from one of GitHub’s cofounders.

- GitHub had a $7.5B exit.

- And the story is: AI is completely changing how software gets built, with plenty of proof points already showing up in the billions in revenue being made from things like Claude Code, Cusor, Codex, etc.

So the pitch is basically: back the team that can build the universal infrastructure for AI and agentic coding.

they aren't building something to help you, they're building something to trap you. even if it's free, does things you like, etc., do not use it. their end goal is to screw you

It turns out the snapshot model is a perfect fit for AI-assisted development. I can iterate freely without thinking about commits or worrying about saving known-good versions.

You can just mess around and make it presentable later, which Git never really let you do nicely.

Plus there’s essentially zero learning curve, since all the models know how to use JJ really well.

* pre-commit — The malicious one. It intercepted every `git commit` attempt and aborted it with that error message, forcing you to use `but commit` instead. Effectively a commit hijack — no way to commit to your own repo without their tool.

* post-checkout — Fired whenever you switched branches. GitButler used it to track your branch state and sync its virtual branch model. It cleaned this one up itself when we checked out.

* There's also typically a prepare-commit-msg hook that GitButler installs to inject its metadata into commit messages, though we didn't hit that one.

* The pre-commit hook is the aggressive one — it's a standard git hook location, so git runs it unconditionally before every commit. GitButler installs it silently as part of "setting up" a repo, with no opt-in. The only escape (without their CLI) is exactly what we did: delete it manually.

It may be a great tool, but I'd be very reluctant to use a closed-source solution as a cornerstone of infrastructure.

1) Git is fine

2) I would not want to replace critical open source tooling with something backed by investor capital from its inception.

Sure, it will be “open source “, but with people throwing money behind it, there’s a plan to extract value from the user base from day one.

I’m tired of being “the product”.

Critical open source tooltips by should spring from the community, not from corporate sponsorship.

How will you ever get the network effects needed to get sustained users with a commercial tool?

Given Git was created because BitKeeper, a commercial tool, pulled their permission for kernel developers to use their tool aren’t we ignoring a lesson there?

> The hard problem is not generating change, it’s organizing, reviewing, and integrating change without creating chaos.

Sure, writing some code isn't the bottleneck. Glossed over is the part where the developer determines what changes to make, which in my experience is the most significant cost during development and it dwarfs anything to do with version control. You can spend a lot of energy on the organising, reviewing, patching, etc. stuff -- and you should be doing some amount of this, in most situations -- but if you're spending more of your development budget on metaprojects than you think you should be, I don't think optimising the metatooling is going to magically resolve that. Address the organisational issues first.

> This is what we’re doing at GitButler, this is why we’ve raised the funding to help build all of this, faster.

The time constraint ("faster") is, of course, entirely self-imposed for business reasons. There's no reason to expect that 'high cost + high speed' is the best or even a good way to build this sort of tooling, or anything else, for that matter.

Git's UI has become increasingly friendly over a very long time of gradual improvements. Yes, Mercurial was pretty much ideal out of the gate, but the development process in that case was (AFAIK) a world away from burning money and rushing to the finish.

Maybe going slow is better?

So, I really hope security incidents don't come after Git!

That said, I find the branding confusing. They say this is what comes after git, but in the name and the overall functionality, seems to just be an abstraction on top of git, not a new source control tool to replace git.

https://docs.gitbutler.com/cli-guides/cli-tutorial/rubbing

I like their vision, though, this is compelling to me:

> What if it was easier to for a team to work together than it is to work alone?

It generally _is_ easier to work alone with git. UI and DX experiments feel worthwhile. lazygit and Magit are both widely used and loved, for example, but largely focus on the single user experience.

This doesn't seem to be the direction these guys are going though, it looks like they think Git should be more social or something.

BUT why not just work with the git community to add this functionality? It doesn't seem like the kind of thing that needs to "replace" git, as opposed to "improve" git?

I was really hoping we'd see some competition to Github, but no, this is competition for the likes of the Conductor App. Disappointed, I must say. I am tired of using and waiting for alternatives of, Github.

The diff view in particular makes me rage. CodeMirror has a demo where they render a million lines. Github starts dying when rendering a couple thousand. There are options like Codeberg but the experience is unfortunately even worse.

If this isn’t something to at least root for, in the sense of a small team, novel product, serving a real need, then I dunno what is. You can use jj or tangled and still appreciate improvements to git and vcs on the web in general. Competition amongst many players is a good thing, even if you don’t believe in this one particular vision.

Heaven forbid it isn’t 100M going to a YC alum for yet another AI funding raise.

If you raise money for this project, you probably intend to make money in the near future. I don’t think anyone here wants ads on Git or to argue with a manager to get the premium version of GitButler just because you reached the commit limit.

These $17M should go to the Git maintainers.

FTFY. I don't understand how anyone could think to replace git by raising money. The only way to truly do this is grassroots iteration. You can build the software, but the distribution will never reach the same network size as git before your investors start asking "When do I get my return?"

> Imagine your tools telling you as soon as there are possible merge conflicts between teammates, rather than at the end of the process.

So you're centralizing a fully distributed process because grepping for "<<<<<<<" and asking your teammate the best way to merge is too hard? I thought coding was supposed to be social?

I mean, honestly, go for it and build what you want. I'm all for it! But maybe don't compare it to git. It's tone deaf.

Gitbutler virtual branches OTOH appear to provide branch independence for agents/commits, while simultaneously allowing me to locally verify all branches together in a single local env. This seems quite a bit nicer than checking out worktree branches in the primary workspace for verification, or trying to re-run local setup in each worktree.

It can back on to git if you want, so a migration doesn't have to be all-at-once. It already has all of these features and more. It's stable, fast, very extensible.

jj truly is the future of version control, whereas git plus some loosely specified possibly proprietary layer is not.

I'm excited to see what ersc.io produces for a jj hosting service and hopefully review UI.

However good this new thing might be, however much better it might be than git - I don't like it's chances.

Alternatively I had the idea of something that automatically syncs your current working progress similar to how Word and Excel autosave work. With a main "branch" thats never developed in and will only be merged into from synced streams. But that idea is nowhere near cooked out yet.

We have AI now. AI tools are pretty handy with Git. I've not manually resolved git conflicts in months now. That's more or less a solved problem for me. Mostly codex creates and manages pull requests for me. I also have it manage my GitHub issues on some projects. For some things, I also let it do release management with elaborate checklists, release prep, and driving automation for package deployment via github actions triggered via tags, and then creating the gh release and attaching binaries. In short, I just give a thumbs up and all the right things happen.

To be blunt, I think a SAAS service that tries to make Git nicer to use is a going to be a bit redundant. I don't think AI tools really need that help. Or a git replacement. And people will mostly be delegating whatever it is they still do manually with Git pretty soon. I've made that switch already because I'm an early adopter. And because I'm lazy and it seems AI is more disciplined at following good practices and process than I am.

The line-based diff(1)/diff3(1)/patch(1) kit often works, and that mindset thrives and gets carried till today. Many toolkits and utilities have been designed to make it more ergonomic, and they are good. Jujutsu is an example. We also have different theories and implementations, some even more algebraically sound like Darcs and Pijul.

But GitHub the Platform is another story, given that they struggled to achieve 90% availability these days.

I like the idea of parallel branches. I feel like you could probably get away with just creating multiple, named stages but having a full history is nice. P4 has multiple pending CLs and it works nicely enough. This sounds a bit better so that's cool.

As far as "social coding" git's design is really at odds with any sort of real time communication. I would love to see a first class support for file locking, and file status work flows. It's not big at all in code dev because code can be merged but for non-coders, source controlled assets are often not mergeable. To solve this, P4 is often used with heavily integrated tools that provide live file status (Locked, out of date, edited by others). This way merge conflicts are prevented at author time. Git is really lacking here. Is fetching constantly really the best we can do?

Then of course... can we get some large file and partial checkout workflows that don't feel good?

What does "what comes after Git" look like for a two-person team vs. a 200-person org? The pain points are completely different.

This is actually really important/useful, it's just not apparent to people who haven't worked on AI agents.

AI agents do a lot of work under the hood to try to save your tokens. There are two basic methods: 1) semantic knowledge maps, 2) PageRank. Agents like Aider will build a semantic knowledge graph of your codebase - the files in it, the functions, variables, etc - so that it can tell the agent exactly where everything is in a tiny summary. It'll also then use PageRank to build a graphed rank of these things, to surface the most relevant items first. (https://aider.chat/2023/10/22/repomap.html)

A modern VCS could do all of these things for you too, and the result should be making it easier to work with code, pulling in the related context simultaneously, so your changes make sense.

I have found that a number of times GitHub's idea of "convenient" comes either from 1) not understanding git fundamentals such that it closes off possible workflows, or 2) pushing a philosophy on users, i.e. I know better than you, so I'm going to block you.

Also, I don’t think I would use this and the problems they describe aren’t really things I care much about.

I wish them the best, but $17m on a devtools company that thinks they are replacing git is going to be rough going.

I'm reminded of a comedy album, "The First Family", from the 1960s where Bobby Kennedy impersonator wanted to form a new political party. He named it something like "Major Affiliate For an Independent America" (I might have that wrong.) Or the M-A-F-I-A.

He said their first order of business was to change the name of the organization.

https://www.youtube.com/watch?v=Xwu8S6Ekx9w

EDIT: I'm not positive that's the correct album but have a good laugh anyway.

I don't know the answer, but I think it could easily be three times as good and I would still stick with git

Another take I've seen is https://agentrepo.com/, which is light-weighted hosted git that's easy for agents to use (no accounts, no API keys, public repos are free). There are large parts of the GitHub experience I'm no longer using (mostly driving from Claude), so I think this is an interesting take.

But you also get an idea of the average reading skill of people based on the top 3 comments: "I don't want a replacement for Git!"

I'm not blaming anyone, or maybe both the readers and the authors.

People now write something that could've been published as a short story 30 years ago, for something that could be a paragraph in length, detailing their emotional state, minute background information, their hopes and dreams.

The adaptive response to this by humans and society is to read the headline and ignore the prose, as the prose is so god damn long.

"Gitbutler is a UI for Git" would've been more suitable than hype about replacing git.

1. git is not going away 2. git UX is not great

So i appreciate their effort to manage development better as agents make it possible to churn out multiple features and refactors at once.

BUT, I reject this premise:

3. Humans will review the code

As agents make it possible to do so much more code (even tens of files sucks to review, even if it’s broken into tiny PRs), I don’t want to be the gatekeeper at the code review level.

I’d rather some sort of policy or governance tooling that bullies code to follow patterns I’ve approved, and force QA to a higher abstraction or downstream moment (tests?)

git is distributed. Decentralised improvement. Local computers and their users make changes. These steps of local added value are then centrally combined into a shared timeline. A single product. During the improvement the locus of control is local. Which means it is hard to harvest the knowledge of this local knowledge and replace it. And it's hard to make local users serve the central AI.

Not something you put in the public mission statement. Because you might get boycotts.

[1] https://en.wikipedia.org/wiki/Git#History

I think the real money is in figuring out a centralized model that doesn't suck. Explicitly locking things has certain advantages. Two people working on the same file at the same time is often cursed in some way even if a merge is technically possible. Especially if it's a binary asset. Someone is going to lose all of their work if we have a merge conflict on a png file. It would be much better to know up front that the file is locked by some other artist on the team.

I guess I can overcome the "what if I cannot undo" anxiety.

[1] https://getcook.dev [2] lazygit

As others alluded, JJ already exists and is a credible successor to Git for the client side.

Technical desides aside though: how is this supposed to make money for the investors?

App itself for Windows won't proceed past my selected repo. Said something about bad permissions, but I use that repo every day.

I think that's something I don't want to imagine

https://docs.gitbutler.com/cli-guides/cli-tutorial/operation...

and git's reflog:

https://git-scm.com/docs/git-reflog

With a box of scraps!

I'm curious what their long term vision they pitched investors is.

But then it's the github cofounder- well, github did add a lot of stuff onto git I didn't know I needed, so I'm curious.

Git CLI with flowers and unicorns.

Is this what gets funded nowadays? I really hope for a gigantic mega crash of all the IT companies. This industry deserves it like none other.

Pound foolish and folly

Sus.

Drop the “fundamentally”.

“It’s cleaner that way.”

The Github PR flow is second nature to me, almost soothing.

But it's also entirely unnecessary and sometimes even limiting to the agent.

Also, if you ever worked with Perforce, you might be familiar with changelists. It’s kind of like that.

Now, GitButler is by no means perfect. There are many rough edges. It tends to get stuck in unexpected states and sometimes it isn’t easy to rectify this.

It also cannot split changes in a single file, which is a bummer, because that’s something I encounter routinely. But I understand this complicates the existing model tremendously.

Well, I think it won't

Refreshing. I am so tired of the usual PR-approved phrases that you read in every announcement.

Other than that, I agree with other comments: not sure what Git's problem is, and what they are supposed to solve. Star Wars' "it's a trap" vibes.

buthub has a nice ring to it

We’re building the infrastructure for how software gets built next."

Dude, aside from this type of phrasing being cringe, it's such blatantly obvious LLM induced psychosis phrase... ridiculous.

I didn't even read that insanely long article explaining why one would need this (the necessity should have rang one or two bells for the author)... but all i could think of before reading that cringe ending, was: you're building what comes after git, but carry "git" in your name seems kinda odd... already revealing you either don't believe your own claims, or you do, but don't really mean what you're claiming... either way: WTF. Insane what's getting funded.

Also: the trend of companies overly feeling the need to explain they're not just X + AI (which also means LLM API), should really ring a lot of other bells to everyone else... god damn, too many bells to ring... and it seems like there is only AI chatbots left, that respond to anyone ringing the bell... god damn... they already took over & infected the human brain...

Easier Git doesn't translate into something I can get my boss to pay for.

Superbly tone deaf. The only people who might possibly want to read that are those already drinking your Kool-Aid, most everyone else can already smell the bullshit.

No thanks.

Was their series A pitch also written by llm?

Quite an understatement. I'm pretty sure GitHub is the primary reason that Git took off like it did.

> The old model assumed one person, one branch, one terminal, one linear flow.

Um, there's more than one flow out there? Feature branches are usually "one person, lots of branches, squish at the end". Since when is Git linear? Some of them even come with their own scripts or GUIs.

I'm even less convinced that something that's raised $17M already will provide a free-as-in-beer solution.

Git has issues, but it works pretty well once you learn it and it's basically universal. Will be hard to dislodge.

Im curious when it will be “SO BAD” we start blocking every AI agent on firewall level.

These people seem to think that their "added value" was the selling point of their product... they appear to believe that some bad things are actually good and desirable, like, for example:

> Heck, it could be argued that development in teams is less social than it was when version control was centralized.

> But what if coding was actually social? What if it was easier to for a team to work together than it is to work alone?

This reeks of open-space floor office plan all over again! When some HR managers decided that programmers need all to sit in the same room the size of a basketball court and that would somehow help them work together better...

Programming is absolutely an individual activity first, where communication helps, but in order to be helpful the communicating parties have to have an initial internal process that refines the messages s.a. not to waste the other party's time. In practice, productive communication may happen once a day... up to once a week maybe? Maybe even less frequently? Git, as it is, is perfectly fine for this.

> Ok, that’s the simple case, pretty straightforward. However, GitButler can also do some pretty cool things that Git either cannot do or struggles with, namely:

> Having multiple active branches that you can work on in parallel.

I'll check out the same Git repository in different directories and will have this ability... maybe also add the second checkout as a remote to the first... but the number of times I've done it in two decades of working with Git is... maybe two? This is an extremely unusual need. I think, I've done this when migrating from multiple repositories into a monorepo and I had to somehow reorganize the history of multiple repositories so that it would make sense together. Definitely not a task for every day, not even every year.

The whole follow-up demonstration of parallel branches is just... Why on earth would I ever want to do that? Why would I want to work in such a way that I commit changes to different branches at (roughly) the same time? It's kind of like stashing changes, but, stashing is the byproduct of "bad planning": I wanted to do one thing, and accidentally did another... oh well, let's save the change somewhere temporarily! But, ideally, I want this to happen as little as possible. Not because it's inconvenient to deal with stashed changes, but because I will very quickly lose track of what goes where, why any particular branch exists etc.

Similarly, for the stacked branches: I absolutely don't want this functionality to exist... if it was already in Git, I'd request that it never be used. This complicates the mental model of what is even possible in the repository and creates some nightmare fuel scenarios: what happens if you stack them sequentially? What happens if you stack many branches on the same branch, and then want to rebase one of the stacked branches? What happens if you rebase the branch on which other branches are stacked? What happens if you delete the branch on which other branches are stacked? Does the stacked branch have to exist in the local checkout, or could it come from a remote?

It's absolutely the case where simple is better (I'd never imagine I'd call Git simple, but here we are).

I can't imagine what the workflow of people who want these changes must look like. I can't imagine why would anyone want to copy that kind of a workflow.

They raised $17M to build what appears to be solvable by some git wrapper scripts that could have been written by AI in 5 minutes?

To me the extra "wat" about this is that if I spend the sub-$1 to get the git wrapper scripts, I can get them exactly the way I want them, instead of being mandated to use the commands they made up. A huge gain for AI is the ability to have exactly the software you personally want, even if nobody else wants it just so.

So they are building the exact opposite of the need that AI brings forward. What they are building is not even median software that is in danger of being replaced (e.g. see Cloudflare spending a week to build "a wordpress"), but something that's the most extreme example of AI-will-replace-this that could possibly exist.

Who will buy this?

The only way this makes sense is as a plea for being acqui-hired (and the project dropped).

If you want to come AFTER Git... you need to not use Git.

> We are creating not only a new kind of Git client,

Nope, not going to be the tool of the future.

The fundamental problem is it is still based on git.

Till this addresses submodules and makes them a first class citizen it's just tooling on top of a VCS that still ONLY supports single project thinking.

But even with all the Git tooling under my belt, I seem to have all but concluded that Git's simplicity is its biggest strength but also not a small weakness. I wish I didn't have to account for the fact that Git stores snapshots (trees), after all -- _not_ patch-files it shows or differences between the former. Rebasing creates copies or near-copies and it's impossible to isolate features from the timeline their development intertwines with. Changes in Git aren't commutative, so when my human brain naively things I could "pick" features A, B, and C for my next release, ideally with bugfixes D, E and F too, Git just wants me a single commit, except that the features and/or bugfixes may not all neatly lie along a single shared ancestral stem, so either merging is non-trivial (divergence of content compounded with time) or I solve it by assembling the tree _manually_ and using `git commit-tree` to just not have to deal with the more esoteric merge strategies. All these things _do_ tell me there is something "beyond Git" but it's just intuition, so maybe I am just stupid (or too stupid for Git)?

I started looking at [Pijul](https://pijul.org/) a while ago, but I feel like a weirdo who found a weird thing noone is ever going to adopt because it's well, weird. I thought relying on a "theory of patches" was more aligned with how I thought a VCS may represent a software project in time, but I also haven't gotten far with Pijul yet. It's just that somewhere between Git and Pijul, somewhere there is my desired to find a better VCS [than Git], and I suspect I am not the only one -- hence the point of the article, I guess.

Oh boy. Thanks for the nightmares.

Like all I see here is "We want to build a fence around git and then charge you to go through it." I mean this as kindly as I can mean it: no thank you.

Leave Git alone.

Today, with English, we're all teaching swarms of agents to use a language built from scraps of Norman French and Anglo-Saxon Old English. That's far from what is needed today.

But instead, we get a replacement for Git. And I didn’t even bother to click the link because I’m fine with how Git works. On the list of pain points in my life, “what comes after Git” has roughly the same priority as “try out a more exciting shower gel”. But did you ever step on a LEGO brick while walking to the bathroom at night? That pain is immediately obvious.

Why is nobody solving actual problems anymore?

The need for exactly this is not ever going away, and its ubiquity proves that Linus nailed something that is truly fundamental.

This is like saying we need a new alphabet because of AI. That is VC hype, even if it comes from a Github founder.