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.

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 the repository? Well, you might want to throw that entire repository away and restore it from a backup before the offending commit because it's so difficult to fix and guarantee that it's not hiding in there somewhere and while also not breaking something else.

It's also taken over 10 years to address the SHA-1 limitation, and it's still not complete. It's a little astonishing that it was written so focused on SHA-1 never being a problem that it's taken this long to keep the same basic design and just allow a different hashing algorithm.

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

That sounds exactly like the pre-git model that git solved..

think about all of the discussion we have around the code that gets lost. we certainly have the ability to keep and link all that stuff now. we don't really need to have arguments about squashing or not, we can just keep the fine grained commits if you really want to dig into them and maybe ask that people write a comprehensive summary of the changes in a patch set -in addition-.

but I guess none of that has anythig to do with AI

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

I've not used this app, but I wonder how tooling like this truly competes against an open source community armed with AI. Like where is the moat here, really? I built a personal tool that does some of this with a basic Claude subscription over the course of a few weeks.

Feels like vibe-coders are the real target market for something like this, but if it takes off, would not be that hard to clone as a FOSS app.

I think this is a potentially giant market: incurious people who don't know what they're doing, lack experience and wisdom, and are highly susceptible to empty marketing fluff. Selling junk to these people can't be very difficult, especially if they rely on an LLM (funded by many of the same investors) to explain it to them.

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

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 as when SVN was beaten out.

but since then, so many people have gotten used to the basic model that git offers (even if they still have issues with details of the syntax).

to gain a foothold in this environment is a monumental task, and anything that wasn't unambiguously libre and probably gratis too has little hope.

1 - https://openai.com/index/openai-to-acquire-astral/

Also, uv is open source, and can be forked if the company behind it decides to close it (see Terraform → OpenTofu, etc).

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

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.

I'm not famous though, I'm just a good engineer who is patient, inquisitive, and determined enough to spend the last five years of my life on nothing but this.

My question is: say the investor believes that some new platform will win out over Github. How do I make the case that it will be mine over a famous person's?

Note that if you want to be the answer, then you have to prioritize other things than the technology. You can have the best product, but if nobody knows about it you're stuck.

The nature of developing standards is that you can't have people start adopting them until they're done.

Github itself basically followed this route. They didn't built Git on top of SVN. They built a much better product (than Sourceforge) and they used network effects (particularly their free-for-OSS offer) to grow their userbase until they could start to land corporate contracts.

I don't know if they were the first git forge, but they were certainly among the first.

The specific problem is that all the competitors to Github have to use git, and that limits how different they can really be than Github and thus how aggressively they can compete to win users

I badly want someone to take that deep dive given the work I've put in to be ready for it

It's pretty easy to find out who I am in the real world too. For one thing I'm a private pilot and for 10 years I had an airplane personally registered to me, making my name and address a matter of (open) public record.

But fundraising is a game to be played, and part of playing the game is building credibility with VCs. It may be that a quirky name helps with that, but probably not.

From the classic baseball movie Bull Durham, where the old veteran is explaining to the newbie how to be successful:

"Your shower shoes have fungus on them. You'll never make it to the bigs with fungus on your shower shoes. Think classy, you'll be classy. If you win 20 in the show, you can let the fungus grow back and the press'll think you're colorful. Until you win 20 in the show, however, it means you are a slob."

If you already have a track record, then you can have a quirky name or personality. Until then, you've got to play the game.

This sounds like one of those "Hacker News Dropbox" comments...

Have you built a prototype and tried to pitch any VCs? Or are you just asking rhetorical questions?

It's a pretty serious claim to know what comes after git, and I have a whole array of criteria I evaluate claimants on:

- Will their version control solution fall apart if there are not enough line breaks in the code?

- Can they solve the rename-function/add-usage conflict? Git normally can't surface this conflict at all.

- Can the system maintain authorship attribution at a fine-grained level (per-second resolution)

- Will their solution's performance break down if there is too much code in one file?

- How will the solution handle change notifications? Is the filesystem watcher the de-facto coordinator?

This GitButler thing fails all my tests for a thing that's serious about replacing git; it just seems like they haven't thought about any of that stuff, well, at all.

The reality is that you can make a successful business with okay engineering and great product insight. It's much more difficult to build a successful business with great engineering and poor product insight. Getting people to use and pay for what you've built gives you the product insight that you need.

If yes, and you’ve solved them, people should be very interested in using what you’ve built. If people are using what you’ve built and are willing to pay for it, VCs will be interested.

If you haven’t solved them, but can validate they are real problems people care about, and have a path towards solving them, this should make a compelling VC pitch.

If they are real engineering problems but no one seems to care much about them, then it’s just a hobby.

The problem they have is that they're betting git is a solid foundation to build on. A tectonic change like git actually being replaced wouldn't just eliminate their moat, it would leave them trapped on the wrong side of it.

I can't win their game, so I'm changing the game.

[1] - https://news.ycombinator.com/item?id=47713650

One of the most idiotic things about the whole LLM craze is the idea that we have to change all of our infrastructure to accommodate LLMs instead of figuring out how to train LLMs to make better commits.

Other commenters mentioned worktrees, which let you check out different branches at the same time from a single local repo. That's convenient, but not required.

Git always supported "fast cloning" local repos as well. You just "git clone" from one directory to another. Then they are independent and you're free to decide what to merge back.

These days, agents can also fork their containers or VMs as often as required too, with copy-on-write for speed.

So that's four ways to work on multiple branches in parallel using Git that we already use.

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.

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.

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

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.

While I hate to engage in speculation, tell spooky stories, or screech at people about the evil CLA you have to sign in order to contribute, my personal opinion is that if Google were ever to start throwing their weight around, the project would be forked in short order and development would continue as normal – it has momentum, plenty of non-Google contributors, and a community. It's also not a product per se, though as we're about to find out, you can certainly build products on top of it – that probably makes it less likely for its current home to suddenly become proprietorial about it.

