Live data from Hacker News

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

blog.gitbutler.com

661–670 of 785 posts

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

#661
post #533

> The old model assumed one person, one branch, one terminal, one linear flow. Not only has the problem not been solved well for that old model, it’s now only been compounded with our new AI tools. 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 fo…

The problem is how to make money from something that is more or less solved.

It’s not solved because it’s trash. There’s no good interface for it and people find it difficult to use.

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

#663
Real problem is how to cope with few billion of bots hammering APIs 24/7 saturating net cables, physical infrastructure and taking down platform with constant DDOS.

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

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

#664

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…

The problem put simply is that git doesn't support concurrency. Even if you use worktrees, git has a global lock for repo interaction.

https://www.felesatra.moe/blog/2024/12/23/jj-is-great-for-th...

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

#665
post #660

Earlier quoted context omitted.

I would argue it being proprietary would be completely unacceptable, for such a position of importance. In any case, Git has become tremendously entrenched over the past couple decades. Anything that hopes to replace it would have to be significantly better to break from the inertia Git has. I’m honestly skeptical as to whether this is even possible in the near future. We’re not at all in the same historical moment a…

git's replacement won't be there because it was better at being what git is (too entrenched), but because git became redundant as the world changed around it. As agentic development takes over and people stop caring about source code, all the tooling (including languages themselves) and approaches to assist humans will be ripe for replacing with those for machines.

Exactly. Big “generals always prepare to fight the last war” energy.

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

#666
post #591

Earlier quoted context omitted.

if the cli is open sources and ends up finished i don't see what the problem is to let a vc fund them building it

VCs are not particularly well known for their commitment to building products that they can't make money off of. They'll promise you the OSS world and then as soon as they can they'll pull the rug out from under you.

If they release the code with a permissive license, then this doesn't matter.

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

#667

Earlier quoted context omitted.

Just create a new branch before you implement new features and if the agent messes up don't merge the branch. That way you get the best of both worlds. The buggy code is still there in case it's needed but it's not in the main branch

Most of the time when I'm using Claude my working tree is already dirty because I'm mid-task. I usually try to do a throwaway commit before every interaction with Claude, but it's easy to forget, or to leave the "accept edits" mode on accidentally and my working tree gets corrupted. Also having to commit takes you out of flow because you suddenly have to deal with any new gitignores, which requires at least a glance…

jj offers "jj undo" which will undo changes to your repo, and the "oplog", which is sort of like the reflog, but on steroids. It's one of the nicest things about it.

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

#668

Earlier quoted context omitted.

> For instance, "move this hunk two commits up" is a task that makes many git users sweat. Citation needed. You split the commit anyway you like, e.g. with the mouse or using cursor movements or by duplicating and deleting lines. Then you move it with the mouse or cursor or whatever and squash it into the other commit. Maybe some people never intend to do it, but then these probably also don't want to learn JJ. I gue…

I'm one of the git users who would sweat. Can you explain a bit (out link relevant docs) how I might split a commit up, and move it?

Here's two "raw" methods:

1. Use "git rebase -i commitid^" (or branch point, tag etc), ideally with editor set to Magit, set that commit to "edit" (single key 'e' in Magit) and let the rebase continue, do "git reset -p HEAD^" and select the hunks you want to remove from the first commit, "git commit --amend", then "git commit -a" (add -c if useful, e.g. to copy author and date from the previous one). or to keep the author date), then "git rebase --continue" to finish.

2. Same, but use "git reset HEAD^" (add -N if useful), then "git add -p" to select the hunks you do want to include in the first commit.

Afterwards you can do the "git rebase -i" command again if you want to reorder those commits, move them relative to other commits, or move the split-out hunks into another existing commit (use the 'f' fixup or 's' squash rebase options).

After doing this a few times and learning what the commands actually do, it starts to feel comfortable. And of course, you don't have to run those exact commands or type them out, it's just a raw, git-level view. "git rebase -i" and "git add -p" / "git reset -p" are really useful for reorganising commit hunks.

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

#669
post #533

> The old model assumed one person, one branch, one terminal, one linear flow. Not only has the problem not been solved well for that old model, it’s now only been compounded with our new AI tools. 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 fo…

> To me it's not clear what the problem is that would require a redesign. The interface is still bad. Teaching people to use git is still obnoxious because it's arcane . It's like 1e AD&D. It does everything it might need to, but it feels like every aspect of it is bespoke. It's also relatively difficult to make certain corrections. Did you ever accidentally commit something that contains a secret that can't be in th…

> Did you ever accidentally commit something that contains a secret that can't be in the repository?

What do I need to do on top of a git force push, and some well documented remote reflog/gc cleanup, which I can’t find with a single search/LLM request? Are we there, where we don’t have enough developers who can do this without feeling it as a burden? Or are we there where this level of basic logic is not needed to implement anything production ready?

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

#670
post #533

> The old model assumed one person, one branch, one terminal, one linear flow. Not only has the problem not been solved well for that old model, it’s now only been compounded with our new AI tools. 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 fo…

[dead]
Post reply on HN