Live data from Hacker News

We've raised $17M to build what comes after Git

blog.gitbutler.com

551–560 of 785 posts

Re: We've raised $17M to build what comes after Git

#551

I recently switched to Jujutsu (jj) and it made me realize that “what comes after Git” might already exist. 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…

What's the difference between "snapshots" and git commits? In my mind a git commit is already a snapshot of the repo and the changes one staged. In what way can you move around more freely than what one can do with magit, deciding for files, hunks, or even single lines of code, whether or not they get staged and committed?

You're right that git commits are snapshots.

jj is very non-modal, that is, it doesn't tend to have a lot of state that commands rely on. As an example of what I mean, because jj does not have a staging area, everything is already committed, which makes it very easy to say, move to a different commit: you don't need to stash your working copy, as jj has already stashed it for you. Similarly, due to the auto-rebase behavior, you can be working in one part of the tree, realize something somewhere else should be moved, and go rebase that without even moving to it at all!

As a small example: say I'm working on something, and I find a typo. I want to send that typo in as a PR, but I don't want to do it as part of my work. I can do that with:

1. make the change in my current working copy (@)

2. jj split -o trunk (selecting the typo contents to split off the typo fix into a new change on top of (hence -o) trunk)

3. jj log (go check out what the change id of that change is

4. jj git push -c

No need to even move my own HEAD (in git terms), just knock it out inline in a few steps while I'm working.

Now, as for magit, I don't use it, and I know that those that do love it and it does make some of this stuff easier. But not everyone can use magit. And there are "magit, but jj" projects as well, but I can't speak to them or which is best at the moment.

Re: We've raised $17M to build what comes after Git

#553

I recently switched to Jujutsu (jj) and it made me realize that “what comes after Git” might already exist. 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…

> You can just mess around and make it presentable later, which Git never really let you do nicely. I'm surprised to read that, because that's how I've always used Git (and GitHub). That's what I've understood to be good practice with Git, and it was liberating compared with what came before. One of the nicest things about Git is you can throw things in locally without worrying about how it looks, and make it present…

I also did that with git, but it's no comparison in ergonomics. For instance, "move this hunk two commits up" is a task that makes many git users sweat. With jj it's barely something that registers as a task.

Re: We've raised $17M to build what comes after Git

#555
No shade on these guys, looks like a cool tool and I'll try it. However, I find myself doing large majority of my git operations using a an agent[1] or a TUI [2], and I rarely open a git interface. I can get everything done straight from the terminal.

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

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

Re: We've raised $17M to build what comes after Git

#556

A lot of people seem confused about how they raised the money, but it’s actually a pretty easy VC pitch. - 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 th…

Put another way: the idea didn't raise $17M, the team did. That's usually the case but you can fully expect a pivot in their future.

Once open source spreads into an area, it tends to kill (commodify) commercial software in that space.

For example, with databases, MySQL and Postgres "won". Yes, there are commercial databases like SQL Server and Oracle but they largely exist through regulatory capture and inertia. It's highly unlike anyone will ever make a commercial general purpose database again. There are always niche cases.

Same with operating systems. Yes we have MacOS and Windows but what are the odds we get another commercial mass OS? I'd say almost zero.

It's the same for source control. Git "won". There are a handful of others (eg Mercurial). But gone are the days of, say, Visual Source Safe.

But when people talk about "what comes after Git" they really mean (IMHO) "what comes after Github", which is a completely different conversation. Because Github absolutely can be superseded by something better. Will it though? I don't know. It has an incredible amount of inertia.

As for AI and anything related to source control, I'd have a hard time betting against Anthropic. But remember the exit could be an HN post of "We're joining Anthropic!". Side note: I really hate this "we're joining X" framing. No, you took the bag. That's fine. But let's be honest.

For people with a proven track record, AI is a gold rush of acquisition more than creating a sustainable business, let alone an IPO. I think that's what this bet is.

Re: We've raised $17M to build what comes after Git

#557

Earlier quoted context omitted.

Apparently it takes $17M and a whole team full of people to do what one guy with a chip on his shoulder could do for free.

Uhh, to be fair, if the goal was only to recreate git from 2005, it probably wouldn't cost $17M. I'd hazard a guess that they're recreating modern git and the emergent stuff like issues, PRs, projects, etc. I've also heard that the core devs for git are essentially paid a salary to maintain git.

They're not though, they're using Git internally.

Re: We've raised $17M to build what comes after Git

#559

Huh. I look at what it took to build Git to begin with[1] and have to wonder if the thing that comes after it is really going to be _that much_ better. Git came about because there was a need for it. I feel like GitButler came about because there was a need for funding. Maybe I just need to have my coffee before commenting. [1] https://en.wikipedia.org/wiki/Git#History

I'm trying not to comment on too many of these, but this one is interestingly wrong to me, so why not indeed? GitButler came about many years ago because I have been using Git for almost the full 20 years of it being around and I thought there could be a better way to do the things it's trying to solve for us. I want version control to do more for us, easier, faster and smarter. Git is still pretty dumb. Plus, now, e…

Why is GitButler still using Git if Git is the problem?

> As a _single_ example - agents can't use interactive editors, yet _so many_ of the powerful parts of Git absolutely _require_ it. Agents can't interactively rebase, meaning they can't very effectively squash, amend, reword, reorder, absorb. They can't very easily interactively add. They are middling at best when it comes to stacking branches. Git is designed to send patches over email and agents are not concerned with that.

Why aren't these just patches to Git itself? Or a fork of Git. You're layering tooling on top instead of fixing the foundations? You say stop layering? But you're clearly still using Git because you're calling it GitButler. You're another layer, like jj and like GitHub's UI.

Re: We've raised $17M to build what comes after Git

#560
Maybe the pitch is:

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.

Post reply on HN