(hi Andy!)

There's some legal annoyances around e.g. CLA which was a result of being a side project of Google originally. Hopefully we'll move through that in due time. But realistically it's a much larger project at this point and has grown up a lot, it's not Martin's side project anymore.

  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "if command -v jj >/dev/null && jj root >/dev/null 2>&1; then if ! jj status >/dev/null 2>&1; then echo 'WARNING: failed to snapshot jj repository, tell user to fix'; fi; fi"
          }
        ]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "if command -v jj >/dev/null && jj root >/dev/null 2>&1; then if ! jj status >/dev/null 2>&1; then echo 'WARNING: failed to snapshot jj repository, tell user to fix'; fi; fi"
          }
        ]
      },

I have all of them run `jj status`, because jj snapshots the working copy every time it's invoked.

You can have Claude write the hooks, but mine is:

`[[ -d .jj ]] && jj status >/dev/null 2>&1; exit 0`

[1] https://code.claude.com/docs/en/agent-sdk/hooks

You could also turn on watchman and have this property on every save of a file and not even need to worry about hooks.

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 <change id I found in 3>

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.

You can definitely use git as a backend for building such a system, but some extra tooling is necessary.

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

Is it? There’s the stash for storing patches, the index for storing good hunks, branching for trying out different experiments. You can even use worktree if you want separate working directory especially when there will be changes in the untracked files.

Git has a lot of tooling for dealing with changes, directly or at the meta layer.

When I'm using agents to code, I don't want to have to stop what I'm doing and commit known-good state to the repo every few minutes.

jj just snapshots everything automatically, so I know I've captured that state, and I can look back and curate it all after the fact.

It's like the shift from manually saving Word documents to autosave, but instead of forcing it with git, I can use JJ which has been intentionally designed for that workflow.

Jujutsu has changed how I work with git. Switching tasks is just "jj edit <change>" or "JJ new <change>". The only thing it can't do properly is git worktrees (it doesn't replicate the .git dir to the worktrees, breaking tooling that relies on git) but there is a (old) issue relating to it. Not sure on the priority, though.

Anyway, YMMV, but I love it.

I will admit, I didn't know jj but I wanted snapshots so I used it, so then when AI made some changes and kept on going and I wanted to go back to a particular change and I used ai to do that. It was actually really frustrating. To the point that I think I accidentally lost one of the good files within the project and I had to settle on good-enough which I had to try to get for hours to that particular point.

My point feels like I should either learn jj properly to use it or to at this point, just ask AI agents to git commit. Another point but I was using ghostty and I had accidentally clicked on the title bar and somehow moved the folder to desktop, I wasn't thinking the most accurately and I just decided to delete it thinking that it must have copied it rather than moved it. (Also dear ghostty why do you make it so easy to move folders, it isn't the best of features and can lead to some honest errors)

My face when I realized that I have deleted the project:

Anyhow decided to restore it with ~/Trash but afterwards realized that the .git/.jj history is removed because it deletes hidden folders (from my understanding) so I definitely lost that good snapshot. I do have the binary of the app which worked good but not the source code of it which is a bit frustrating

These were all just an idea of prototyping/checking how far I can move things with AI. Yeah so my experience for that project has been that I could've even learnt a new language (Odin) and the raylib project to fix that one specific bug in lower time than AI which simply is unable to fix the bug without blowing the whole project in foot.

I think the takeaway is to have good backups man. I mean I was being reckless in this project because I had nothing to lose and was just experimenting but there have been cases where people have lost databases in prod. So even backups should be essential if you find any source code which is good to be honest.

I am sure you guys must have lost some source code accidentally which you have worked upon, would love to hear some horror stories to hopefully know that I haven't been the only one who has done some mistake and to also learn something new from these stories. (I am atleast happy in the sense that I learnt the lesson from just an tinkering thing and not something truly prod)

* 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's not difficult to "escape" - using `git checkout` will tear everything down properly - that's the only task of the `post-checkout` - to determine that you want to go back to using vanilla git commit tooling and remove our shims.

We also don't have a prepare-commit-msg hook - our commit tooling will inject an extra Change-Id header (of the same format and interchangeable with Jujutsu) but that affects nothing that vanilla git cares about.

  ⎿  Error: Exit code 1

     GITBUTLER_ERROR: Cannot commit directly to gitbutler/workspace branch.

     GitButler manages commits on this branch. Please use GitButler to commit your changes:
       - Use the GitButler app to create commits
       - Or run 'but commit' from the command line

     If you want to exit GitButler mode and use normal git:
       - Run 'but teardown' to switch to a regular branch
     … +5 lines (ctrl+o to see all)

I still haven't uninstalled the app and will try to figure out the working model.

Also please offer some skill file or a text I can add to my CLAUDE.md / AGENTS.md so that when I ask claude to commit , it will go through gitbutler...( edit: looks like it is there, but the discovery is hard ) .

For the Claude question, the CLI ships a skill, set it up with `but skill install`.

I hope this helps

And I saw these malicious (pre-commit) git hooks installed by GitButler, without any confirmation, or prompt seeking my approval.

I'm sure you folks will come up with a "technical explanation" or some "legal-marketing language" to cover up for this — but in my book — redirect `git commit` to `but commit` is dishonest and unethical.

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.

Can’t believe how this whole AI movement seems to want to reinvent software engineering, poorly.

Which should be basic skill on anyone dealing with code, but Git is not just programmer's tool any more for a long time so better UI is welcome

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

- One local copy of a repo with multiple work trees checked out at once, on different branches/commits? Git does that.

- "Add a patch to any commit in any branch" I can't think of a way of interpreting this statement (and I can think of a couple!) that isn't something git can do directly.

Maybe it adds some new UI to these, but those are just git features. Doesn't mean it's a bad product (I have no idea, and "just UI" can be a good product) but these seem to be built-in git features, not Gitbutler features.

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

  git worktree add -b feature-2 ../feature-2

