Live data from Hacker News

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

blog.gitbutler.com

621–630 of 785 posts

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

#621

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…

I use Git as a deduplication compressing backup tool. Git is fine and useful for a multitude of uses both manual and automated. Maybe the UI aka. porcelain is a bit clunky, but Git was explicitly intended to be separated into porcelain and plumbing, so that you can use the plumbing to make your own porcelain.

From git(1):

    LOW-LEVEL COMMANDS (PLUMBING)
       Although Git includes its own porcelain layer, its low-level commands 
       are sufficient to support development of alternative porcelains. 
       Developers of such porcelains might start by reading about git-update-index(1) and git-read-tree(1).

       The interface (input, output, set of options and the semantics) to these 
       low-level commands are meant to be a lot more stable than Porcelain level 
       commands, because these commands are primarily for scripted use.
       The interface to Porcelain commands on the other hand are subject to change 
       in order to improve the end user experience.

       The following description divides the low-level commands into commands that 
       manipulate objects (in the repository, index, and working tree), commands 
       that interrogate and compare objects, and commands that move objects and 
       references between repositories.

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

#622

Earlier quoted context omitted.

> 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.

> 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 guess this is more of a selection bias, that these that care about history editing are also more likely to learn another VCS on their own.

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

#623
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.

Yep, something that is sadly becoming more and more common. People with solutions spending insane money trying to convince others that a problem exists.

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

#624
post #572

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…

Every success story and happy conversion to jj is evidence that hg should have won the DVCS war, but more importantly, that VCSes and their inherent merits and tradeoffs were always secondary to the social networks underpinning them. GitHub as a defacto monopoly really killed innovation in the VCS space, but also shifted the focus and attention elsewhere. That's why I don't think there'll be so much of a "post-git" w…

Does VCS-agnosticity actually work? It feels like a huge burden to migrate it everytime you want to have the tools from the innovation in your daily work. Also projects want to integrate project versions into each other and reference versions and identifiers are likely VCS specific. That's why I feel VCS monopolies actually has a lot of benefits.

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

#625

Earlier quoted context omitted.

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?

Technically, nothing. But psychologically git commits represent a unit of completed work, whereas with AI agents what's needed is a kind of agent-wise undo history such that you can revert back to the state of the repo 1 minute ago before Claude did an oopsie all over your repo. You can definitely use git as a backend for building such a system, but some extra tooling is necessary.

git checkout @{1.minute.ago}

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

#627
post #203

Earlier quoted context omitted.

Guessing you aren’t working with hundreds of collaborators in a distributed offline system. Which is what git was for and why svn wasn’t enough for that type of use case.

or using branches.

for me atomic commit or was that committing a bunch of files with 1 command was important. and cvs wouldnt let me do it. perforce did. but it was proprietary software, though i think they offered a free version for solo developers or something like that. and when svn came out i jumped ship.

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

#628

Earlier quoted context omitted.

What does that even mean? Multiple branches is a git feature.

I think it means parallel branches. Normally in git you can use one branch at a time. With agentic coding you want agents to build multiple features at the same time, each in a separate branch

Does it checkout different branches at the same time, provides an in memory representation to be modified by another API, or does it to multitasking checkouts. The first thing is already natively in Git. I guess the others are innovation, although the second sounds unnecessary and the third like comedy.

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

#629

Earlier quoted context omitted.

Sooooo git worktree. It's exactly that. One repository dir checked out in different places with different branches.

Not quite, Gitbutler allows you to apply multiple branches to the code base at once. With codebases you will have multiple code bases not one. for example: It allows me to test coworkers branches with mine without merging or creating new branch. It has many features that makes it super easy to add patch to any commit in any branch

> for example: It allows me to test coworkers branches with mine without merging or creating new branch.

How is that not supported by worktrees? You are aware, that you can checkout commits?

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

#630

Earlier quoted context omitted.

> especially for dealing with rebase/merge conflicts where I would say Git is mediocre. It seems like everyone that hold this opinion want Git to be some magical tool that will guess their intent and automatically resolve the conflict. The only solutions other than surfacing the conflict are locking (transactions) or using some consensus algorithm (maybe powered by logical clocks). The first sucks and no one has been…

> It seems like everyone that hold this opinion want Git to be some magical tool that will guess their intent and automatically resolve the conflict. Absolutely not. There are plenty of fairly trivial solutions where Git's default merge algorithm gives you horrible diffs. Even for cases as simple as adding a function to a file it will get confused and put closing brackets in different parts of the diff. Nobody is ask…

> where Git's *default* merge algorithm gives you horrible diffs

You are saying it yourself.

Post reply on HN