They'll start injecting ads in your commit messages, forcing you to subscribe to a premium plan.

Surely $trillion "ai" thing can generate a better solution than one Finnish guy 20 years ago.

You can define your own merge strategy that uses a custom executable to fix conflicts.

https://stackoverflow.com/a/24965574/735926

16M$ VC money saved.

Does it work well for resolving merge conflicts in your experience?

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 able to design the second (code is an end result, not the process of solving a problem).

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 asking for perfection but if you think it can't be improved you lack imagination.

There are a number of projects to improve this like Mergiraf. Someone looked at fixing the "sliders" problem 10 years ago but sadly it didn't seem to go anywhere, probably because there are too many core Git developers who have the same attitude as you.

https://github.com/mhagger/diff-slider-tools

You are saying it yourself.

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

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?

"Why fund $17M towards development of an operating system, when Linux was made by one guy with a chip on his shoulder?"

Also, you should hear Linus talk about building git himself, what he built wasn't what you know as git today. It didn't even have the commands like git pull, git commit etc until he handed development over.

To build better tool than git, probably a few months by tiny team of good developers. Just thinking of problem and making what is needed... So either free time or few hundred thousand at max.

On other hand to replace GitHub. Endless millions will be spend... For some sort of probable gains? It might even make money in long run... But goal is probably to flip it.

His main contributions were his ideas.

1) The distributed model, that doesn’t need to dial the internet.

2) The core data structures. For instance, how git stores snapshots for files changes in a commit. Other tools used diff approaches which made rewinding, branch switching, and diffing super slow.

Those two ideas are important and influenced git deeply, but he didn’t code the thing, and definitely not in 7 days!

https://graphite.com/blog/bitkeeper-linux-story-of-git-creat...

You may find this 10-year-old thread on HN enlightening, too: https://news.ycombinator.com/item?id=11667494

Git is decades old. Of course, there are tons of contributions after the first 10 days. Everyone knows that.

He started it and built the first working version.

On the ninth he roasted some fool.

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

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?

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.

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.

Keep an eye on our blog to see how we're doing this, and how we're doing it in a way that hopefully the entire community joins us in a way where we're not all reinventing the same wheels.

but if not just your own work flow, have a dir dedicated to storing prompt history and then each file is titled with the commit id.

As for the flag just agree to some convention and toss it in the commit message

Yes, it could have syntax like

    git notes add -m "Claude prompt: foo fee faa foo" <commit-hash>

OH WAIT YOU CAN DO THAT ALREADY SINCE 2009

Seriously, the 90% complaints about git not being able to do something is just either RTFM or "well, it can, but could use some better porcelain to present to user"

Only useful if it can be reliably verified, which is challenging at best.

The point of git is that it has strong authentication built into the fabric of the thing.

I mean, it's just text, so it shouldn't be too taxing to store it. I agree it's hoarder mentality though :)

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

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

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.

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

If it's to enable multi-agent scenarios, don't worktrees (at least in the local sense) allow for this?

Worktrees are multiple workspaces, each in their own directory, sharing a single git repo. This is helpful because you reduce the overhead and the CLI command juggling for fully separate clones.

I have no idea what approach is better for your multi-agent scenario.

1) because they can

2) it's their money, not company money, and again, why would you risk your own money when someone else wants to risk their money?

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.

Are you interested in giving https://tangled.org a try? I'd love to hear your thoughts!

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.

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.

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.

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.

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.

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.

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

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

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.

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

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

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, everything in the dev workflow is changing - it's an interesting problem to think about what a _great_ toolset for how we'll all soon be developing software will be.

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.

I would love to debate all of the lessons learned about the history of Git, but I was around for all of that. I know why Git was started, I know what it was meant to do, I understand how it's evolved. I still think there are a lot of interesting things that we could have in our change control tooling and Git is not the perfect solution.

Nearly everyone in this thread suffers from the same basic local maxima blindness that you do. Git is great, GitHub made it more valuable. But maybe the answer to the papercuts we've constantly been dealing with for decades isn't faster horses. (To, you know, mix metaphors)

I watched a bit of the gitbutler video and I liked the ideas, multiple/stacked branches. It felt like a genuine/natural extension of git concepts.

Sortof like Typescript vs JavaScript, I worry that the payoff of adopting something like Gitbutler would require navigating a lot of janky integrations with the rest of my tooling and training of the team.

I myself have always resisted mastering the git command line because JetBrains' git tooling is so nice, and abstracts just the right bits that I haven't had the need. I'm not opposed to switching to command line, but that 3-way git merge tool that JetBrains has is so good and I'd hate to lose it.

Honestly, I predict the world and its networks and developers are going to start cloistering and close themselves off as the AI training panopticon is getting nasty.

It would be great for Gitbutler to abstract true decentralized version control by offering decentralized/self-hosted feature parity with GitHub and remove vendors like them from the picture. I'd pay recurring seat licenses for something turnkey that I could run privately and securely.

You use git at a level beyond mine; I've been fumbling with it for maybe 2/3 of the time you've been actually using it, so I appreciate you even taking the time to respond.

I think what gets me is that according to the article, GitButler is designed "for the GitHub Flow style" of development. git isn't limited to one flow, why should its successor be? Git didn't need $17M funding (and the strings that come attached to that) to change the world. Why should its successor?

But yeah I should've had that coffee first, so thanks for the respectful push-back and I hope the rest of the community appreciates it.

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

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

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.

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.

Wealthy people don't have time to do all due diligence and vetting specially when random startups become unicorn.

git ≠ GitHub

Not sure what the business logic is. Maybe they are mostly acquihire. Or the companies just have so much money to throw around they just spray it everywhere. Whatever the reason, if the tools remain open source, the result for devs is probably better open source tools. At least until enshittification begins when the companies run out of funding, but hopefully the tools remain forkable.

Does AI make reading or writing stacked PRs any nicer? No, it does not.

Correct, hence the "SaaSpocalypse" phenomenon in recent weeks. Investors are slowly becoming disinterested in investing in software anymore precisely because models are good enough now to replicate any SaaS pretty easily, which still requires effort but is less so than paying for a SaaS particularly in large organizations which are charged per seat.

Maybe if I were reviewing some random dude's code, where I have no idea what he's been working on...

The whole concept of PR is that you want additional looks on the code, and multiple agents working adversarially on PRs with philosophical rules are really nice.

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.

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?)

4. GitButler is a terrible name for this

5. No one will use the "but" command over "git"

6. The founder needs to learn to enunciate the name of his new product better

And also, your central premise is exactly right. The solution to agents and humans working faster will not be better manual oversight of what they're doing. It's like missing the most important principle of agentic development. Supervise, don't gatekeep.

Pound foolish and folly

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.

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.

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.

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.

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.

Well, I think it won't

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

Also if they really wanted to “replace git” I think that would be much more difficult due to network effects. Everybody is already using git.

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

and git's reflog:

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

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

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

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?

With a box of scraps!

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.

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

What I'd would expect of the next vcs is to go beyond vcs of the files, but of the environment so works on my machine™ and configuring your git-hooks and CI becomes a thing of the past.

Do we need an LSP-like abstraction for environments and build systems instead of yet another definitive build system? IDK, my solution so far is sticking to nix, x86_64, and ignoring Windows and Mac, which is obviously not good enough for like 90%+ of devs.

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

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?

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.

When I discovered git, I couldn't go back to svn - git fit my mind _so_ much better.

It might not have seen the meteoric rise without GitHub, but just like it's weird to find servers running an OS other than Linux these years, I suspect there would have been a steady growth that eventually made it dominant.

I suspect it will be very hard to unseat git at this point - for all its untuitive UI it's good enough for most things, and it's been slowly improving for the use cases where it's weak.

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

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

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.

Yeah, that is also my take. I'm biased of course since I'm someone working on replacing git through grassroots iteration, but I've been around this block a few times though and I never saw blasting money at a problem produce real innovation.

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.

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.

It’s 17m for a tool which hopes to serve companies and charge money and make more than 17m in profit as a result.

If you look at the set of dev tooling, teams will frequently pay many hundreds per dev on things like CI, Git tools, code review, etc.

And to be fair, GitHub is really quite bad for a lot of workflows. I haven’t used gitbutler, but my team pays ~$30 a month per dev for tools which literally just provide a nicer interface for stacking PRs, because it saves us WAY more than that in time.

This isn’t even an egregious example of VC, it’s just an enterprise dev tooling bet.

Great use of 17 million dollars.

Use value != sales value; hype sells.

Ps. not too sure how far $17M gets you toward mini nuclear power plants, but I catch your drift.

What’s the problem?

Do you think less money should be going into VC?

Just some numbers ~1.5M housing units are built in the US with an approx cost of $300k - $400k. That is $450B to $600B going into housing units construction every year.

On the other hand VC has maybe $1T AUM in the US. Maybe 10%-20% of that is deployed every year? So $100b to $200B.

What is wrong with that ratio? Could there be better solutions to make more housing cheaper? (lower regulations, efficient permitting, etc)

Money moving from VC to housing seems without a first principled approach on what problem your solving and how is silly.

Apple, Microsoft, Google, Amazon all were founded years or decades before Git was created and money had a different value back then. (Inflation)

For every unicorn there are tens of thousands or even hundreds of thousands dead horses...

Nicely put!

So thanks, I take this compliment. You just made my day!

There's gobs of amazing technology being built by people who just love to build, have great ideas, and huge talent (now exponentially compounded by LLM assistance, even) -- and 99% of it is ignored by people with $$ and none of them will be paid to work on these things -- let alone get funded to build a business around them -- and the reason isn't the inadequacy of the technology or "lack of a workable business plan": it's lack of social connections or pedigree.

And what this tells me is two things

1. there's a fundamentally sickness to the VC culture coming out of Silicon Valley and it's gotten worse not better with the new restraints in the post-ZIRP era. It's an echo chamber and a social circle, not a means for creating new profitable companies or good infrastructure, and it serves mainly just to feed a pipeline of acquisitions into much bigger fish rather than building tomorrow's new businesses or ideas. This is very different from 80s, 90s tech culture that I grew up in.

2. there's clearly a desperate need for more actual incubators or labs for actual technology, paying people to build "good stuff" independent of the vagaries of what VCs and their ivy league friends are able to pitch.

Frankly: The $$ out there in heavy circulation has been mostly corrosive, not helpful.

But the taxes remain very high, especially on income so it hits middle-class professionals the hardest. In some countries like Spain (and increasingly Sweden) they are contributing to a high structural unemployment, especially youth unemployment, too.

So in the end, the problem isn't just higher taxes, but higher unemployment and therefore lower gross salaries (before those higher taxes are even taken into account).

I'm paying maximum social security and in previous generations the service you got in the public healthcare system was way better.

For some procedures I definitely go to private doctors as well nowadays. It's not a huge burden, but e.g. I will never go to a public skin doctor ever. The stories you hear about them are... brrr!

But overall the system is still miles ahead of the one in the United States. I've been there on multiple occasions and witnessed first hand, I have friends there and I know both systems. (Obviously I know the European system or rather the one in my country of residence even better)

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?

It reminds me how the Bohemian Club’s slogan, “Weaving Spiders Come Not Here” is a bit farcical given that it is impossible for the club members not to engage in commerce.

While that's completely true, I do think it misses a key underlying point: VCs (and many breeds of investor) are not ultimately selecting for value creating ideas, or for their friends: they're selecting for investments they believe _other people_ will pay more for later.

In the case of startups, those people are most likely other VCs (at later rounds), private equity (at private sale) or retail investors (at IPO).

Very rarely is the actual company profitable at any of those stages, demonstrably and famously.

So the whole process is selecting for hype-potential, which itself is somewhat correlated to the usual things people get annoyed about with startup cliches: founders who went to MIT; founders who are charismatic; founders who are friends with VCs; etc...

So yeah, they invest in their friends, but not because they're their friends. Because they know they can more reliably exit those investments at a higher value.

[0] https://hn.algolia.com/?q=gitbutler

This is also true for how HFT guys make money. It's not that they are very good in investments. The Fed injects money constantly from the top which gets distributed or trickle down to such firms. Because in a tight economy which is not akin to gambling, it should be near to impossible to make money so easily.

Good ideas are a decent subset, but you could also have a bit of "Greater Fool Theory" compliant ideas.

> Money is not given to good ideas (though, it doesn’t hurt). Money is given to friends.

I have an obvious counter example. I'm sure money is invested for all sorts of reasons to all sorts of people. I'm also sure that money is not exclusively invested based on friendships, and I'm quite sure that money is at times invested based on the merits of an idea. Obviously those merits have to correspond to the ability to form the basis of a successful company, unless it's a philanthropic investment.

The clearest of these is that you have already built it, or an MVP of it that is more than just smoke and mirrors, and there’s users and customers.

If you have excellent proof points and actual revenue growth, you could show up with no pants smelling like weed and somebody might fund you. Then they’d call their press people to do an “eccentric genius founder” piece about the person who showed up stoned with no pants and their pitch was that good. That’s cause if your graph goes up and to the right you’re not crazy, you’re “eccentric.”

If you don’t have any proof they fall back on secondary evidence, like credentials and schools and vibes. The latter, yes, often overlaps with cronies.

And unfortunately that by necessity includes most ideas that cost a lot to prototype, which means credentialism and croneyism tends to gate keep fields with a high cost of entry.

Do you need a working product to get funding? No. But you do need a compelling investment thesis - which takes months and even years of deep thought to come to fruition. Of course you can shortcut this process by smooching but only a select few can pull that off.

Money is given to ideas that might become billion dollar businesses and teams that look like they can do it. Pedigree, domain expertise, previous exits.

Team matters. What other proxies are there?

Lately, for founders, to which prison they went.

Then, we will develop (read: sell) AI agents that will ingest a proposed code change (created by your front-line agent), and iteratively refactor it until the commit agent accepts it.

That's the Platinum Premier tier. If you're on the regular tier, paying the minimum, the AI will silently fix all that right up for you.

You never sort by color, ever! You sort by form, and then throw every color of that specific form in one bin. If you throw every red brick in the same bin, you'll never find a specific formed red brick because to many red bricks. But if you first search by form and then by color, you are much faster.

Index the many valued column, not the column with few discrete values.

https://youtube.com/@disturbingthepiecepod

Anyone have a solution for another annoying problem: 1 missing piece.

Somehow got lost halfway through the build.

Also, Lego will send you any missing pieces for free.

there are to many types of bricks to sort by form. unless you have an inventory the size of a brick factory you can only sort by category or by size.

otherwise, sorting by color makes your collection aesthetically pleasing, and when you build, you usually want to use specific colors only to make your model look good.

And then if you like to sort further you sort out the smallest of each bin because those always fall to the bottom when mixed together

Because solving problems isn’t the goal, the goal is money (and sometimes a little fame) with the least possible effort, and software can be changed on a whim and is very cheap to manufacture and distribute and “fix in flight”, it’s the perfect vehicle for those who are impatient and don’t really care about understanding and studying a need.

sometimes it's just wait until your kid grows up and learns to put the LEGO away

there's a lot of people working on hard problems that are pretty far from software

being cynical about early stage software (and any company that is overpromising like Theranos, Nikola, etc..) is warranted, but also money as a reward motivates a lot of innovation (PV panels, batteries, EUV lithography)

the founder does not want to risk money for his own idea

while

funders have simultaneously also too much money while believing they don't have enough.

That very simple dynamic is what is driving investment in the Silicon Valley, itself praised worldwide as the forefront.

That's what bringing our own civilization on the economical (AI bubble), ecological (AI bubble, car brain) and democratic (surveillance capitalism, privacy zuckering) cliff.

People complaining about investors throwing stupid sums of money at stupid or trivial things unrelated (or only marginally related) to AI? ...sounds to me like the first glimpse of hope I have come across in this industry for half a decade.

> Today, with Git, we're all teaching swarms of agents to use a tool built for sending patches over mailing lists. That's far from what is needed today.

[0] https://pickupbricks.com

[1] https://www.youtube.com/watch?v=X25MIpQqLIU

This video is from 8 years ago:

https://youtu.be/wXxrmussq4E?si=bgDdDvZODVov3sSC&t=15

I'm sure, by now we could make them for <$1k per robot, if we wanted to.

EDIT: BTW did you see that the page you linked to has this at the bottom of their landing page:

"Example product"

"This area is used to describe your product’s details. Tell customers about the look, feel, and style of your product. Add details on color, materials used, sizing, and where it was made."

so I wonder if they actually sell anything.

https://us.roborock.com/pages/roborock-saros-z70

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

I'm not seeing it. When I search for "example" nothing comes up, but maybe I'm looking wrong.

I see it on Amazon as well, with reviews and videos from "customers", so I assume it's not vaporware and that is more an issue with people not filling out the full website template, which is also not a great sign.

https://www.amazon.com/Pick-Up-Bricks-Compatible-Accessories...

The world doesn’t need this. It would just be more plastic and electronic trash.

You and your kids have hands. Pick them up. It’s what we do in my house.

If you don’t have hands, use your feet.

Perhaps you should have. Based on the link it seems like it's more an extension to than replacement for Git.

The page is mostly sort of fluffy AI hype, but the concrete bits are things like integrating issue tracking and PR logic in one tool/repo, like e.g. fossil does.

Also git proper could use some love too. The UI is still a mess. And the large file support and the submodule/subtree/subrepo situations are quite dismal.

> $17M, one could probably build a vacuum robot prototype that’ll also clean up all of the kids toys and sort LEGO bricks by colour and size.

Doing this robustly is probably quite far from robotics SOTA.

Neither of them is doing to be remotely prepared for what I'm going to do, which is actually replace Git.

That said, if you ever decide solve the tidying the toys problem, start a kickstarter, I pledge to pledge support! :D

I do wonder, though, if it would have been designed differently if the whole “code forge” sort of application (or whatever GitHub and the like are called) was envisioned at the time. Pull requests aren’t even a concept in git proper, right?

It seems like a kind of important type of tool. Even though git is awesome, we don’t need a monoculture.

    git request-pull

Generates a pretty email requesting someone to pull commits from your online repository. It's really meant for Linus to pull a whole bunch of already-reviewed changes from a maintainer's integration branch.

The rough equivalent to GitHub's "pull request" is the "patch series", produced by:

    git format-patch

Which lets you provide a "cover letter" (PR description), and formats each commit as a diff that can be quoted inline in an email reply for code review.

Interesting that DAG model means any branch from anywhere can be merged... the forge is just coordination.

Explored here if curious - https://vectree.io/c/git-graph-theory-logic

I would argue that it was purposefully designed in contrast against that model.

GitHub is full of git anti patterns.

GitHub is a social networking site that just so happens to have code hosting related features.

It's as much a social network/collaboration tool as it is place to store your code these days.

But it took a big brain with a systemic view of the problem and solutions space to bring them all together - in a lighting fast implementation to boot.

1. it was free;

2. it was sponsored by the most fashionable project of the time (Linux);

3. it did not require a server;

4. because it was FOSS, people could extend it without asking anyone's permission; and...

5. ...once GitHub appeared, simplifying the PR process, the network effect did its thing.

Git was hard to use and to understand. It did not win on technical features alone, as you said there were plenty of alternatives. It won because of community and network effects.

So is ffmpeg and ImageMagick. Or Blender. Or Freecad. There are domains that do require some learning and training to properly use the available tool.

Edit: see "git request-pull" as mentioned below (file:///C:/Program%20Files/Git/mingw64/share/doc/git-doc/git-request-pull.html) but what it does is write "a pretty email" (the other poster's words) to STDOUT.

What? Is the intention, that I access your C: drive? Also is it common to have a file:// link on MS Windows? I thought this was a unix thing.

So the maintainer adds you as a remote and pulls from you.

And what's the next step? I can't even imagine how rich (and how large the their houses) the parents need to be for them to comfortably buy such dedicated tool. Perhaps 100x~1000x richer than me?

And, while this is just pulled out from my rear side, I feel even getting this passed safety regulation would cost your $17M. It's a fully automated machine working next to toddlers!

On the contrary Github is a proven product.

I think if you have a healthy busy growing well, you shouldnt raise unless you have ambition and urge to go faster.

Irony of thr market is, just like tinder 20% of the companies attract all the attention rest of them try to gran the attention. Those who need capital get the capital, those who need the capital die trying.

Enough friday pessimisim.

My previous employer was like this. A 20yo company with a nice always increasing ytoy growth. The CEO told for 20 years that he would never raise any money. It was an incredible place to work : nice compensation, product and consumer centered, we had time and means to do the right things.

Until the CEO changed his mind and raised money anyway. But we didn't have to fear anything because those investors were very different and not like the other greedy ones.

Well I'm not working there anymore for a hella lot of reasons that are just the same as everywhere else.

But at least the CEO who was already rich is now incredibly rich.

If you find a greedy VC then most likely they are real VC and often gets attracted when your business is not doing great.

Reputation travels in this industry therefore people care.

Founders are only one stakeholder. There are employees ( I think they fall into that category ), customers, suppliers, and the wider society.

It all comes back to why does the company exist - and for which stakeholders. I think that's the point the original author is making.

I don't buy the argument that making money in the end is a perfect surrogate for overall good - it's not - it's an imperfect surrogate - and to pretend it is a perfect surrogate is just an excuse to behave like an arsehole.

To make that concrete, let's say you are a chemical company making paints - really important job, paints are needed the cheaper you can make them, the more people can have them etc, but if you knowingly pollute a local river just because you can get away with it and increase your profits - saying that increased profits justifies polluting the river based on the assumption that river pollution is correctly priced ( free ) is an obvious convenient excuse to be a selfish arsehole.

What you are mixing is founder led business vs ceo led business. CEO often takes a short term view, when stakeholders are PE Firm, wall street, short term gains are prioritized. But for, a long term investor, would not incentivize you to take calls that would harm in long run.

What could be wrong is that, you wouldnt know all the consequences and causality of your decisions and thats very human thing in my opinion.

I wish the companies understood the tremendous cost to society of polluting our well of knowledge.

But no, as your mention it is free for them to pollute, so they do liberally

However you are right to point out there is a problem. Typically societies ( via governments ) try and fix by appropriately pricing the behaviours via regulation/laws ( fines or prison for the people doing it ).

However making regulation/laws is hard. What's your proposal to fix the problem you've identified?

You might hit a moment where a lot of people whose only purpose in life is using Claude Code, um, well, starve. But yeah, nature is metal like that.

This is why VC is a cancer on society. If you don't have a healthy business growing well, your business shouldn't get bigger.

This is the reason why I don't wish for VC investments if I do something preferably.

Also I feel like your comment is highly accurate, I feel like this narrative though can sometimes be the only thing that matters, something like a vibes based economy.

I don't like this so much because some idea's technical prowess is taken at the back seat while its the marketing which ends up mattering, like many other things, it feels like that tends towards something akin to influencer level marketing and its something that I sometimes personally dislike.

To be honest, the reason why I am seeing YC investments especially from say people my age 18-19, is that, it is becoming a point of flex for them and just a capitalization of hype that they might have. It really does feel like it to me that when we boil down people and interactions sometimes into how much money they have, we lead inevitably to societies like ours.

The network is something that I understand can be hard to make though. I do believe network plays a role and I do feel like I have bootstrapped my own network by just talking with people online and helping, but I do believe one issue in that, that particular network isn't my business market sadly, and I do feel unsure about how to network to them and so I would be curious if others face somewhat of an similar issue.

Flex often dont translate to value. I often say dont look at what others are doing, head down focus and execute. Raising capital is actually the starting point, i would say it is not an achievement.

I think anyone can network. You dont have to be sales person, you have the increase your probability to be in the right place at the right time.

I feel like, my issue which can be a more society based issue is that we are all at the end of the day too busy with ourselves which can be fine, but what this leads to is that even with my extended family, I have seen people treat just a slight but observable way differently to elder cousins, one who make money and who doesn't and I do believe that cousins who might not earn money in the moment already have stress but it piles it on them maybe just a bit more too.

So I think that most of the world just somehow tries to quantify a person with one dimensional quantity sometimes, and this is why we see people whose only metric is to reach that goal and I am starting to feel like, its not the technical rigor or passion which matters sometimes but basically something akin to influencer-style marketing (Cluely has basically become a skit channel which has hundreds of millions of dollars by a16z I think)

And I feel like what this influencer-style thing is leading to is that our society, as a whole and people who build things, are jumping on the latest trends even when not understanding them (Claw-code was essentially the peak point of this-all) and we are basically adopting all the things wrong with the influencer-style culture and things are getting even more alienated from reality.

Our Industry/World-in-general is having grift and I am not saying it never had grift but I am witnessing something similar to algorithmic form of rage-baits being created by some people for them to not be left behind and we as a society, are now lacking the ability to have discourse with nuance in many-times/places.

> you have the increase your probability to be in the right place at the right time.

I completely agree with you but I do sometimes wonder if I am on Hackernews or if it is the right place. I mean, I am here first and foremost because I like talking here but from that viewpoint you mention, I have sometimes wondered if I should use twitter but I refuse to use it pretty much for most things simply because I feel like I would be yet another part of this cycle of rage-bait and being sucked into it and I am not sure if it would be well worth it. I am not sure if twitter etc. are worth it and I feel like even with things like Youtube etc., in both of these it becomes a very number game with things like followers etc.

Atleast within Hackernews, you don't have the concept of followers, so at one hand it is great but on the other, I question from that perspective if HN is the right place and where do you find people for businesses. Linkedin perhaps?

So in essence, I think I would say that I am unsure about the probabilities and what definition of right means. I would love it if you can talk more about it and thanks for commenting that comment, I appreciate it and I wish you to have a nice day!

> So I’d like to stress that while it really came together in just about ten days or so (at which point I did my first kernel commit using git), it wasn’t like it was some kind of mad dash of coding. The actual amount of that early code is actually fairly small, it all depended on getting the basic ideas right. And that I had been mulling over for a while before the whole project started. I’d seen the problems others had. I’d seen what I wanted to avoid doing.

Just so that people know that creating software is not only coding.

My comment is unrelated on the point you are making about expenses.

I had a few interactions with VCs (both professional and personal), where I didn't care because I wasn't benefitting from them. One of them was "an expert in CRISPR and blockchain" (WTF?) and... well I didn't need much time to see that he did not understand what a "hash" was. He was mostly an expert at repeating stories he had been told about how he would make a ton of money with the latest bullshit he didn't understand.

The truth is, it's like trading. You diversify the investments and hope that the economy goes up (respectively that one of the startups you invested in gets profitable). The only thing a VC has to do is verify that they don't invest in a fraud, but even that is hard given that they never understand the technology enough to say it's worth it (they often invest in shiny bullshit).

Per Matt Levine, the optimum amount of fraud is non-zero. Tune your detector too loosely or too tightly and you'll miss out.

But for fraud that hasn't happened yet don't worry about it and hope nobody figures out how to do it.

To be fair, many times founders are extremely convinced about their idea, they don't necessarily consciously sell bullshit to the VCs.

It just feels like what matters is to be very good at convincing VCs, not at building something real. When you're so good at getting money, of course eventually something will work (because you will be able to hire competent people to do the job). And then you will be called a "visionary", and people will say "we need HIM as a CEO because nobody else would be able to hire tons of competent people to build stuff with billions of dollars" :-).

While I personally doubt that for $17M one could build such a vacuum robot prototype (for a vacuum cleaner company, investing this amount of money - if it worked - would be a rounding error), I will rather analyze the point that you raised:

It is a very common situation that the workflows of companies is deeply ingrained into some tool

- that they can't get rid of (be it Microsoft Excel (in insurance and finance), be it Git (in software development), ...)

- that is actually a bad fit for the workflow step (Git and Excel often are)

So, this is typical for the kind of problem that companies in sectors in which billions of $/€ are moved do have.

I am actually paid to develop some specialized software for some specialized industrial sector that solves a very specific problem.

So, in my experience the reason why nobody [is] solving actual problems (in the sense of your definition) anymore is simple:

- nobody is willing to pay big money for a solution,

- those entities who are willing to pay big money often fall for sycophantic scammers/consultants.

The first Roomba prototype from iRobot was two weeks and $10k in 1999 [1], and S. C. Johnson's funding was up to $2M [1]. The public estimate for total pre-launch program cost is $3M. [2]

In 2026 $, that's about $19k, $4M and $6M respectively.

[1] https://nymag.com/vindicated/2016/11/roombas-long-bumpy-path...

[2] https://dancingwithroomba.com/funding-tertill/

Also, I already built a robot arm, a robot car, and a custom camera in my free time. So I’m having a hard time imagining that a robot vacuum prototype wouldn’t be possible for me to build in a year, let alone with the team size that $1m in annual salaries buys.

https://www.bbc.com/news/articles/c1lr75lp239o

You can do it with 0-3 digits of license cost too.

There's no sane way the business overhead more than doubles things.

The problem is that the cost of replacing git isn't measured in money, it's measured in time.

It's one of the few programming projects that no amount of money can buy, and ironically getting more money often means having less time.

At the same time, you just can't scale up a company then decide to disruptively innovate on your core tech. You either put your nose to the grindstone or you let yourself play and explore but you can't do both at once.

"We've replaced due diligence with a DNA test."

"No mutts, no miracles. Three generations of wealth or GTFO."

"Your bloodline is fine. Don't fret the cap table."

"You forgot to attach the pitch deck, but we really like your family crest."

Not be tied to Microslop and migrated to Azure?

Because that’s too risky for investors.

Just write down how you'll spend the money to make that, what it'll eventually cost to produce, what the market size will be, and what the price will be, and if it's enough return you can easily convince someone to give you $17m to do it all.

Thought so until saw this. Man, he is the co-founder of Github and already seed-funded. How can someone refuse him? 17M is a small amount considering the valuation VS Code Agent wrappers are getting

We've strayed really far from where technical innovation began

Well, cofounding Github helps

Consider that many of the tech posts here are of the form, "i did X but with Z" as the poster hopes they will be recognized as some master of execution.

Why are we trying to replace git? What is the problem with git?

Missing socks (and containers or their lids) are still great unsolved problems in 2026. Solving this issue is like fusion, always 10 years away.

What GP wrote sounds like an absolute nightmare of tech debt and unmaintainable spaghetti code that nobody understands anymore to me.

But I guess for some people the increased speed outweighs all other concerns?

"I'm not sure. But at least we got here fast."

I thought the consensus what that vibe coding is a bad idea and you're supposed to review whatever is machine-generated, however "good enough" you believe it to be.

Nevertheless the joke is already dead. There's no reason not to explain.

They went over this, in the documentary titled "Idiocracy".

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

For example, instead of building a robot to pick up Lego bricks, say you’re building a platform for personal robotics, and it’ll cook you food, do your laundry, repair your fridge. It doesn’t matter if you have any idea how to do this, just say you need $50M and you’ll hire some robotics and vision guys to figure it out. The bigger and bolder the lie, the better.

https://www.amazon.co.uk/Toy-Storage-Organizer-Lego-Play/dp/...

Solving actual problems are hard, and even harder to get money for (see research). Most VC’s are in it for the returns only, not actually making a change, there are some exceptions but they are far and few apart.

It doesn't solve the picking-up-off-the-floor problem.

I just looked into this out of idle curiosity, after watching some guy build a LEGO sorting machine. (They work in a warehouse that sells used bricks for model builders.)

Interestingly, this is on the cusp of viability, but training the ML model would still be cost-prohibitive (for me). With $17M, it's within reach, but there's still the obvious mechanical hurdles: Kids don't disassemble their Lego, the conditions are "less than ideal", and even vibrating belts in a warehouse scenario have a lot of trouble keeping bricks separated for the camera to get a clear image.

Robot hands are nowhere near the point where they can reliably (or even unreliably!) take apart two arbitrary Lego bricks that are joined, let alone anything of even mild complexity. This is hard for most humans, and often requires the use of tools! See: https://www.lego.com/en-us/service/help-topics/article/lego-...

The machine vision part is... getting there! You could pull some clever tricks with modern hardware such as bright LED lights, multi-spectral or even hyper-spectral sensors, etc. The algorithms have improved a lot also. Early attempts could only recognise a few dozen distinct shapes, and the most recent models a few hundred, but they're about 2-3 years old, which means "stone ages".

A trick several Lego recognition model training runs used was to photo realistically render 3D models of bricks in random orientations and every possible color, which is far faster than manually labelling photos of real bricks.

These days you could use the NVIDIA Omniverse libraries to heavily accelerate and automate this.

I mean who tf gives some small team millions to put some Nvidia GPU into space and thinking we will have market disrupting GPU clusters in space in 10 years?!

There are so many low hanging fruits in IT Industry to just being solved.

Even just having something like well build, open smart home products whould have been disruptive years ago (until someone like ikea decides to enter that space).

So, even though Git seems to be ok (people who store large binary files or who run huge monorepos would probably disagree), maybe we can do better.

Altavista was kind of okeish for search, yet Google managed to figure out something that was (at that time) way better.

I came here to say precisely that. I was on svn before git was a thing, and I've never moved off it for any projects where I get to decide such things.

To a first approximation, one could say that distributed version control is a problem nobody ever had, and nobody ever intends to have. (GitHub is the world's centralized monorepo.)

Yet, distributed version control is the majority of the reason why git's mental model is so overcomplicated.

The distributed aspect is important because it let me separate how I’d like to control changes vs how it’s done in the canonical repo. I sync when I want to.

All you need is a camera pointing at the floor with image detection... when there's legos on the floor it triggers a video playing that explains how the kids need to pick up the legos. /s

Building UI and auxiliary features on top of Git is a crowded space, it’s not clear what compelling innovation they are bringing to the table.

Rather, the GP merely implied that some parents would love to have a robot to sort their kids legos, and that (ironically) even that unimportant "need" is more important than replacing git.

Kids face a lot of new problems these days. They also face some old one, like sorting their legos.

Then you step on a lego.

Who really wants cheap lego vacuums? Basement-dwellers who are getting yelled at by their mom? Not a good market.

If you need (D)VFS aka Distributed Versioned Filesystem, grab right tool. Or write one.

This is exacly way I wrote DOT (Distributed Object Tracker). Its pure DVFS repo manager, to handle binary blobs and that it.. Nothing more.

People complaining about GIT not working well w/ big data just handling GIT wrong. Linus said it from the begining, its NOT tool for such datasets. Just move along.

There are some things that need to come from a place of manic self-motivated genius. It's not something that you can buy with money. The money is really just there to help you shove a mediocre solution down everyone's throats (which is exactly what's going on here).

Then again, it is used for non-coding tasks, but any and all of it's UI problems are not from the method of storage (pretty much any modern VCS uses same "tree of linked snapshots of filesystem) so making one while still making it git compatible just with better ui (like Jujutsu) is very much possible