building the future of source control over the incumbent tech does not bring much excitement personally.
does not takeaway the interest and funding they are able to bring. raising money is not always a bad thing, if say, there will be a webapp to go alongside their approach to workflows.
> 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 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.
>Git was built because the commercial license of BitKeeper became unworkable for the Linux kernel community.
BitKeeper was free to linux kernel developers with a "but no reverse engineering" clause, but Tridgell went exploring of his own volition because he wanted to and kinda sorta violated that, so the license was cancelled by BitKeeper.
I'm not taking sides or upset about any part of this, I just wouldn't call that "becoming unworkable for the linux kernel community"; that would be like "the fence around your yard became unworkable for me in my desire to trespass on your property so I climbed over it"
what Tridgell discovered was pretty dumb and could be considered a distinct lack of a fence, but he connected to a socket and typed "help" and it dutifully printed out a bunch of undocumented useful commands.
Yep, something that is sadly becoming more and more common. People with solutions spending insane money trying to convince others that a problem exists.
Skill issue. It's the most popular VCS in the world by a huge margin, millions of devs use it every day just fine, countless forges have been built around it, and there's only one semi-compelling alternative frontend (jj). If you honestly find Git challenging, how are you coping with software engineering? Git is the easy part.
Millions of dev use it in the most rudimentary way, occasionally lose their stash, rm their local repo and start over, ask the office expert for help every time they need to figure out where-the-foxtrot that commit came from, don't even attempt to use reflog or bisect or interactive staging, etc.
> 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.
> 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.
Of course is not true - look into git filter branch. I had to use it once when a developer checked in a whole bunch of binaries and created a PR which ended being merged. I had to rewrite the history and delete the files from history - just deleting the files would not suffice because the file were in git history and we’re taking too m&ch space.
Perhaps proving the point here. That's not enough to eliminate the secret, the dangling commit will persist. Though this might be a nitpick, it's rather hard to get it from the remote without knowing the SHA.
> generate a new key
Is absolutely the right answer. If you pushed a key, you should treat it as already compromised and rotate it.
The interface can be independent of the implementation. Under the hood git does everything you need. If learning to use it at a low level isnt appealing, then you can put an interface on top which is more ergonomic.
> Did you ever accidentally commit something that contains a secret that can't be in the repository?
What do I need to do on top of a git force push, and some well documented remote reflog/gc cleanup, which I can’t find with a single search/LLM request? Are we there, where we don’t have enough developers who can do this without feeling it as a burden? Or are we there where this level of basic logic is not needed to implement anything production ready?
> What do I need to do on top of a git force push, and some well documented remote reflog/gc cleanup, which I can’t find with a single search/LLM request?
This is a self-defeating argument. You're essentially saying we shouldn't improve something because it can be done with a handful of commands (you already know btw) and prompting an LLM.
> Are we there, where we don’t have enough developers who can do this without feeling it as a burden?
The no true scotman.
> Or are we there where this level of basic logic is not needed to implement anything production ready?
Not sure how this fits in with the rest honestly.
It was never about whether it was possible. It was about how it's being done. Juniors (and even seniors) accidentally check in secrets. Arguing that there shouldn't be a simpler way to remove an enormous security flaw feels a bit disingenuous.
No, I’m saying that you can do this without replacing git. You can make it simpler even without replacing git. Aka you just did a strawman, if you are really into these. Also you answered to me in an authoritative way, when even according to you, you don’t understand my comment. You can figure out a logical fallacy name for this. And also of course a nice fallacy fallacy.
Btw, I’m also saying that who cannot find how it can be solved right now with git, those shouldn’t be allowed anywhere near a repo with write permission, no matter whether you use git or not. At least until now, this level of minimal logical skill was a requirement to be able to code. And btw regardless the tool, the flow will be the exact same: ask a search engine or ml model, and run those. The flow is like this for decades at this point. So those minimal logical skills will be needed anyway.
The problem mainly is that when they don’t even know that they shouldn’t push secrets. You won’t be able to help this either any tooling. At least not on git level.
I've always wanted a kind of broader and more integrated approach that isn't just about text diffs. the ability to link in substantial comments that would be displayed optionally and not piss off linear readers. links to design and reference documents. bugs and prs that were persistent and linked to the versioned code instead of being ephemeral.
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
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 that can build the universal infrastructure for AI and agentic coding.
I think I have just as good a shot at building what comes after git as their team does, and perhaps quite a lot better.
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?
I understand that money is at the root of the question. I don't see any problem with my strategy for making money, which is to win over all their users with a wildly better product.
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.
That is an empirical question answered by the market. The way you get your answer is to build it, get it in front of people, and see if they use it. Then you will know.
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.
Reach out to investors that you or your friends/family have an existing relationship with. If that's not an option your odds of being funded are slim. Consider going to Stanford or networking with them another way; the latter being much easier if you're already wealthy.
This might sound like a joke or overly cynical but I'm being totally serious. Merit and product quality are only very loosely correlated with funding success at this stage.
The vast majority of projects don't get VC funded and of the small number that do most have some sort of relationship or other in into the funding world.
This doesn't mean you can't get funded, but it's a huge longshot. If you already have an income and some savings consider bootstrapping the project yourself, at least until you have some traction in the market.
I appreciate the advice, but I'm a couple steps ahead of you. I spent 10 years mastering my trade (UI) working in San Francisco and Palo Alto and Menlo Park, and that's when I saved enough money to allow myself to work on this for the last 5 years.
And fortunately I don't need anyone's permission. It's just too late to stop the wave of change that's coming now. After 5 decades, the punchcard is finally going to be retired as the primitive at the heart of all programming.
It's been my username for 20 years and I'm not changing it to be more corpo-propriate now. I think it makes more sense if you know that my name is Conrad.
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.
> I'm not changing it to be more corpo-propriate now.
Look, I'm not wanting to be rude here, and this is obviously all hypothetical since you're likely not actively pitching to investors, but if you were, being stubborn in this way would be a deal breaker for me as an investor.
I see all the reasons you have for keeping it, and they're reasonable, but the mere idea that that's a hill you're willing to die on is a red flag. I'd see this as one of many potential points of friction. Where else will you choose to not make compromises?
Maybe it's not rational on my part, but you're trying to convince irrational entities to part with their money.
You could look at it this way: if someone offered $17M to change it, would you?
I don't blame you for not wanting to change your name.
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.
I agree completely. However, this mentality is why honest people like you get pushed to the sidelines, and manufactured, perfect imaged, 1000+ referenced in LinkedIn types are more successful in getting VC funding. If this is seriously your goal, you are going to have to play the game. Remember, even when perfectly playing the game in your position you will likely fail. If this is what you want to do, do you want to be taken out of the running for something like a username?
It's not that other people are famous. They have a track record in this exact field, where he produced results and made money for investors. His results help to shape how software development gets performed.
They are using fame and past success as a proxy. You would need to do it on the basis of your ideas and the work that you have done. Someone really knowledgable would need to dig deep on your work and then the VCs will need to trust these person(s). The other alternative might be to try to get traction with users like Linus did with git and hope that they like it enough that it becomes popular. But Linus had the advantage of being famous and highly respected already,
No offense, but why should I believe you? The guy is famous because he has a track record of success doing similar projects. Of course that doesn’t guarantee success, but I’d wager it makes it statistically more likely than a random person. Starting a successful company is not all about good engineering.
Have you built a prototype and tried to pitch any VCs? Or are you just asking rhetorical questions?
I built a prototype, and then I rebuilt and rebuilt it and rebuilt it, and somewhere in there my understanding of how to think about what I was building completely flipped on its head. Then I rebuilt the version flipped on its head another several times until I finally understood it. You can see that on my Github, it's all public: https://github.com/conartist6 (public devlog on Discord).
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 none of that shit matters if you can build a product that people use and want to pay for. I would back someone who has made a dollar off of a product over someone who has built a great product that no one uses 100% of the time.
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.
Sadly you can't, and this is a huge flaw in the venture capital model. They invest in people that they think other vcs will invest in. More often than not who your parents are matters more than anything (unless you've had a huge exit like the OP). They'll also throw money at you if you come from a rich family, not because they think you'll succeed, but because they want your family's money as LPs in their funds.
Well regardless of whether it's hard or impossible, I'm doing this. I'm going.
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 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.
I watched video to see where my prompts etc are stored in a way that makes sense. But no, this is just a nicer git. We need a solution to all these 10k loc PRs.
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.
Makes sense to me. The new coding agents are drastically changing software development, and I think there's a lot of space for innovation in how version control tooling works in this new world.
Another commenter explained it: It's about working on multiple branches in parallel. You can only check out one branch at a time currently in git - but with "but" you have all the changes just in memory so different agents can work on different branches at the same time.
Working on multiple branches in parallel is literally what Git was created for, and how it's been used since the very first version 20 years ago.
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.
put differently: there's already a lot of money moving from A to B as people use AI & agentic coding. Find a way to get yourself in the middle of that cash flow and suck out a few percentage points of it .. profit!
Put another way: the idea didn't raise $17M, the team did. That's usually the case but you can fully expect a pivot in their future.
Once open source spreads into an area, it tends to kill (commodify) commercial software in that space.
For example, with databases, MySQL and Postgres "won". Yes, there are commercial databases like SQL Server and Oracle but they largely exist through regulatory capture and inertia. It's highly unlike anyone will ever make a commercial general purpose database again. There are always niche cases.
Same with operating systems. Yes we have MacOS and Windows but what are the odds we get another commercial mass OS? I'd say almost zero.
It's the same for source control. Git "won". There are a handful of others (eg Mercurial). But gone are the days of, say, Visual Source Safe.
But when people talk about "what comes after Git" they really mean (IMHO) "what comes after Github", which is a completely different conversation. Because Github absolutely can be superseded by something better. Will it though? I don't know. It has an incredible amount of inertia.
As for AI and anything related to source control, I'd have a hard time betting against Anthropic. But remember the exit could be an HN post of "We're joining Anthropic!". Side note: I really hate this "we're joining X" framing. No, you took the bag. That's fine. But let's be honest.
For people with a proven track record, AI is a gold rush of acquisition more than creating a sustainable business, let alone an IPO. I think that's what this bet is.
- leads with amount of money raised
- mentions a16z
- i use git every single day and have no idea what exactly the thing will do
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
They dont want to build the next git they want to build the next Github. It will have one of those licenses where you can use it but not offer a managed service like the Elastic License
Seeing all of these investments in developer tooling projects makes me wonder/skeptical of what the next chapter of development looks like when the money spigot runs dry.
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.
> Feels like vibe-coders are the real target market for something like this,
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.
VCs are not particularly well known for their commitment to building products that they can't make money off of. They'll promise you the OSS world and then as soon as they can they'll pull the rug out from under you.
The problem is that they need to find some way to not only make the money back but multiply it.
That’s where the “you’re getting screwed” comes into play - we don’t know yet how they will screw us, but it’s gonna happen
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 curve, since all the models know how to use JJ really well.
Yes, it’s fantastic. I have a post-tool-use hook for Claude Code to snapshot the repository for every edit. It’s like the built in file history feature but native in my VCS and works for my edits too. Don’t want to froth too much but JJ is my favourite piece of software in a while, and the fact that it’s not VC-funded is a major plus point.
Jujutsu is not "VC funded". But some of the developers, including me, work at East River Source Control (I worked on Jujutsu before that, too). The majority of the code in the project doesn't come from us -- or Google, for that matter. We don't allow people to approve patches when the author is from the same company, anyway.
If I remember correctly, jj is one guy who works at Google. Which presents a separate worry, which is that one day, when jj gets popular enough, Google will consume it, make it shit, change the name of it every six months and then shut it down.
"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"
}
]
},
In newer jj there’s a dedicated snapshot command but I’ve not updated yet. Pop this in your Claude Code settings.json. It will snapshot the repository, thus recording any changes. Explore with jj evolog.
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" without as much as a "post-github".
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.
LOL. In 2007, I did a side-by-side comparison of SVN, Mercurial and git with my codebase at work (~700k LOC). I know hg got faster eventually, but I still can't believe people say "hg should have won the DVCS war" with a straight face. It was orders of magnitude slower in my tests. Like, 20 minutes to commit large xml files (yeah, I know, but that's where we were). Not just a few ms slower, unbearably slow for several things.
I liked its features better, but chose git, and that was the correct decision.
This isn't an apology or a deflection, but different VCSes strike different trade-offs in terms of speed per workload. The mercurial storage model is comparable to video encoding in that it has a somewhat equivalent of "key frames" and alternates differential and full revisions¹. This makes workloads like bisecting or jumping to long-distance commits more efficient, at the expense of the time to create new commits.
For your use-case, mercurial has had a `largefiles`² extension for a very long time (long before git-lfs).
> I liked its features better, but chose git, and that was the correct decision.
Anyhow, my personal story with git is that I bought into the hype and social effects without really challenging my assumptions ("it must be the best, everyone says so"), until I got very fed-up with its obnoxious UI, and someone on IRC told me "ehh, give hg a shot". Nowadays, I mostly interact with git repos through hg-git and jj.
> 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 presentable later.
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.
You sweat because you are working with the CLI. Git is intrinsically "graphical". Use a good GUI client or higher level interface (maybe jj) to manipulate git graphs --- stop worrying about "how" (i.e. wrangling with CLI to achieve what you want) and focus more on "what".
> 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.
I'm confirming the sentiment is accurate. Background: using Git (involuntarily) since 2010, did my fair share reading it's source, put honest effort into reading it's man pages, so. Jujutsu _is_ a revelation and I'm moving to it every time I'm able to: the git repository stays the same, it's the jj runs it now.
If you ever tried to have multiple WIP features merged in a Git working copy, I have a great news — with jujutsu complexity of the workflow increases linearly over the number of branches, if ever: it's almost trivial. Otherwise I very much encourage you to try — in and of itself the workflow is extremely effective, it's just Git makes it complex af.
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?
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.
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.
Most of the time when I'm using Claude my working tree is already dirty because I'm mid-task. I usually try to do a throwaway commit before every interaction with Claude, but it's easy to forget, or to leave the "accept edits" mode on accidentally and my working tree gets corrupted. Also having to commit takes you out of flow because you suddenly have to deal with any new gitignores, which requires at least a glance at untracked files to make sure you're not committing anything you shouldn't be. I want to be able to undo the state of my working tree to the moment before a particular interaction with Claude, just like how I can undo a file.
> You can definitely use git as a backend for building such a system, but some extra tooling is necessary
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.
It seems to have been build on great idea. Git's "plumbing" is just a set of snapshots of the tree, and everything above is built on that so replacing the porcelain with something better fitting the problem is far more useful than trying to reinvent the wheel and making yet another distributed tree snapshot based VCS just to reinvent user facing tooling like the other VCS tried
I was doing something with jj snapshots with AI now that you have mentioned.
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)
you'r doing great. we all learn these things. AI assisted development makes it really easy to redevelop, especially since it sounds like you were vibe coding it out.
Definitely not true about models knowing jj. I've had latest opus and gpt fail at revsets and fileset syntax, even hallucinating subcommands like jj move (maybe it existed before, interface is not stable). Luckily it's easy enough to not need them most of the time.
Yes, I use Claude with jj often, and it occasionally tries to use older commands like move. Most of the time it gets it right for me though, often plugins and such say to use git explicitly, and that's where it tends to stray.
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.
I do use git branches, but they solve isolation, which isn't my pain point with git.
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.
Why not just ask your agent to check in before every change? And then squish before you push or share. Works great for me and easier than convincing coworker to switch off git.
Installed GitButler to try it out — and realized it installs malicious Git hooks to take over the git commit workflow:
* 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.
Just to clarify (and we do say this when you run `but setup`), the `pre-commit` hook is needed because of the way that we manage commits - we allow for multiple parallel applied branches, which Git cannot do. The way we accomplish this is to maintain a hidden 'megamerge' commit (as JJ would say). All Git commands work fine the way we're doing it except 'git commit', which is not aware of our operating model and will commit on top of our megamerge, which is problematic. So we install pre-commit to protect against getting yourself in a poor situation by using both Git and GitButler interchangeably.
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.
this is bad developer UX ( in my opinion). Please reconsider . I lost interest the moment I was not able to commit using normal git commands.
⎿ 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)
but was not installed ( I installed the mac app ) .
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 ) .
All I did was install GitButler via my OS's package manager, and open a local repo via the GUI.
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.
The tool that could replace git must free, ubiquitous, and arguably open-source. This is why I cannot imagine how raising $17M may pay for itself in that case, to say nothing of a 10× return.
It may be a great tool, but I'd be very reluctant to use a closed-source solution as a cornerstone of infrastructure.
I would argue it being proprietary would be completely unacceptable, for such a position of importance.
In any case, Git has become tremendously entrenched over the past couple decades. Anything that hopes to replace it would have to be significantly better to break from the inertia Git has. I’m honestly skeptical as to whether this is even possible in the near future. We’re not at all in the same historical moment as when SVN was beaten out.
yeah, it used to be that things like Perforce could still exist, because when they were created, they could do things that their OSS equivalents could not.
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.
I was just thinking that. I first started using Git to interact with Subversion repositories as a better svn than svn, and I'm surely not the only one.
git's replacement won't be there because it was better at being what git is (too entrenched), but because git became redundant as the world changed around it. As agentic development takes over and people stop caring about source code, all the tooling (including languages themselves) and approaches to assist humans will be ripe for replacing with those for machines.
"Backed by" as in "running git under the hood", not as in "supported by the git organization". I'd probably use "powered by" in this case to avoid confusion
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
Can agents not checkout different branches and then work on them? It's what people also do. I have a hard time to understand what problem is even solved here.
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.
Lol. Unfortunately VCs and ever-so-ernest founders are impervious to irony. Best to just let them get their grift on and just be happy it isn't your money they're boondoggling.
Well, yeah, but Git is basically UNIX/POSIX or JPEG. Good enough to always win against better like Plan 9 or JPEG XL (though I think this one may win in the long term).
> 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 able to design the second (code is an end result, not the process of solving a problem).
> 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 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.
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?
Literally true if it's that one guy you're talking about.
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.
I'd be 1,000x more interested in a project with the official git maintainers' buy-in to leverage the alleged power of LLM development to bring all git's features into libgit2 (or whatever, but that's a starting point) and switch git itself over to using that as its backend.
I've twice in my career found reasons that git being (officially; I have no interest in dealing with another implementation with its own missing features and distinct bugs) a library instead of a messy ball of scripts and disparate binaries, would have saved me tons and tons of time. You can look at the stories of how Github was designed and built, or look at the architectures of other similar software, and see folks struggling with the same issue. You'll run into frustration on this front pretty much instantly if you try to build tooling around Git, which turns out to be such a useful thing to do that I've ended up doing it twice in ~15 years without particularly looking for reasons to.
(While we're at it, how about some kind of an officially-blessed lib-rsync with a really pleasant API?)
Uhh, to be fair, if the goal was only to recreate git from 2005, it probably wouldn't cost $17M. I'd hazard a guess that they're recreating modern git and the emergent stuff like issues, PRs, projects, etc. I've also heard that the core devs for git are essentially paid a salary to maintain git.
Thinking it for bit it comes to "what comes after Git" and what does "Git" mean there.
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.
No he didn’t. He built a proof of concept demo in 7 days then handed it off to other maintainers to code for real. I’m not sure why this myth keeps getting repeated. Linus himself clarifies this in every interview about git.
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!
Those were not his ideas. Before Git, the Linux kernel team was using BitKeeper for DVCS (and other DVCS implementations like Perforce existed as well). Git was created as a BitKeeper replacement after a fight erupted between Andrew Tridgell (who was accused of trying to reverse engineer BitKeeper in violation of its license) and Larry McVoy (the author of BitKeeper).
I agree and that’s the point I was trying to make.
Linus’s contribution is a great one. He learned from prior tools and contributions, made a lot of smart technical decisions, got stuff moving with a prototype, then displayed good technical leadership by handing it off to a dedicated development team.
That’s such a good lesson for all of us devs.
So why the urge to lie and pretend he coded it in a week with no help? I know you’re not saying this, but this is the common myth.
He did what needed to be done. Linux similarly has thousands of contributors and Linus's personal "code contribution" is almost negligible these days. But code doesn't matter. Literally anyone can generate thousands of lines of code that will flip bits all day long. What matters is some combination of the following: a vision, respect from peers earned with technical brilliance, audaciousness, tenacity, energy, dedication etc. This is what makes Linus special. Not his ability to bash on a keyboard all day long.
The parent comments are arguing that 17million for git 2.0 is insane because Linux wrote the original in a week.
Except that’s not true. He sketched out a proof of concept in a week. Then handed it off to a team of maintainers who worked on it for the next two decades.
It’s also not pedantic because Linus himself makes this distinction. He doesn’t say he coded Git and specifically corrects people in interviews when they this.
First off, I'm of course interested to see what the future infrastructure of software building next looks like.
> 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.
The only security incident I've had in my career was due to Git Butler - it committed temporary files into GitHub without me explicitly approving it! Of course, it was a private repository, but still, it became impossible to delete those secrets because there were plenty of commits afterward. Given the large file tree and many updated files in the commit, it wasn't apparent that those folders got sneaked into the commit.
So, I really hope security incidents don't come after Git!
Just a reminder that even if you managed to amend those commits and force-push, the commits would still exist and will be addressable given the hash is known.
The issue is that the investors will want a return on that $17M at some point, so they're going to need to charge money for something eventually. If the revenue model is not obvious now, that only means they'll be pressured into something non-obvious later.
I like what I see in the video, it would solve a lot of problems I end up having with git.
That said, I find the branding confusing. They say this is what comes after git, but in the name and the overall functionality, seems to just be an abstraction on top of git, not a new source control tool to replace git.
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.
I actually believe we need to rethink Git for modern needs. Saving prompts and sessions alongside commits could become the norm for example, or I could imagine having different flags for whether a contribution was created by a human or not.
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.
Actually, it is. We're currently leading a conversation among several players in this space to agree on a metadata standard that helps make attaching, collaborating on and transmitting information like this simple, extensible and scalable.
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.
What do people expect to do with these saved prompts/contexts? Nobody is going to read through them, right? I suppose the thinking is LLMs will, but any decently active codebase will soon contain far too much context for any current LLM. Is this the same thinking behind cryonics, ie. we may be able to use this stuff one day so let's start saving it now? Hoarding has ruined many people and it will ruin us all if we're not careful...
For me the reason would be to preserve traces of intentionality (ie what was the user trying to achieve with this commit?). These days a 10k LOC commit might be triggered by a 100-word user prompt, there is a lot more signal in reading the prompt itself than the code changes.
I mean, it's just text, so it shouldn't be too taxing to store it. I agree it's hoarder mentality though :)
>Saving prompts and sessions alongside commits could become the norm for example, or I could imagine having different flags for whether a contribution was created by a human or not.
and then the tooling could attach any metadata to it that is desired.
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"
Honest question. I love some of the additional capabilities and specifically the dependency commits, virtual branches, and JSON output...
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?
There’s no business in working with an existing community to add functionality. And hence, where do you think the full time developers working on the project would get their livelihood?
Yes you could add all these things to git, but no, nobody will give you $17M to do it, nor will you find competent engineers who are willing to work for whatever funding they can find for “improving git”, which in all reality will probably round down to 0 in comparison to several software engineer’s salaries.
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.
I'd like to pretend that inability to render large diffs is a feature. Nobody is going to actually read the multi-thousand line diff; you need to make smaller PRs, or just admit that the diff in that particular view isn't helpful. I doubt that's the actual reasoning, but I can live with it.
Wow. So much hate in the comments here. Of all the funding / equity events lately, I wonder how this one gets so much doubt and distrust from the start.
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.
Nothing in this project looks vibecoded. I compel you to try vibecoding this in a couple weeks if you think it’s possible, and then after that to build a business out of it. If the only thing stopping you is the code, you should give it a try.
Git just works.
If you're not really familiar with it, you can use a free UI.
If you don't know anything about it, AI like ChatGPT or Claude can help you commit or even teach you Git.
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.
'Stacked PRs' are back on the menu with Claude, because changing something in PR1 isn't a massive time sync to get PR2-5 back in shape, as Claude can usually handle all of that for me.
i dont get it, watched the video seeing the "power" of using multiple branches at the same workdirectory etc. all i was thinking was ok they want to make it easy for coding agents work with multiple branches / feautres at once... Just that works already pretty well with git and worktrees... and agent uses the tools anyway... dont know what they want to build with 17M
> We've raised $17M to build something like git and bait-and-switch it later because VCs only exist to extract value and anything we end up building will be a shadow of a fart of how useful git actually is
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.
> I don't understand how anyone could think to replace git by raising money. The only way to truly do this is grassroots iteration.
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.
Claims about “what comes after git” aside, I really like the idea of virtual branches. Worktrees have a pitfall IMO that they don’t allow you to test changes in a running local env, meaning I need to commit the changes, close the worktree, and checkout the branch on my primary workspace to verify.
Gitbutler virtual branches OTOH appear to provide branch independence for agents/commits, while simultaneously allowing me to locally verify all branches together in a single local env. This seems quite a bit nicer than checking out worktree branches in the primary workspace for verification, or trying to re-run local setup in each worktree.
It can back on to git if you want, so a migration doesn't have to be all-at-once. It already has all of these features and more. It's stable, fast, very extensible.
jj truly is the future of version control, whereas git plus some loosely specified possibly proprietary layer is not.
I'm excited to see what ersc.io produces for a jj hosting service and hopefully review UI.
So many people in this thread started commenting before trying the product or even watching a simple video of what it does. It's like reddit, commenting based on title without any actual comprehension of the content. Shameful really.
Real question--- why does one of the GitHub co-founders need to raise 17M for a venture? I'm certain they could fund it themselves. Is this more or less a marketing play than anything else?
Why are investors still investing in SAAS products like this? I've heard some investors made rather blunt statements about such investments being a very hard sell to them at this point. Clearly somebody believes differently here.
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.
> If you think like that why invest in software at all; the AI will do everything?
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.
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.
There seems to be a bit of a trend that dev adjancent open source companies with not much monetization strategy are being bought off by AI giants. Most prominently Anthopic bought bun, OpenAI is buying Astral. So that may be the exit plan too.
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.
I think Git specifically with jj is still a massively good tool. There are some interesting alternatives happening like Fossil with its auto commit which for single devs is probably realy nice.
Or Pijul but thats very early stage.
Alternatively I had the idea of something that automatically syncs your current working progress similar to how Word and Excel autosave work. With a main "branch" thats never developed in and will only be merged into from synced streams. But that idea is nowhere near cooked out yet.
I failed to see why this would be something that "comes after Git" from a VCS perspective.
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.
Seems fine I guess. I'm not a fan of Perforce but it does have some features that git still struggles with and needs to address to break into new customers. This Gitbutler seems to address some of them but I can't say it really feels next gen.
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?
My understanding is parallel branches allow multiple changelists to be applied to a single workspace. eg you can have multiple WIP fix branches active in your feature branch workspace and not worry about polluting your feature branch with unrelated/duplicated commits.
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.
Genuinely curious about the collaboration model here. Git's biggest weakness isn't technical — it's that merge conflicts are a social problem disguised as a technical one. Two people editing the same file usually means the ownership boundaries are wrong, not that the VCS is.
What does "what comes after Git" look like for a two-person team vs. a 200-person org? The pain points are completely different.
> Imagine your version control tool taking what you’ve worked on and helping you craft logical, beautiful changes with proper context
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.
As long as this tool doesn't break "fast forward merge" and proper linear history and allows you do delete PRs unlike its GitHub progenitor then I'm happy.
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.
Those who don't understand git are bound to reinvent it. Git is fine as it is, with some porcelain and QoL improvements here and there. Some of the most capable devs I know use git + cgit for collaboration and they manage just fine.
X is hard to use because when something goes wrong you need to have a deep knowledge to figure it out! Let's build Y on top of X to make this easy! Now you just need to have deep knowledge of both Y and X to figure problems out. And it's gonna cost $17M to build Y. Deal?
Git isn't that old. I find it interesting people want to replace it by big money. Does this say something about the quality of git? Enough people also complain about that.
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.
How I'm using git/Github has changed with agentic coding. However, I'm not using swarms of agents to write code, so it's bit hard for me to decipher the JTBD of gitbutler.
Another take I've seen is https://agentrepo.com/, which is light-weighted hosted git that's easy for agents to use (no accounts, no API keys, public repos are free). There are large parts of the GitHub experience I'm no longer using (mostly driving from Claude), so I think this is an interesting take.
But you also get an idea of the average reading skill of people based on the top 3 comments: "I don't want a replacement for Git!"
I'm not blaming anyone, or maybe both the readers and the authors.
People now write something that could've been published as a short story 30 years ago, for something that could be a paragraph in length, detailing their emotional state, minute background information, their hopes and dreams.
The adaptive response to this by humans and society is to read the headline and ignore the prose, as the prose is so god damn long.
"Gitbutler is a UI for Git" would've been more suitable than hype about replacing git.
I watched the demo video on the git butler home page and agree with the premises that:
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?)
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.
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.
I've been using gitbutler since 09/24. It was the first git GUI I preferred over the command line. Being able to separate local changes into separate branches, drag missed changes into a past commit, etc. made tidy development so much easier. It is a great tool and the hate here is wild. However, I find it less useful when agents code for me. The surgical changes GitButler made so easy became less relevant as agents touch so many files at once. Have you found the same? Whats your vision for how GitButler will make agentic coding better in the way it did human coding? Does it move away from the UI you have now to something else? Does the UI get relegated and it becomes a tool the agent controls? (I liked the agent integration but it didn't feel like an improvement over using codex/CC so I went back to using them directly)
Fair enough, but he created it and I don't know the names of the real maintainers (sorry).
And I don't think these two are writing the code for GitButler tbh.
Anyhow, main point still stands: git is used by millions with no venture capital funding.
Huh. I look at what it took to build Git to begin with[1] and have to wonder if the thing that comes after it is really going to be _that much_ better. Git came about because there was a need for it. I feel like GitButler came about because there was a need for funding. Maybe I just need to have my coffee before commenting.
I'm trying not to comment on too many of these, but this one is interestingly wrong to me, so why not indeed?
GitButler came about many years ago because I have been using Git for almost the full 20 years of it being around and I thought there could be a better way to do the things it's trying to solve for us. I want version control to do more for us, easier, faster and smarter. Git is still pretty dumb. Plus, now, 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)
There does seem to be a lot of jaded pessimism this morning (buck up, fellas!)
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.
Why is GitButler still using Git if Git is the problem?
> As a _single_ example - agents can't use interactive editors, yet _so many_ of the powerful parts of Git absolutely _require_ it. Agents can't interactively rebase, meaning they can't very effectively squash, amend, reword, reorder, absorb. They can't very easily interactively add. They are middling at best when it comes to stacking branches. Git is designed to send patches over email and agents are not concerned with that.
Why aren't these just patches to Git itself? Or a fork of Git. You're layering tooling on top instead of fixing the foundations? You say stop layering? But you're clearly still using Git because you're calling it GitButler. You're another layer, like jj and like GitHub's UI.
Git is awesome in lots of ways. As a data storage layer and as a transport protocol, it's pretty great. The porcelain was built for a different era and is slow to adapt. Originally, Git was meant to just be these primitives and everyone was supposed to write their own "porcelain" or SCM on top. We're doing that and then some - creating new standards for more metadata, real time communications, built in review, etc. If anything, we're going back to the original point of git and doing what Linus wanted other people to do in the first place - write a good SCM for their workflows on top of the foundation he started.
Is this actually replacing git, or just a new frontend for the same git stuff? In any case, I'll be interested to see if this still exists in a year, and if that $17M actually made it replace git
Git is pretty close to ideal for the distributed model.
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.
No shade on these guys, looks like a cool tool and I'll try it. However, I find myself doing large majority of my git operations using a an agent[1] or a TUI [2], and I rarely open a git interface. I can get everything done straight from the terminal.
I guess I can overcome the "what if I cannot undo" anxiety.
Makes sense. Git solved versioning, not collaboration at scale. Most real pain today is juggling context across PRs, tools, and now agents not writing code.
I do not understand the problem solution, but if anything with git, I would want Codeberg style. I moved to gitlab and they were soldout and I am back on github slowly transitioning out. Common sentiment I believe is we want git, but on our own terms, not another VC funded project to move in.
My only issue is the title. It appears they are building a replacement for GitHub of which a replacement for Git is just a component. Building a replacement for GitHub is going to need at least the sort of funding they are mentioning. So once one reads the article it makes a bit more sense.
Some others mentioned pijul, but I will put in my two cents about it. I have been looking to make use of it because it seems really nice for working with an agent. Essentially you get patches that are independently and can be applied anywhere instead of commits. If there is ambiguity applying a patch then you have to resolve it, but that resolution is sort of a first class object.
the one feature which I have never seen in VCS is ability to stick commit message not just to all changes, but specifically to line/hunk.
It looks like very intuitive for me - I don't want to invent "references style" to say something about specific changed line in my commit - I want comment this line directly.
The title mentions 'after git' but the video demo shows that it's very much tied to git and Github. The post also mentions the overhead of dealing with git, but the examples shown come with their own overhead and commands. I'm admittedly unable to see the appeal or just misunderstanding it, but the number of stars on the repo shows I'm in the minority.
Yes, I think that “after git” claim is just marketing. This is indeed just a nice frontend to git. It looks interesting and seems to solve real problems, in the same way that jj already does. But it is not a radical change.
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.
I watched the video but I don't quite get it. I feel like I'm missing something? A nicer git workflow is not what I need because I can ask an LLM to fix my git state and branches. This feels a bit backwards. LLMs are already great at working with raw git as their primitive.
I'm curious what their long term vision they pitched investors is.
I don't have to read the article to know that if it not just git with fixes and new features, it's not going to pan out. This is like building a new house because your current house needs a couple of leaks fixed and a coat of paint.
I feel like we’re over-capitalizing a problem that could be solved with better protocols. If the "Git successor" is just a wrapper to help agents not hallucinate their own worktrees, it feels like a very expensive solution to a context-window management problem.
I wonder what the development of git itself has cost in engineer time? Presumably more than $17 million? Assuming a fully loaded engineer is 250k, that only amounts to 68 engineer-years over 20 calendar years, which seems low.
LLMs have solved the Git problem without any need for other tooling. There is no learning curve anymore. You don't need to know any commands or even look at the CLI. You can explain in plain text what you're trying to do.
It’s weird because I could see raising money on the premise that GitHub is garbage, not git. But then you can’t say I co-founded GitHub as your bona fides.
Dunno what they’re trying to build, but I encourage everyone to try what they already have built. It helps me work on multiple changesets in parallel. This often just happens, for example you work on something and discover a bug in something else that needs to be fixed. In GitButler, I can just create another branch, drag the changes in there, push and done.
Also, if you ever worked with Perforce, you might be familiar with changelists. It’s kind of like that.
Now, GitButler is by no means perfect. There are many rough edges. It tends to get stuck in unexpected states and sometimes it isn’t easy to rectify this.
It also cannot split changes in a single file, which is a bummer, because that’s something I encounter routinely. But I understand this complicates the existing model tremendously.
Most of the comments here are clearly from people who haven't used GitButler. Try it out and it's a very sticky product, clearly superior workflow to vanilla Git.
GitHub CEO also raised 60M for 'entire' to bring agent context to git. The dust is yet to settle here as it's difficult to bring a paridgm shift from today's git workflows
To me jj is an ok porcelain for git, but I find it worse than magit. Sure, it has some tricks under their sleves for merging, but I just don't run into weird merges and never needed more advanced commands like rerere.
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.
> I know what you’re thinking. You’re hoping that we’ll use phrases such as “we’re excited,” “this is just the beginning,” and “AI is changing everything”. While all those things are true, I’ll try to avoid them and instead make this announcement a little more personal.
Refreshing. I am so tired of the usual PR-approved phrases that you read in every announcement.
Other than that, I agree with other comments: not sure what Git's problem is, and what they are supposed to solve. Star Wars' "it's a trap" vibes.
We’re building the infrastructure for how software gets built next."
Dude, aside from this type of phrasing being cringe, it's such blatantly obvious LLM induced psychosis phrase... ridiculous.
I didn't even read that insanely long article explaining why one would need this (the necessity should have rang one or two bells for the author)... but all i could think of before reading that cringe ending, was: you're building what comes after git, but carry "git" in your name seems kinda odd... already revealing you either don't believe your own claims, or you do, but don't really mean what you're claiming... either way: WTF. Insane what's getting funded.
Also: the trend of companies overly feeling the need to explain they're not just X + AI (which also means LLM API), should really ring a lot of other bells to everyone else... god damn, too many bells to ring... and it seems like there is only AI chatbots left, that respond to anyone ringing the bell... god damn... they already took over & infected the human brain...
"Gitbutler", really rolls off the tongue, doesn´t it :) Oh and the irony of raising $17M to "replace" a tool which kinda...does not need replacing at all? How about replacing some of the entshittified services, like Google Workspace? Now that would be worth the $17M raised.
Wow, very impressive, great job!
You mentioned monitoring, I think it might be a very interesting way to see the "ongoing" work of your agents and orchestrate them. Do you have a precise idea on how it's going to happen, or is this already planned?
> I know what you’re thinking. You’re hoping that we’ll use phrases such as “we’re excited,” “this is just the beginning,” and “AI is changing everything”. While all those things are true
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.
There's definitely a need for this, but the underlying reason there's a need for this is so beyond me.
I've worked with a lot of Software Engineers over the years, even at FAANG, that didn't have a good technical understanding of git (basically, your repo is a tree structure, most commands are just about manipulating that tree in some way).
I mean, just spend the hour to go through a git tutorial. There's so many great ones like the interactive one that shows the tree as you go through the levels. It's your profession.
Also, I think another layer on top of Git as this seems to propose won't fix it -- once something non-obvious happens, these people continue to be stuck.
I would like to take this opportunity to kindly inform you that I wrote that post, as I write all of the blog posts on our blog (and everywhere else I write). You will never see something with my name on it that was written by AI. Thanks.
Could be I live in a bubble, but I don't use git because of GitHub or with GitHub that much.
No doubt, GitHub is/was great for distributing software but I feel we'd still all be using git without GitHub
Subversion was (and is) an admirable project, and filled a void by being much better than CVS.
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'm still not convinced we need a replacement for git.
> 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.
Jesus this website is overstimulating and it's extremely difficult to understand. What the hell they are selling other than a UI on top of Git? Git works perfectly fine especially if you take an hour or two to learn how to do a few more complicated but useful workflows (rebasing, cherry-picking).
Real problem is how to cope with few billion of bots hammering APIs 24/7 saturating net cables, physical infrastructure and taking down platform with constant DDOS.
Im curious when it will be “SO BAD” we start blocking every AI agent on firewall level.
Standard is better than better. For all of its flaws, I’ll take Git any day over any (better) alternative, because the value is in the absence of fragmentation. If a repo doesn’t use Git, I’m out.
My impression from GitHub was always that it was nice to have someone else host Git repositories for free, and that the "added value" (the Web view, the user management, the CI, the Wiki) were all made by dilettantes: poor quality, mostly useless, never doing the right thing.
These people seem to think that their "added value" was the selling point of their product... they appear to believe that some bad things are actually good and desirable, like, for example:
> Heck, it could be argued that development in teams is less social than it was when version control was centralized.
> But what if coding was actually social? What if it was easier to for a team to work together than it is to work alone?
This reeks of open-space floor office plan all over again! When some HR managers decided that programmers need all to sit in the same room the size of a basketball court and that would somehow help them work together better...
Programming is absolutely an individual activity first, where communication helps, but in order to be helpful the communicating parties have to have an initial internal process that refines the messages s.a. not to waste the other party's time. In practice, productive communication may happen once a day... up to once a week maybe? Maybe even less frequently? Git, as it is, is perfectly fine for this.
> Ok, that’s the simple case, pretty straightforward. However, GitButler can also do some pretty cool things that Git either cannot do or struggles with, namely:
> Having multiple active branches that you can work on in parallel.
I'll check out the same Git repository in different directories and will have this ability... maybe also add the second checkout as a remote to the first... but the number of times I've done it in two decades of working with Git is... maybe two? This is an extremely unusual need. I think, I've done this when migrating from multiple repositories into a monorepo and I had to somehow reorganize the history of multiple repositories so that it would make sense together. Definitely not a task for every day, not even every year.
The whole follow-up demonstration of parallel branches is just... Why on earth would I ever want to do that? Why would I want to work in such a way that I commit changes to different branches at (roughly) the same time? It's kind of like stashing changes, but, stashing is the byproduct of "bad planning": I wanted to do one thing, and accidentally did another... oh well, let's save the change somewhere temporarily! But, ideally, I want this to happen as little as possible. Not because it's inconvenient to deal with stashed changes, but because I will very quickly lose track of what goes where, why any particular branch exists etc.
Similarly, for the stacked branches: I absolutely don't want this functionality to exist... if it was already in Git, I'd request that it never be used. This complicates the mental model of what is even possible in the repository and creates some nightmare fuel scenarios: what happens if you stack them sequentially? What happens if you stack many branches on the same branch, and then want to rebase one of the stacked branches? What happens if you rebase the branch on which other branches are stacked? What happens if you delete the branch on which other branches are stacked? Does the stacked branch have to exist in the local checkout, or could it come from a remote?
It's absolutely the case where simple is better (I'd never imagine I'd call Git simple, but here we are).
I can't imagine what the workflow of people who want these changes must look like. I can't imagine why would anyone want to copy that kind of a workflow.
They raised $17M to build what appears to be solvable by some git wrapper scripts that could have been written by AI in 5 minutes?
To me the extra "wat" about this is that if I spend the sub-$1 to get the git wrapper scripts, I can get them exactly the way I want them, instead of being mandated to use the commands they made up. A huge gain for AI is the ability to have exactly the software you personally want, even if nobody else wants it just so.
So they are building the exact opposite of the need that AI brings forward. What they are building is not even median software that is in danger of being replaced (e.g. see Cloudflare spending a week to build "a wordpress"), but something that's the most extreme example of AI-will-replace-this that could possibly exist.
Who will buy this?
The only way this makes sense is as a plea for being acqui-hired (and the project dropped).
> 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.
I started using Git around 2008, if memory serves. I have made myself more than familiar with the data model and the
"plumbing" layer as they call it, but it was only a year ago -- after more than two decades of using Git, in retrospect -- that a realisation started downing on me that most folks probably have a much easier time with Git than I do, _due_ to them not caring as much about how it works _or_ they just trust the porcelain layer and ignore how "the sausage is made". For me it was always either-or situation -- I still don't trust the high-level switches I discover trawling Git's manpages, unless I understand what the effect is on the _data_ (_my_ data). Conversely, I am very surgical with Git treating it as a RISC processor -- most often at the cost of development velocity, for that reason. It's started to bug me really bad as in my latest employment I am expected to commit things throughout the day, but my way of working just doesn't align with that it seems. I frequently switch context between features or even projects (unrelated to one another by Git), and when someone looks at me waiting for an answer why it takes half a day to create 5 commits I look back at them with the same puzzled look they give me. Neither of us is satisfied. I spend most of the development time _designing_ a feature, then I implement it and occasionally it proves to be a dead-end so everything needs to be scrapped or stashed "for parts", rinse, repeat. At the end of the road developing a feature I often end up with a bunch of unrelated changes -- especially if it's a neglected code base, which isn't out of ordinary in my place of work unfortunately. The unrelated changes must be dealt with, so I am sitting there with diff hunks trying to decide which ones to include, occasionally resorting to hunk _editing_ even. There's a lot of stashing, too. Rebasing is the least of my problems, incidentally (someone said rebasing is hard on Git users), because I know what it is supposed to do (for me), so I deal with it head on and just reduce the whole thing to a series of simpler merge conflict resolution problems.
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.
I really, genuinely, do not want a replacement for git developed by a company that raised money to build it, since it will inevitably be a walled garden of one kind or another that enshittifies as it tries to make the money back. Git is fine and there is one thing no VC funded effort can get: freedom from the vampires.
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.
I continue to be amazed at American capital allocation. $17M for an idea to improve Git? For a fraction of that money Ukrainian housewives build anti-drone air defence systems in their garage that protect their country. For that kind of money you could build an apartment block to ease the housing shortage. You could invest in electricity resilience and build mini nuclear power plants or a small wind farm. Soviet capital allocation: while they were pouring money into their space program and building the "biggest baddest military helicopters" there wasn't enough bread in grocery stores.
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.
So it's gambling that they can extract money from open source project, by repackaging most of the existing features through a nice UX and hope business gamble their tech stack on it.
After a decade of negative interest, there is still a lot of excess capital looking for high-risk-high-gain investments. Perceived future economic value is unfortunately not in the stuff we know and understand to be useful, essential.
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.
You'd have thought the same about all the big tech companies when they were startups. Yet now they're making piles of money and contributing to America's overall economic success.
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.
The problem is they’re pouring insane amounts of money into non-problems. I use Git every day. There’s no problem with Git. Real problems that people suffer with everyday like healthcare and housing and even defense are doing so pitifully and we’re spending $17M on improving Git? If you don’t see the ridiculousness you really are in a bubble.
But then again, for a fraction of the money US-Americans pay for health insurance, we actually have public health insurance here...
Yes, we have higher taxes, yes, we pay more in social security... but in the end we have far less "Working Poor" and I know very, very, very, very few people who have more than 1 job.
But I guess that's just socialist bullshit.
What I am trying to convey is: The US lives in its own bubble, just like the rest of us does.
The difference is that the US hears the US propaganda and the rest of us heard the US propaganda for decades as well, through Hollywood and media.
Europe is far from perfect though. In all the three countries I'm familiar with (UK, Sweden, Spain) the healthcare system is really struggling. Extremely long wait times are becoming more common, for more procedures, even in the emergency departments.
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 wholeheartedly agree with that sentiment. We are definitely heading in the wrong direction. It's the same development here (not UK, Sweden or Spain)
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)
Long wait times are increasingly also a major problem in US healthcare, so I'm inclined to believe that the root causes behind wait time problems aren't related to public vs private insurance systems.
The worst part about what I see here is the inequity or imbalance of what we're seeing about where money gets allocated, and the material effects of what that inequity brings about. It's not "I have a good idea and a great team" it's "I am X, or know Y" and... ugh.
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.
> 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.
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.
I feel like I really need to learn how to raise money. For $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. Parents worldwide would love it.
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.
Money is not given to good ideas (though, it doesn’t hurt). Money is given to friends. If you look at how VC (or really any network) funding circulates, it’s just people who are allowed to enter that circle and money just flows between them constantly. On one hand, you have trusted people who you are willing to give money, on the other hand, this inherently creates a clique.
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.
Another thing I've noticed is how when you go on the website for a VC funded B2B startup and look at the customers or testimonies they have listed, most of them will be other B2B startups funded by the same VC. It makes me wonder how much of that market is essentially a few friends standing in a circle and passing a $100 bill around, but on a larger scale.
The reason “ideas don’t get funding” is usually (but not always) true is that usually a good idea alone doesn’t mean much. So usually you have to have good idea plus something else the investor feels is a proof point or evidence you can execute.
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.
Ideas shouldn’t get funding - ideas are just mere results of thought that haven’t been played through in depth.
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.
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.
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.
I don't think describing them as friends is entirely correct. People give money to people they trust. And friends often are in that subset of people. But that's not a strict requirement.
I'm sure VCs give money to friends but I didn't know any investors when I raised millions. They invested money because they thought it was a good idea.
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.
That works under the assumption of the "wisdom of the markets", and we assume VC possesses that wisdom, but laid bare it's just as vulnerable to cronyism as any other institution.
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.
As someone who tried to sort many lego sets lately, I do like this. The problem lies that modern lego has so many unique forms that it feels like you'll have many bins with one or two pieces in.
As the “Disturbing the Piece” podcast points out - you “sort” the good important parts you want easy access to and you “bin” everything else in the giant box you can dig through if needed.
That's why you buy different sized bins, and then you can even combine some forms into one bin (but be careful not to combine similiar forms, this counters the goal).
You need to get some bins that have a top shelf like a toolbox. The low item counts go in the top shelf, segregate the bottom for efficiency. Bin by color.
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.
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.
people love solving problems, but most solutions are not VC fundable (fortunately/unfortunately)
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.
The author is a founder of GitHub, he could raise $17m for “git but it’s called pit and a repository is a hole and committing code is called burying it” if he wanted to, investors care about pedigree.
> I feel like I really need to learn how to raise money. For $17M, one could probably ...
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.
HN is not a hive mind with a single opinion. You get the extreme opinions of both sides and every nuance in between. There are people here who despise VC and people who live for it and think it’s the greatest thing since sliced bread.
For what it's worth, that LEGO vacuum does exist[0], it was on Shark Tank[1]. I assume they stole the idea from The Office. It doesn't sort the bricks, but I assume that was more of a stretch goal based on the insane amount of money being discussed. After all, the LEGO vacuum only cost $495k to get to market.
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."
> EDIT: BTW did you see that the page you linked to has this at the bottom of their landing page:
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.
> 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.
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.
I like git, it works perfectly fine on my command line.
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.
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:
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.
> 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.
I would argue that it was purposefully designed in contrast against that model.
Sorceforge predates git by about 11 years. As do several other projects like google code. Its not a new idea. Or basically most source control systems. Git, actually, is the more unique idea, of a DVCS... versus a cVCS...
git is not a new idea, various features of git existed in various SCMs for decades. The distributed aspect existed in Bitkeeper too, for example.
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.
There’s really nothing resembling a “pull request” that’s used by 99.999% of git users. We have merge requests. But we call them pull requests for some dumb reason.
Indeed they're not; they live on the 'user layer' rather than the 'application layer'. That's not to say many git-frontends (IntelliJ, Sourcetree, Github desktop) don't support them, but "git pullrequest" isn't a thing.
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.
"Pull requests" are part of git though since it was originally a DCVS it meant you would pull from an individuals git repo ... services like github etc centralized the concept
Perforce had change sets and there were lots of tools for code reviews that worked a lot like GitHub before GitHub (review board, phabricator, another one I can’t remember).
> I feel like I really need to learn how to raise money. For $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. Parents worldwide would love it.
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.
Not to shoot down your comment with sarcasm, I'm being really honest: I changed my shower gel with an expensive one this week, and it really had an unexpected, exciting effect. Small stuff can really have consequences much bigger than themselves.
That said, if you ever decide solve the tidying the toys problem, start a kickstarter, I pledge to pledge support! :D
Some people are not sensitive to quality. A car is a car, a shower gel is a shower gel, etc. In the computer world, they curiously congregate around Microsoft...
Thing i learned about raising capital it, you need to build or have a network. Thats YC is great, accelerators, incubators help you do that. Network and story you tell. Also, every stage you raise, you have to make sure the folks you raise from help you craft the narrative for thr next round.
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.
> I think if you have a healthy busy growing well, you shouldnt raise unless you have ambition and urge to go faster.
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.
> I think if you have a healthy busy growing well, you shouldnt raise unless you have ambition and urge to go faster.
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.
I am twice your age so i would assume i have some wisdom here.
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.
> 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. Parents worldwide would love it.
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!
Roborock released one of these about a year ago. It doesn't do as much as they want, but it can pick up things and put them into designated locations, shoes being the main example.
> 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 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.
Unsure if you want the real answer, but the financials on gitv2 will be much more appealing to a VC. Hardware is hard, slow, expensive, risky. Finally, China is the place to build physical things not the US.
What would "the financials" be on a git replacement? No one makes money on git itself. Probably not much even on the services around git, given that Microsoft funds github for its own reasons, and gitlab is constantly running out of money.
17M seems like a rounding error these days with all the AI investments. Probably some spare cash in a fund that needed to be closed or something.
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.
That’s not really fair. That first week prototype was proof of concept, not the Git we use today. It would easily have taken $17 million for a private team to put in equivalent work to all of the open source effort that has made Git into the tool we have today.
One reason I don't read HN as much as I used to is because I can't help translating numbers like that into the amount of research that could be accomplished with the same amount, and then I get angry.
VCs have no clue. They have money and therefore they are in a dominant position. Everybody around them (professionally) is trying to flatter them and convince them that they should invest in their project.
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).
In fact, a certain amount of investment in frauds is acceptable and desirable; if you give £10m to 9 frauds who spunk it straight up the wall and to 1 true visionary who builds a unicorn, that's money well spent. Plus of course you can always hope that the fraudster is good enough to sucker the next guy so you can get out.
Per Matt Levine, the optimum amount of fraud is non-zero. Tune your detector too loosely or too tightly and you'll miss out.
The optimum amount of fraud is non-zero only because detection is expensive as you get close to zero. Getting less fraud needs to always be in mind. When someone gets away with fraud others will try to copy it so anything that has happened before has a much higher value to detect.
But for fraud that hasn't happened yet don't worry about it and hope nobody figures out how to do it.
An expert on crisps maybe XD? i'm not really sure about your last point on investing in frauds, i guess they only care if and when the fraud gets exposed, they might purposely choose to do exactly that given the right conditions though, it is a completely perverted and deranged system at this point.
Yeah sorry, I was saying "frauds" for "bullshit", I guess? Lacking some vocabulary to express this in a nuanced way.
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" :-).
> But instead, we get a replacement for Git. [...] Why is nobody solving actual problems anymore?
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.
> 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)
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.
As someone who makes things it always confuses me when millions just disappear whenever a company or government contractor makes things. Give me $17M and I'll build a vacuum robot prototype in under 2 years, I can't imagine 10 engineers getting paid $100+k/year can't do it in less time? Tooling is expensive, but not THAT expensive...
I would agree. CNC-ing POM also tends to work extremely well for prototype plastic parts.
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.
Get it approved in a lot of large markets? Deal with ongoing supply issues as suppliers change and you need to maintain your product? Market it? I could keep going on, but making a prototype is the easy part, making a sustaining business out of it is the hard part.
For $17 mil you can't replace Git either. Can't get it done.
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.
But we are not even get a replacement for git, we are getting a CLI on top of git. Since agents can use GH CLI and mcp very well, I'm very interested to see what is it that Git butler can do so much better (I also might be a bit sceptic, but I'll give them the benefit of the doubt).
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
On the other side, people who were using, say, Perforce, also thought there can't be anything better. Still, BitKeeper appeared as an innovation in the area, eaten later by Git, created by angry Linus (because of BitKeeper licencing changes).
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.
> For $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. Parents worldwide would love it.
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.
Solutions to more actual problems are more expensive. It’s easier to ask millions of people for $0.01 than it is to ask thousands for $100. Things that are easy to sell to millions of people for $100 are rarely innovative (transportation, food, entertainment, etc), and if they are, they’re world-changing (cars, supermarkets, smartphones, etc).
Totally agree - most of these co's that get funded are pointless. FWIW, the general math here is that you'd spend < 2-3mm developing new git and most of the money goes into distribution.
We've strayed really far from where technical innovation began
It's primarily focused on "take from someone else" rather than create something new and useful.
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.
I think it’s always good to dig a bit deeper on these things.
This seems ridiculous to you, compared to a very obvious win with a Lego sorting vacuum.
Lego isn’t niche, and the explanation isn’t a weird technical thing that only experts would get and understand how important or valuable it is.
Yet it’s not being done.
Is there nobody who has realised this gap but you? Has nobody managed to convince people with money that it’s worthwhile? Have you tried but failed?
Or is it not many many thousands of people who are wrong but you?
Is the problem harder than you think? I’ve worked with robotics but not for a long time and I think the core manipulation is either not really solved or not until recently. I don’t know about yours but my kids also don’t fully dismantle their Lego creations either so would the robot need to take them apart too? That’s a lot of force. And some are special.
How people want Lego sorted is pretty broad. Kids don’t even need it sorted that much. And the volume can be huge for smaller buckets of things.
Is the market not as big as you think? Is it big enough for the cost, I’d buy one for £100 but £1000? £10,000?
How does it compare for most people against having the kids play on a blanket and then tipping it into a bucket? Or those ones that are a circle of cloth with a drawstring so it’s a play area and storage all in one? I 3d printed some sieves and that’s most of the issue right there done.
People are solving actual problems, but lots of problems are hard, and not all of them are profitable.
As a gut feeling, there is such a large overlap of engineers and large Lego collections and willingness to spend lots of money and time saving some time sorting Lego that the small number of implementations usually split over many years is very telling about the difficulty.
Hasn't someone already built that robot? At least my kids tell me this exists every time I tell them to clean up their Legos. Actually it just does Legos, not the general toys.
Git is still pretty lacking in the area of big files. This is quite annoying if you're dealing with big deep learning data. So your LEGO vacuum robot could actually benefit from a better Git.
When the sock bot dries the socks, matches and folds them together we're at peak robot. Come to think of it, its got to not lose either of them also. Current tech falls short of this.
> When the sock bot dries the socks, matches and folds them together we're at peak robot. Come to think of it, its got to not lose either of them also.
Missing socks (and containers or their lids) are still great unsolved problems in 2026. Solving this issue is like fusion, always 10 years away.
The same reasons the world needed AI for cats funded to the tune of tens of millions of dollars. How do you expect those precious people to do anything at all without a bi-yearly expenses-paid trip to Cabo and on-site baristas?
I feel like git started to feel outdated overnight as the company I work for went agentic development first.
I fought for years trying to convince my colleagues to write good commit messages. Now Claude is writing great commit messages but since I'm no longer looking at code - I never see them. I don't think Claude uses them either.
Branches are now irrelevant since all agents work in worktrees by default. But worktrees are awkward since you run out of disk space fast (since we're in a monorepo).
There is a constant discussion ongoing whether we commit our plans or not. Some argue that the whole conversation leading up to the PR should be included (stupid imo).
The game changed completely. It isn't weird that people are wondering if the tools should as well.
Definitely feels like there's opportunity to build something better
I have to agree that the comment you are referring to seems to be nothing other than sarcasm despite that it doesn’t read that way at all. If it’s true, the world is definitely in trouble…
Have you considered returning to actual software engineering and workflows that tools were designed to support instead of playing the LLM slot machine?
Funny the replies you're getting here when already we see companies with engineers not having written a single line of code since late last year when models became good enough to go end to end.
We see companies running web apps on top of Oracle or not using any version control at all, let alone agentic coding; it doesn't mean it's a good idea because someone is crazy enough to do it.
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.
I ask myself this all the time, I have ideas now and then that I need to start writing down. Its just sad, we have so much potential as a society, but all the money goes to things like AI and bitcoin blindly. While I love some aspects of AI, and hope to someday be like the Jetsons and have a robot in my home that helps with things, and frees up me and my wife to doing other things with our family, I also don't trust something that is feeding my most intimate events from my home to a server somewhere.
It’s probably because you’re not willing to lie enough. There was some founder back in the 2010s, I forgot his name, but he’d go around giving talks on fundraising and he basically said he just lied all the time.
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.
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.
The vast majority of git users are using github as a central repository. There a a few other not github but serves the same purpose central repositories. Distributed sounds cool, but almost everybody wouldn't notice a thing if git was centralized.
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.
> To a first approximation, one could say that distributed version control is a problem nobody ever had, and nobody ever intends to have.
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.
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).
Your kids need to learn how to clean up after themselves.
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
Actually, a camera that scores the clean up progress, together with some virtual gold coins and real loot boxes for a week of good compliance might really do the trick.
You didn't click the link. Who are you to say that they aren't solving actual problems? You might not be their target. The whole article is dedicated to explaining why they're building their product.
The article does a bad job at that, because it remains rather vague and doesn’t explain the concrete problems they are trying to solve, that aren’t either already solved by Git-linked issue trackers, or would be better solved by improving support in Git itself (like for stacked branches).
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.
Tbf, git is very much a problem that needs solving. It only works well for text data, the fact that it is decentralized adds a lot of complexity but doesn't matter for 99% of users since they use a centralized git forge like Github or Gitlab, and the UX is pretty much non-existent.
It works exacly as it was designed to work.. GIT as VCS.. Version Control System.. for text code sniplets. It can handle small binary blobs just fine.
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.
But do you really think $17M is going to give us that alternative, or will it come from some brilliant guy going on a caffeine-fueled weeklong side quest (like how Git was invented)?
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).
if you don't understand git you shouldn't be coding, full stop. The exact same skill set needed to write good code is required to use git in quick and efficient matter.
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
Completely unnecessary retort. At no point did anyone in this thread state that sorting legos was a major problem of society.
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.
Maybe you're not a parent. To me, this sounds like arguing against the existence of the dishwasher by saying "of all the major problems of society, washing dishes by hand isn't one."
Successfully would be big business, because everyone and everyone and the F1000 uses git. Or at least it could more of a feature than a product, and gets merged into some other VC company, or some Jira feature or etc.
Who really wants cheap lego vacuums? Basement-dwellers who are getting yelled at by their mom? Not a good market.
Mmmh. git is perfect as it is. It does one thing and does it really well: version control. Exact bits that go in come out. And it reconciles different versions and handles transferring them to remotes.
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.
building the future of source control over the incumbent tech does not bring much excitement personally.
does not takeaway the interest and funding they are able to bring. raising money is not always a bad thing, if say, there will be a webapp to go alongside their approach to workflows.
> 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 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 problem is how to make money from something that is more or less solved.
BitKeeper tried to do that. Git was built because the commercial license of BitKeeper became unworkable for the Linux kernel community.
"Those who cannot remember the past are condemned to repeat it".
>Git was built because the commercial license of BitKeeper became unworkable for the Linux kernel community.
BitKeeper was free to linux kernel developers with a "but no reverse engineering" clause, but Tridgell went exploring of his own volition because he wanted to and kinda sorta violated that, so the license was cancelled by BitKeeper.
I'm not taking sides or upset about any part of this, I just wouldn't call that "becoming unworkable for the linux kernel community"; that would be like "the fence around your yard became unworkable for me in my desire to trespass on your property so I climbed over it"
what Tridgell discovered was pretty dumb and could be considered a distinct lack of a fence, but he connected to a socket and typed "help" and it dutifully printed out a bunch of undocumented useful commands.
Yep, something that is sadly becoming more and more common. People with solutions spending insane money trying to convince others that a problem exists.
It's basically the entire context of this website.
I'm gonna go out on a limb and say these guys would never have raised if they didn't have "GitHub co-founder" on the first slide of the pitch deck
Ok, that explains everything. Who you know in the Valley is everything. Literally.
The beauty of it all is one doesn’t even have to invent a solution… they only have to invent a “problem” to be pitched for VC funding.
have you heard startups
As a spoon designer, I have had some difficulty finding work lately.
It’s not solved because it’s trash. There’s no good interface for it and people find it difficult to use.
Skill issue. It's the most popular VCS in the world by a huge margin, millions of devs use it every day just fine, countless forges have been built around it, and there's only one semi-compelling alternative frontend (jj). If you honestly find Git challenging, how are you coping with software engineering? Git is the easy part.
Millions of dev use it in the most rudimentary way, occasionally lose their stash, rm their local repo and start over, ask the office expert for help every time they need to figure out where-the-foxtrot that commit came from, don't even attempt to use reflog or bisect or interactive staging, etc.
sure, but solving conflicts is still hard in git. This can be simplified.
> 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.
> 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.
I'm not a git expert but I cant image that's true
Of course is not true - look into git filter branch. I had to use it once when a developer checked in a whole bunch of binaries and created a PR which ended being merged. I had to rewrite the history and delete the files from history - just deleting the files would not suffice because the file were in git history and we’re taking too m&ch space.
It’s not you just need to force push or generate a new key…
Perhaps proving the point here. That's not enough to eliminate the secret, the dangling commit will persist. Though this might be a nitpick, it's rather hard to get it from the remote without knowing the SHA.
> generate a new key
Is absolutely the right answer. If you pushed a key, you should treat it as already compromised and rotate it.
You also need to clear the caches of the remote
Yeah it doesn't seem hard to rewrite the commit history
The interface can be independent of the implementation. Under the hood git does everything you need. If learning to use it at a low level isnt appealing, then you can put an interface on top which is more ergonomic.
I'm a huge fan of lazygit
> Under the hood git does everything you need
No it doesn't. Git is buggy. It also doesn't work for anything that's not a text file. It is unbelievably slow.
> Did you ever accidentally commit something that contains a secret that can't be in the repository?
What do I need to do on top of a git force push, and some well documented remote reflog/gc cleanup, which I can’t find with a single search/LLM request? Are we there, where we don’t have enough developers who can do this without feeling it as a burden? Or are we there where this level of basic logic is not needed to implement anything production ready?
> What do I need to do on top of a git force push, and some well documented remote reflog/gc cleanup, which I can’t find with a single search/LLM request?
This is a self-defeating argument. You're essentially saying we shouldn't improve something because it can be done with a handful of commands (you already know btw) and prompting an LLM.
> Are we there, where we don’t have enough developers who can do this without feeling it as a burden?
The no true scotman.
> Or are we there where this level of basic logic is not needed to implement anything production ready?
Not sure how this fits in with the rest honestly.
It was never about whether it was possible. It was about how it's being done. Juniors (and even seniors) accidentally check in secrets. Arguing that there shouldn't be a simpler way to remove an enormous security flaw feels a bit disingenuous.
No, I’m saying that you can do this without replacing git. You can make it simpler even without replacing git. Aka you just did a strawman, if you are really into these. Also you answered to me in an authoritative way, when even according to you, you don’t understand my comment. You can figure out a logical fallacy name for this. And also of course a nice fallacy fallacy.
Btw, I’m also saying that who cannot find how it can be solved right now with git, those shouldn’t be allowed anywhere near a repo with write permission, no matter whether you use git or not. At least until now, this level of minimal logical skill was a requirement to be able to code. And btw regardless the tool, the flow will be the exact same: ask a search engine or ml model, and run those. The flow is like this for decades at this point. So those minimal logical skills will be needed anyway.
The problem mainly is that when they don’t even know that they shouldn’t push secrets. You won’t be able to help this either any tooling. At least not on git level.
git rebase -i <one commit before your mistake> git push origin mainline -f
git log --all --reflog -- path/to/secret-file
Git filter rule
[dead]
This is juicero for source control.
The problem that requires a redesign is that vcs are unable to extract a subscription rent from some of the people who use git.
More power to them for re-visiting this, but agree with you:
> The old model assumed one person, one branch, one terminal, one linear flow.
That sounds exactly like the pre-git model that git solved..
I've always wanted a kind of broader and more integrated approach that isn't just about text diffs. the ability to link in substantial comments that would be displayed optionally and not piss off linear readers. links to design and reference documents. bugs and prs that were persistent and linked to the versioned code instead of being ephemeral.
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
[dead]
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 that can build the universal infrastructure for AI and agentic coding.
I think I have just as good a shot at building what comes after git as their team does, and perhaps quite a lot better.
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?
Might want to change that username before you make your pitch
The question is not "will the product be better." The question is will you make the investors money.
I understand that money is at the root of the question. I don't see any problem with my strategy for making money, which is to win over all their users with a wildly better product.
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 you wanted to imply that, but just to make sure no one misunderstands: GitHub didn't invent git.
I don't know if they were the first git forge, but they were certainly among the first.
That is an empirical question answered by the market. The way you get your answer is to build it, get it in front of people, and see if they use it. Then you will know.
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.
Quite! It just happens that so far I've been stuck on purpose.
The nature of developing standards is that you can't have people start adopting them until they're done.
Reach out to investors that you or your friends/family have an existing relationship with. If that's not an option your odds of being funded are slim. Consider going to Stanford or networking with them another way; the latter being much easier if you're already wealthy.
This might sound like a joke or overly cynical but I'm being totally serious. Merit and product quality are only very loosely correlated with funding success at this stage.
The vast majority of projects don't get VC funded and of the small number that do most have some sort of relationship or other in into the funding world.
This doesn't mean you can't get funded, but it's a huge longshot. If you already have an income and some savings consider bootstrapping the project yourself, at least until you have some traction in the market.
I appreciate the advice, but I'm a couple steps ahead of you. I spent 10 years mastering my trade (UI) working in San Francisco and Palo Alto and Menlo Park, and that's when I saved enough money to allow myself to work on this for the last 5 years.
And fortunately I don't need anyone's permission. It's just too late to stop the wave of change that's coming now. After 5 decades, the punchcard is finally going to be retired as the primitive at the heart of all programming.
Step 1: don't pitch from a conartist6 username
It's been my username for 20 years and I'm not changing it to be more corpo-propriate now. I think it makes more sense if you know that my name is Conrad.
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.
> I'm not changing it to be more corpo-propriate now.
Look, I'm not wanting to be rude here, and this is obviously all hypothetical since you're likely not actively pitching to investors, but if you were, being stubborn in this way would be a deal breaker for me as an investor.
I see all the reasons you have for keeping it, and they're reasonable, but the mere idea that that's a hill you're willing to die on is a red flag. I'd see this as one of many potential points of friction. Where else will you choose to not make compromises?
Maybe it's not rational on my part, but you're trying to convince irrational entities to part with their money.
You could look at it this way: if someone offered $17M to change it, would you?
I don't blame you for not wanting to change your name.
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.
No pilot has ever been a con artist...
I agree completely. However, this mentality is why honest people like you get pushed to the sidelines, and manufactured, perfect imaged, 1000+ referenced in LinkedIn types are more successful in getting VC funding. If this is seriously your goal, you are going to have to play the game. Remember, even when perfectly playing the game in your position you will likely fail. If this is what you want to do, do you want to be taken out of the running for something like a username?
It's not that other people are famous. They have a track record in this exact field, where he produced results and made money for investors. His results help to shape how software development gets performed.
They are using fame and past success as a proxy. You would need to do it on the basis of your ideas and the work that you have done. Someone really knowledgable would need to dig deep on your work and then the VCs will need to trust these person(s). The other alternative might be to try to get traction with users like Linus did with git and hope that they like it enough that it becomes popular. But Linus had the advantage of being famous and highly respected already,
I've considered trying to get Linus to be the knowledgeable person given his history. I haven't actually reached out though.
I badly want someone to take that deep dive given the work I've put in to be ready for it
Now you understand why people have non technical co founders!
>I think I have just as good a shot at building what comes after git as their team does, and perhaps quite a lot better.
This sounds like one of those "Hacker News Dropbox" comments...
The trick to raising money is being able to convince an investor you are the person to build that platform, not being able to build the platform.
No offense, but why should I believe you? The guy is famous because he has a track record of success doing similar projects. Of course that doesn’t guarantee success, but I’d wager it makes it statistically more likely than a random person. Starting a successful company is not all about good engineering.
Have you built a prototype and tried to pitch any VCs? Or are you just asking rhetorical questions?
I built a prototype, and then I rebuilt and rebuilt it and rebuilt it, and somewhere in there my understanding of how to think about what I was building completely flipped on its head. Then I rebuilt the version flipped on its head another several times until I finally understood it. You can see that on my Github, it's all public: https://github.com/conartist6 (public devlog on Discord).
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 none of that shit matters if you can build a product that people use and want to pay for. I would back someone who has made a dollar off of a product over someone who has built a great product that no one uses 100% of the time.
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.
Does anyone actually care about the above issues?
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.
Sadly you can't, and this is a huge flaw in the venture capital model. They invest in people that they think other vcs will invest in. More often than not who your parents are matters more than anything (unless you've had a huge exit like the OP). They'll also throw money at you if you come from a rich family, not because they think you'll succeed, but because they want your family's money as LPs in their funds.
Well regardless of whether it's hard or impossible, I'm doing this. I'm going.
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.
You can stop at bullet #1 and that's plenty to raise $17m on right there. No questions asked.
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):
I watched video to see where my prompts etc are stored in a way that makes sense. But no, this is just a nicer git. We need a solution to all these 10k loc PRs.
Another comment [1] has a solution - a new tool called pit, it just throws the whole 10k loc PR in a pit and forgets about it :p
[1] - https://news.ycombinator.com/item?id=47713650
> We need a solution to all these 10k loc PRs.
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.
Agreed. Although I’m not sure what’s nicer about it. It’s in color. But I failed to understand why I’d want any of those features.
Makes sense to me. The new coding agents are drastically changing software development, and I think there's a lot of space for innovation in how version control tooling works in this new world.
Why should ai need this? A linear backlog is enough, a cache, for everything else they can create it new in a short time.
Another commenter explained it: It's about working on multiple branches in parallel. You can only check out one branch at a time currently in git - but with "but" you have all the changes just in memory so different agents can work on different branches at the same time.
Working on multiple branches in parallel is literally what Git was created for, and how it's been used since the very first version 20 years ago.
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.
git-worktree has been a thing for a decade+ and AI agents seem to be using them just fine in my experience. This is a solved problem.
That's not even true
They actually started before the LLM craze. The original pitch was just better Git.
put differently: there's already a lot of money moving from A to B as people use AI & agentic coding. Find a way to get yourself in the middle of that cash flow and suck out a few percentage points of it .. profit!
Put another way: the idea didn't raise $17M, the team did. That's usually the case but you can fully expect a pivot in their future.
Once open source spreads into an area, it tends to kill (commodify) commercial software in that space.
For example, with databases, MySQL and Postgres "won". Yes, there are commercial databases like SQL Server and Oracle but they largely exist through regulatory capture and inertia. It's highly unlike anyone will ever make a commercial general purpose database again. There are always niche cases.
Same with operating systems. Yes we have MacOS and Windows but what are the odds we get another commercial mass OS? I'd say almost zero.
It's the same for source control. Git "won". There are a handful of others (eg Mercurial). But gone are the days of, say, Visual Source Safe.
But when people talk about "what comes after Git" they really mean (IMHO) "what comes after Github", which is a completely different conversation. Because Github absolutely can be superseded by something better. Will it though? I don't know. It has an incredible amount of inertia.
As for AI and anything related to source control, I'd have a hard time betting against Anthropic. But remember the exit could be an HN post of "We're joining Anthropic!". Side note: I really hate this "we're joining X" framing. No, you took the bag. That's fine. But let's be honest.
For people with a proven track record, AI is a gold rush of acquisition more than creating a sustainable business, let alone an IPO. I think that's what this bet is.
GitHub has already been bettered - gitlab is much better, in my opinion.
And Self hostable.
wasn't there another GitHub cofounder that recently also had some similar product launched?
- leads with amount of money raised - mentions a16z - i use git every single day and have no idea what exactly the thing will do
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
They dont want to build the next git they want to build the next Github. It will have one of those licenses where you can use it but not offer a managed service like the Elastic License
Seeing all of these investments in developer tooling projects makes me wonder/skeptical of what the next chapter of development looks like when the money spigot runs dry.
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.
> Feels like vibe-coders are the real target market for something like this,
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.
if the cli is open sources and ends up finished i don't see what the problem is to let a vc fund them building it
VCs are not particularly well known for their commitment to building products that they can't make money off of. They'll promise you the OSS world and then as soon as they can they'll pull the rug out from under you.
If they release the code with a permissive license, then this doesn't matter.
idk i just see this as someone giving me a free car in 2026 and being afraid they’re not gonna give me another free car in 2027
i’m happy to change the oil on the 2026 one for a few more years
To paraphrase Microslop's "Embrace, extend ... build a walled garden around."
“enclose”?
The problem is that they need to find some way to not only make the money back but multiply it. That’s where the “you’re getting screwed” comes into play - we don’t know yet how they will screw us, but it’s gonna happen
The problem is in your premise: Software usually does not end up finished.
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 curve, since all the models know how to use JJ really well.
Yes, it’s fantastic. I have a post-tool-use hook for Claude Code to snapshot the repository for every edit. It’s like the built in file history feature but native in my VCS and works for my edits too. Don’t want to froth too much but JJ is my favourite piece of software in a while, and the fact that it’s not VC-funded is a major plus point.
Its VC funded https://www.sec.gov/Archives/edgar/data/2076429/000207642925...
Jujutsu is not "VC funded". But some of the developers, including me, work at East River Source Control (I worked on Jujutsu before that, too). The majority of the code in the project doesn't come from us -- or Google, for that matter. We don't allow people to approve patches when the author is from the same company, anyway.
(also at ERSC here, hi Austin!) Heck, I have not had enough bandwidth to do as much upstream work as I initially thought I would when I started there!
that's a company built on top of Jujutsu, not jj itself
If I remember correctly, jj is one guy who works at Google. Which presents a separate worry, which is that one day, when jj gets popular enough, Google will consume it, make it shit, change the name of it every six months and then shut it down.
Can you expand on this? How do you achieve it? Just a WIP JJ commit after every change or something more clever?
In .claude/settings.json you can trigger shell commands on events like SessionStart, Stop, PreCompact, and PostToolUse [1].
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
The others use `jj status`, but if I were to do this, I'd use `jj log -n0`, which has no output. All you really need is any read-only jj command.
You could also turn on watchman and have this property on every save of a file and not even need to worry about hooks.
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" without as much as a "post-github".
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.
LOL. In 2007, I did a side-by-side comparison of SVN, Mercurial and git with my codebase at work (~700k LOC). I know hg got faster eventually, but I still can't believe people say "hg should have won the DVCS war" with a straight face. It was orders of magnitude slower in my tests. Like, 20 minutes to commit large xml files (yeah, I know, but that's where we were). Not just a few ms slower, unbearably slow for several things.
I liked its features better, but chose git, and that was the correct decision.
This isn't an apology or a deflection, but different VCSes strike different trade-offs in terms of speed per workload. The mercurial storage model is comparable to video encoding in that it has a somewhat equivalent of "key frames" and alternates differential and full revisions¹. This makes workloads like bisecting or jumping to long-distance commits more efficient, at the expense of the time to create new commits.
For your use-case, mercurial has had a `largefiles`² extension for a very long time (long before git-lfs).
> I liked its features better, but chose git, and that was the correct decision.
Anyhow, my personal story with git is that I bought into the hype and social effects without really challenging my assumptions ("it must be the best, everyone says so"), until I got very fed-up with its obnoxious UI, and someone on IRC told me "ehh, give hg a shot". Nowadays, I mostly interact with git repos through hg-git and jj.
¹: https://www.kernel.org/doc/ols/2006/ols2006v2-pages-91-98.pd...
²: https://wiki.mercurial-scm.org/LargefilesExtension
> 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 presentable later.
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.
You sweat because you are working with the CLI. Git is intrinsically "graphical". Use a good GUI client or higher level interface (maybe jj) to manipulate git graphs --- stop worrying about "how" (i.e. wrangling with CLI to achieve what you want) and focus more on "what".
GitButler from OP also allows you to do this incredibly easily. This and stacked commits is IMO their main selling point.
> 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.
I'm confirming the sentiment is accurate. Background: using Git (involuntarily) since 2010, did my fair share reading it's source, put honest effort into reading it's man pages, so. Jujutsu _is_ a revelation and I'm moving to it every time I'm able to: the git repository stays the same, it's the jj runs it now.
If you ever tried to have multiple WIP features merged in a Git working copy, I have a great news — with jujutsu complexity of the workflow increases linearly over the number of branches, if ever: it's almost trivial. Otherwise I very much encourage you to try — in and of itself the workflow is extremely effective, it's just Git makes it complex af.
I'm one of the git users who would sweat. Can you explain a bit (out link relevant docs) how I might split a commit up, and move it?
The problem put simply is that git doesn't support concurrency. Even if you use worktrees, git has a global lock for repo interaction.
https://www.felesatra.moe/blog/2024/12/23/jj-is-great-for-th...
What's the difference between "snapshots" and git commits? In my mind a git commit is already a snapshot of the repo and the changes one staged. In what way can you move around more freely than what one can do with magit, deciding for files, hunks, or even single lines of code, whether or not they get staged and committed?
You're right that git commits are snapshots.
jj is very non-modal, that is, it doesn't tend to have a lot of state that commands rely on. As an example of what I mean, because jj does not have a staging area, everything is already committed, which makes it very easy to say, move to a different commit: you don't need to stash your working copy, as jj has already stashed it for you. Similarly, due to the auto-rebase behavior, you can be working in one part of the tree, realize something somewhere else should be moved, and go rebase that without even moving to it at all!
As a small example: say I'm working on something, and I find a typo. I want to send that typo in as a PR, but I don't want to do it as part of my work. I can do that with:
1. make the change in my current working copy (@)
2. jj split -o trunk (selecting the typo contents to split off the typo fix into a new change on top of (hence -o) trunk)
3. jj log (go check out what the change id of that change is
4. jj git push -c <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.
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.
Just create a new branch before you implement new features and if the agent messes up don't merge the branch.
That way you get the best of both worlds. The buggy code is still there in case it's needed but it's not in the main branch
Most of the time when I'm using Claude my working tree is already dirty because I'm mid-task. I usually try to do a throwaway commit before every interaction with Claude, but it's easy to forget, or to leave the "accept edits" mode on accidentally and my working tree gets corrupted. Also having to commit takes you out of flow because you suddenly have to deal with any new gitignores, which requires at least a glance at untracked files to make sure you're not committing anything you shouldn't be. I want to be able to undo the state of my working tree to the moment before a particular interaction with Claude, just like how I can undo a file.
git checkout @{1.minute.ago}
> You can definitely use git as a backend for building such a system, but some extra tooling is necessary
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.
It seems to have been build on great idea. Git's "plumbing" is just a set of snapshots of the tree, and everything above is built on that so replacing the porcelain with something better fitting the problem is far more useful than trying to reinvent the wheel and making yet another distributed tree snapshot based VCS just to reinvent user facing tooling like the other VCS tried
I gotta say, jj was not something that interested me before, but that's a compelling pitch.
I was doing something with jj snapshots with AI now that you have mentioned.
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)
you'r doing great. we all learn these things. AI assisted development makes it really easy to redevelop, especially since it sounds like you were vibe coding it out.
Definitely not true about models knowing jj. I've had latest opus and gpt fail at revsets and fileset syntax, even hallucinating subcommands like jj move (maybe it existed before, interface is not stable). Luckily it's easy enough to not need them most of the time.
Yes, I use Claude with jj often, and it occasionally tries to use older commands like move. Most of the time it gets it right for me though, often plugins and such say to use git explicitly, and that's where it tends to stray.
I like darcs, so I am rooting for pijul.
https://pijul.com
is there a jj hosting service?
GitHub.
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.
https://tangled.org/ supports many jj features, but they seem to only offer public repos.
We are working on something https://lubeno.dev
Looks like still a bit early for me, but if you add an RSS feed to your blog, I would at least be reminded to check it out again later :)
I know of one: https://lubeno.dev
Any service that hosts git?
We use GitHub at my work. And I think I’m the only one using JJ.
Isn't jj git compatible so you can just use github?
Yes.
Do you not use git branches? Your use case was why git was made.
I do use git branches, but they solve isolation, which isn't my pain point with git.
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.
Why not just ask your agent to check in before every change? And then squish before you push or share. Works great for me and easier than convincing coworker to switch off git.
The biggest problem with Jujutsu is the name. I would love to hear a Swedish person try to pronounce it.
Its a backronym (or whatever you call it) that cones from the actual name, “jj”, which itself comes from the ease of typing jj on a keyboard
The logo is a pair of bluejays, so I've taken to casually calling it twojay with some of my coworkers.
"I can iterate freely without thinking".
Vibecoding moto.
Installed GitButler to try it out — and realized it installs malicious Git hooks to take over the git commit workflow:
* 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.
Just to clarify (and we do say this when you run `but setup`), the `pre-commit` hook is needed because of the way that we manage commits - we allow for multiple parallel applied branches, which Git cannot do. The way we accomplish this is to maintain a hidden 'megamerge' commit (as JJ would say). All Git commands work fine the way we're doing it except 'git commit', which is not aware of our operating model and will commit on top of our megamerge, which is problematic. So we install pre-commit to protect against getting yourself in a poor situation by using both Git and GitButler interchangeably.
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.
this is bad developer UX ( in my opinion). Please reconsider . I lost interest the moment I was not able to commit using normal git commands.
but was not installed ( I installed the mac app ) .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 ) .
We will remove the hook constraint as soon as we complete this https://github.com/gitbutlerapp/gitbutler/issues/11866
For the Claude question, the CLI ships a skill, set it up with `but skill install`.
I hope this helps
All I did was install GitButler via my OS's package manager, and open a local repo via the GUI.
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.
You keep using the word malicious, what do you mean? What is the malice?
Yeah it feels malicious if it doesn't tell you it's going to do that, like a sneaky lock-in
Silently replacing Git with `but`.
So they decided to start "embrace, extend, and extinguish" directly with with "extinguish".
Pretty much, yes.
The tool that could replace git must free, ubiquitous, and arguably open-source. This is why I cannot imagine how raising $17M may pay for itself in that case, to say nothing of a 10× return.
It may be a great tool, but I'd be very reluctant to use a closed-source solution as a cornerstone of infrastructure.
I would argue it being proprietary would be completely unacceptable, for such a position of importance.
In any case, Git has become tremendously entrenched over the past couple decades. Anything that hopes to replace it would have to be significantly better to break from the inertia Git has. I’m honestly skeptical as to whether this is even possible in the near future. We’re not at all in the same historical moment as when SVN was beaten out.
yeah, it used to be that things like Perforce could still exist, because when they were created, they could do things that their OSS equivalents could not.
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.
JJ has a good chance, because it builds on top of git, not replacing it abruptly.
I was just thinking that. I first started using Git to interact with Subversion repositories as a better svn than svn, and I'm surely not the only one.
git's replacement won't be there because it was better at being what git is (too entrenched), but because git became redundant as the world changed around it. As agentic development takes over and people stop caring about source code, all the tooling (including languages themselves) and approaches to assist humans will be ripe for replacing with those for machines.
Exactly. Big “generals always prepare to fight the last war” energy.
I mean it worked out for Astral who made open python tooling and got acquired by openai¹ maybe it's a new legit strategy now
1 - https://openai.com/index/openai-to-acquire-astral/
But uv is a (very-) nice-to-have tool, not the foundation.
Also, uv is open source, and can be forked if the company behind it decides to close it (see Terraform → OpenTofu, etc).
surely you've witnessed the backlash to uv as a result though
I personally feel that:
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.
Gitbutler is backed by git. Gitbutler is essentially just ui for git which also allows you to have multiple branches. It isn't meant to replace git.
"Backed by" as in "running git under the hood", not as in "supported by the git organization". I'd probably use "powered by" in this case to avoid confusion
Not quite - it totally takes over your branching strategy and locks you into GitButler.
So.. worktrees?
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
Can agents not checkout different branches and then work on them? It's what people also do. I have a hard time to understand what problem is even solved here.
That has been implemented 10 years ago:
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.
Sooooo git worktree. It's exactly that. One repository dir checked out in different places with different branches.
Even before git has the worktree feature, you could just clone the repo again (shallowly if it’s big).
and worktrees too.
Which Claude literally uses.
‘Embrace, extend, extinguish.’
[dead]
Git is fine. I would like something better than fine though, especially for dealing with rebase/merge conflicts where I would say Git is mediocre.
What about a vibecoded replacement with emojis and javascript?
Surely $trillion "ai" thing can generate a better solution than one Finnish guy 20 years ago.
I would urge you to take a look at the founding team here, I doubt that they vibe coded this tool.
Rust! it’s written in rust and not javascript!!!!
Lol. Unfortunately VCs and ever-so-ernest founders are impervious to irony. Best to just let them get their grift on and just be happy it isn't your money they're boondoggling.
> Git is fine. I would like something better than fine though, especially for dealing with rebase/merge conflicts where I would say Git is mediocre.
You can define your own merge strategy that uses a custom executable to fix conflicts.
https://stackoverflow.com/a/24965574/735926
„Claude, merge these branches and resolve conflicts. Ask me if unclear.“
16M$ VC money saved.
So far I have not let AI work with git, because I preferred handling version control myself.
Does it work well for resolving merge conflicts in your experience?
In my experience, yes. It has done a great job of choosing which changes should be integrated based on context in the repo, too.
Not the person you responded too, but in my experience the answer is a big yes.
I'm sure that will go well for my formal model in a language that about 100 people use...
If only 100 people in the world are using this language, who are you even merging code with, lol.
Well, yeah, but Git is basically UNIX/POSIX or JPEG. Good enough to always win against better like Plan 9 or JPEG XL (though I think this one may win in the long term).
> 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 able to design the second (code is an end result, not the process of solving a problem).
> 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 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
> where Git's *default* merge algorithm gives you horrible diffs
You are saying it yourself.
> but with people throwing money behind it, there’s a plan to extract value from the user base from day one.
They'll start injecting ads in your commit messages, forcing you to subscribe to a premium plan.
Bingo
Why does it take $17m to beat Git?
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?
Apparently it takes $17M and a whole team full of people to do what one guy with a chip on his shoulder could do for free.
On one hand that’s true. On the other, the “one guy” there is, like, the guy who does impressive projects “just as a hobby.”
Yeah, it's really burying the lede to call Linus Torvalds "one guy with a chip on his shoulder".
"Why fund $17M towards development of an operating system, when Linux was made by one guy with a chip on his shoulder?"
While he's technically excellent (or so it seems on the outside) he's still just, like, a guy
Literally true if it's that one guy you're talking about.
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.
I'd be 1,000x more interested in a project with the official git maintainers' buy-in to leverage the alleged power of LLM development to bring all git's features into libgit2 (or whatever, but that's a starting point) and switch git itself over to using that as its backend.
I've twice in my career found reasons that git being (officially; I have no interest in dealing with another implementation with its own missing features and distinct bugs) a library instead of a messy ball of scripts and disparate binaries, would have saved me tons and tons of time. You can look at the stories of how Github was designed and built, or look at the architectures of other similar software, and see folks struggling with the same issue. You'll run into frustration on this front pretty much instantly if you try to build tooling around Git, which turns out to be such a useful thing to do that I've ended up doing it twice in ~15 years without particularly looking for reasons to.
(While we're at it, how about some kind of an officially-blessed lib-rsync with a really pleasant API?)
Uhh, to be fair, if the goal was only to recreate git from 2005, it probably wouldn't cost $17M. I'd hazard a guess that they're recreating modern git and the emergent stuff like issues, PRs, projects, etc. I've also heard that the core devs for git are essentially paid a salary to maintain git.
They're not though, they're using Git internally.
I'm not sure if I should take these comments seriously or as a joke...
Thinking it for bit it comes to "what comes after Git" and what does "Git" mean there.
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.
Linus built git in 8 days or something.
No he didn’t. He built a proof of concept demo in 7 days then handed it off to other maintainers to code for real. I’m not sure why this myth keeps getting repeated. Linus himself clarifies this in every interview about git.
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!
Those were not his ideas. Before Git, the Linux kernel team was using BitKeeper for DVCS (and other DVCS implementations like Perforce existed as well). Git was created as a BitKeeper replacement after a fight erupted between Andrew Tridgell (who was accused of trying to reverse engineer BitKeeper in violation of its license) and Larry McVoy (the author of BitKeeper).
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
I agree and that’s the point I was trying to make.
Linus’s contribution is a great one. He learned from prior tools and contributions, made a lot of smart technical decisions, got stuff moving with a prototype, then displayed good technical leadership by handing it off to a dedicated development team.
That’s such a good lesson for all of us devs.
So why the urge to lie and pretend he coded it in a week with no help? I know you’re not saying this, but this is the common myth.
He did what needed to be done. Linux similarly has thousands of contributors and Linus's personal "code contribution" is almost negligible these days. But code doesn't matter. Literally anyone can generate thousands of lines of code that will flip bits all day long. What matters is some combination of the following: a vision, respect from peers earned with technical brilliance, audaciousness, tenacity, energy, dedication etc. This is what makes Linus special. Not his ability to bash on a keyboard all day long.
Im specifically pointing out the false history that Linus god-coded git and handed it to us on the 7th day.
In reality, it was a collaborative effort between multiple smart people who poured months and years of sweat into the thing.
I seem to agree with you. The real story is a good thing and Linus made important contributions!
But he didn’t create git by himself in a week like the parent comments argue.
The point was only that Linus didn't build git in 8 days and alone.
That's just being pedantic for the sake of it.
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.
It’s not being pedantic.
The parent comments are arguing that 17million for git 2.0 is insane because Linux wrote the original in a week.
Except that’s not true. He sketched out a proof of concept in a week. Then handed it off to a team of maintainers who worked on it for the next two decades.
It’s also not pedantic because Linus himself makes this distinction. He doesn’t say he coded Git and specifically corrects people in interviews when they this.
Nah, on the 7th day he rested... On the 8th he apologized for his behavior having learned the error of his ways.
On the ninth he roasted some fool.
I wish we had old Linus back just one day to review some vibecoded patch to Linux. I’d love to hear him rant about it.
In a cave, with a box of scraps!
First off, I'm of course interested to see what the future infrastructure of software building next looks like.
> 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?
The only security incident I've had in my career was due to Git Butler - it committed temporary files into GitHub without me explicitly approving it! Of course, it was a private repository, but still, it became impossible to delete those secrets because there were plenty of commits afterward. Given the large file tree and many updated files in the commit, it wasn't apparent that those folders got sneaked into the commit.
So, I really hope security incidents don't come after Git!
Just a reminder that even if you managed to amend those commits and force-push, the commits would still exist and will be addressable given the hash is known.
Couldn’t you expire the reflog entry and prune the db to remove it entirely?
Can't they be purged if they are dangling and the housekeeping is ran?
https://stackoverflow.com/a/47771133/8662097
related: https://news.ycombinator.com/item?id=41060102 Anyone can access deleted and private repository data on GitHub
To all the salty people- the person cofounded GitHub. It's not the product that raised 17M, it's the person.
The issue is that the investors will want a return on that $17M at some point, so they're going to need to charge money for something eventually. If the revenue model is not obvious now, that only means they'll be pressured into something non-obvious later.
I was going to be snarky, but Scott Chacon is a serious person, so we'll see!
Scott is brilliant, funny, and kind, and maybe he could be serious if he ever needed to be serious... But I've never seen that in him.
I'm seriously funny...
He is Super Cereal.
I like what I see in the video, it would solve a lot of problems I end up having with git.
That said, I find the branding confusing. They say this is what comes after git, but in the name and the overall functionality, seems to just be an abstraction on top of git, not a new source control tool to replace git.
For a long time I couldn't decide if Git Butler was a real product or a very elaborate joke to get devs to type "but rub" into their terminal.
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.
I actually believe we need to rethink Git for modern needs. Saving prompts and sessions alongside commits could become the norm for example, or I could imagine having different flags for whether a contribution was created by a human or not.
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.
Idk how git works under the hood but those both seem like they could both be easily accomplished with git itself .
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
Actually, it is. We're currently leading a conversation among several players in this space to agree on a metadata standard that helps make attaching, collaborating on and transmitting information like this simple, extensible and scalable.
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.
What do people expect to do with these saved prompts/contexts? Nobody is going to read through them, right? I suppose the thinking is LLMs will, but any decently active codebase will soon contain far too much context for any current LLM. Is this the same thinking behind cryonics, ie. we may be able to use this stuff one day so let's start saving it now? Hoarding has ruined many people and it will ruin us all if we're not careful...
For me the reason would be to preserve traces of intentionality (ie what was the user trying to achieve with this commit?). These days a 10k LOC commit might be triggered by a 100-word user prompt, there is a lot more signal in reading the prompt itself than the code changes.
I mean, it's just text, so it shouldn't be too taxing to store it. I agree it's hoarder mentality though :)
remove the existing code, add feature to the prompt and re-generate everything, probably
>Saving prompts and sessions alongside commits could become the norm for example, or I could imagine having different flags for whether a contribution was created by a human or not.
Yes, it could have syntax like
and then the tooling could attach any metadata to it that is desired.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"
> I could imagine having different flags for whether a contribution was created by a human or not.
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.
Honest question. I love some of the additional capabilities and specifically the dependency commits, virtual branches, and JSON output...
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?
There’s no business in working with an existing community to add functionality. And hence, where do you think the full time developers working on the project would get their livelihood?
Yes you could add all these things to git, but no, nobody will give you $17M to do it, nor will you find competent engineers who are willing to work for whatever funding they can find for “improving git”, which in all reality will probably round down to 0 in comparison to several software engineer’s salaries.
Unless one wishes to control the entire ecosystem rather than simply participate in it.
The source code is hosted on Github: https://github.com/gitbutlerapp/gitbutler
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.
I'd like to pretend that inability to render large diffs is a feature. Nobody is going to actually read the multi-thousand line diff; you need to make smaller PRs, or just admit that the diff in that particular view isn't helpful. I doubt that's the actual reasoning, but I can live with it.
> I am tired of using and waiting for alternatives of, Github.
Are you interested in giving https://tangled.org a try? I'd love to hear your thoughts!
Wow. So much hate in the comments here. Of all the funding / equity events lately, I wonder how this one gets so much doubt and distrust from the start.
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.
There is nothing inherently special about the straw that breaks the camel's back.
Why do they need $17m to build this? Vibe code it in a couple weeks, ship it.
Nothing in this project looks vibecoded. I compel you to try vibecoding this in a couple weeks if you think it’s possible, and then after that to build a business out of it. If the only thing stopping you is the code, you should give it a try.
idk what this guys can come up with, i mean anything beyond git is a bloated mess that no one wanted to use, just look at gitlab
Git just works. If you're not really familiar with it, you can use a free UI. If you don't know anything about it, AI like ChatGPT or Claude can help you commit or even teach you Git.
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.
Git does not ‘just work’, hence the creations of jj and every git wrapper cli/ui in the past N years with serious traction (>100).
The amount of ~skepticism~ hate is astounding here!! People don’t even acknowledge that it’s written in RUST!!!!
The lesson is quite simple... don't over promise in the title.
Nowadays I just ask my LLM butler to "organize outstanding changes into coherent commits". No new software needed.
'Stacked PRs' are back on the menu with Claude, because changing something in PR1 isn't a massive time sync to get PR2-5 back in shape, as Claude can usually handle all of that for me.
i dont get it, watched the video seeing the "power" of using multiple branches at the same workdirectory etc. all i was thinking was ok they want to make it easy for coding agents work with multiple branches / feautres at once... Just that works already pretty well with git and worktrees... and agent uses the tools anyway... dont know what they want to build with 17M
I thought gitbutler was not a great name, but then I saw their CLI command name is "but"
> We've raised $17M to build something like git and bait-and-switch it later because VCs only exist to extract value and anything we end up building will be a shadow of a fart of how useful git actually is
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.
> I don't understand how anyone could think to replace git by raising money. The only way to truly do this is grassroots iteration.
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.
Claims about “what comes after git” aside, I really like the idea of virtual branches. Worktrees have a pitfall IMO that they don’t allow you to test changes in a running local env, meaning I need to commit the changes, close the worktree, and checkout the branch on my primary workspace to verify.
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.
I created a cli called spotlight-testing to solve this pitfall with worktrees. I hope it helps! https://github.com/mblode/spotlight-testing
jj is what comes after 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.
The remaining lifetime of a technology is proportional to how long it has already existed.
However good this new thing might be, however much better it might be than git - I don't like it's chances.
So many people in this thread started commenting before trying the product or even watching a simple video of what it does. It's like reddit, commenting based on title without any actual comprehension of the content. Shameful really.
Real question--- why does one of the GitHub co-founders need to raise 17M for a venture? I'm certain they could fund it themselves. Is this more or less a marketing play than anything else?
Why do rich people raise money when they already have money?
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?
So that when the venture inevitably fails, VCs are the ones that lose money and the founders get a nice exit.
Why are investors still investing in SAAS products like this? I've heard some investors made rather blunt statements about such investments being a very hard sell to them at this point. Clearly somebody believes differently here.
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.
Many investment decisions are taken by people who get cut of investment as fees.
Wealthy people don't have time to do all due diligence and vetting specially when random startups become unicorn.
It's obvious that GitButt wants to be bought by one of the AI providers so they can add it as a feature to their subscription.
If you think like that why invest in software at all; the AI will do everything?
Does AI make reading or writing stacked PRs any nicer? No, it does not.
> If you think like that why invest in software at all; the AI will do everything?
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.
It does though.. you don't have agents that can connect to github or wherever your git mirrors are and comment on PRs?
The comments stop me from marking MRs with bad issues as ready, but if reviewing it's not really helpful.
Maybe if I were reviewing some random dude's code, where I have no idea what he's been working on...
Don't you read the PRs?
Yes, but my agents also do.
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.
git isn’t Saas.
git ≠ GitHub
The article is about a $17M funding round for GitButler. Which I assume has some revenue plan that you might qualify as SAAS. Correct me if I'm wrong.
There seems to be a bit of a trend that dev adjancent open source companies with not much monetization strategy are being bought off by AI giants. Most prominently Anthopic bought bun, OpenAI is buying Astral. So that may be the exit plan too.
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.
Their product is a CLI.
jj is rapidly becoming the new standard for post-git VCS in my circles. I’d love to see more startups working on that.
I think Git specifically with jj is still a massively good tool. There are some interesting alternatives happening like Fossil with its auto commit which for single devs is probably realy nice. Or Pijul but thats very early stage.
Alternatively I had the idea of something that automatically syncs your current working progress similar to how Word and Excel autosave work. With a main "branch" thats never developed in and will only be merged into from synced streams. But that idea is nowhere near cooked out yet.
I failed to see why this would be something that "comes after Git" from a VCS perspective.
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.
Seems fine I guess. I'm not a fan of Perforce but it does have some features that git still struggles with and needs to address to break into new customers. This Gitbutler seems to address some of them but I can't say it really feels next gen.
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?
Could you explain parallel branches vs what git offers today?
If it's to enable multi-agent scenarios, don't worktrees (at least in the local sense) allow for this?
My understanding is parallel branches allow multiple changelists to be applied to a single workspace. eg you can have multiple WIP fix branches active in your feature branch workspace and not worry about polluting your feature branch with unrelated/duplicated commits.
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.
Genuinely curious about the collaboration model here. Git's biggest weakness isn't technical — it's that merge conflicts are a social problem disguised as a technical one. Two people editing the same file usually means the ownership boundaries are wrong, not that the VCS is.
What does "what comes after Git" look like for a two-person team vs. a 200-person org? The pain points are completely different.
> Imagine your version control tool taking what you’ve worked on and helping you craft logical, beautiful changes with proper context
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.
As long as this tool doesn't break "fast forward merge" and proper linear history and allows you do delete PRs unlike its GitHub progenitor then I'm happy.
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.
I thought git didn’t allow companies to use git in their name any more and grandfathered in girhub, gitlab, etc. How did this company get a trademark.
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.
Getting it is not the hard part. Keeping it in light of an adversarial, litigious contender is.
Those who don't understand git are bound to reinvent it. Git is fine as it is, with some porcelain and QoL improvements here and there. Some of the most capable devs I know use git + cgit for collaboration and they manage just fine.
X is hard to use because when something goes wrong you need to have a deep knowledge to figure it out! Let's build Y on top of X to make this easy! Now you just need to have deep knowledge of both Y and X to figure problems out. And it's gonna cost $17M to build Y. Deal?
Git isn't that old. I find it interesting people want to replace it by big money. Does this say something about the quality of git? Enough people also complain about that.
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.
Jumping on the bandwagon, Magit is raising $$$ to Keep Version Control Magical https://github.com/magit/magit/issues/5555
What "comes after Git" is not a proprietary solution developed by a VC-backed company.
I'm trying to estimate how much better than git a new system would have to be to convince me to abandon git and learn the new system
I don't know the answer, but I think it could easily be three times as good and I would still stick with git
How I'm using git/Github has changed with agentic coding. However, I'm not using swarms of agents to write code, so it's bit hard for me to decipher the JTBD of gitbutler.
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.
The title is misleading and click bait perhaps.
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.
I watched the demo video on the git butler home page and agree with the premises that:
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?)
I also concluded based on the video:
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.
Maybe the pitch is:
git is distributed. Decentralised improvement. Local computers and their users make changes. These steps of local added value are then centrally combined into a shared timeline. A single product. During the improvement the locus of control is local. Which means it is hard to harvest the knowledge of this local knowledge and replace it. And it's hard to make local users serve the central AI.
Not something you put in the public mission statement. Because you might get boycotts.
Hey, this is Scott - the guy in the photo who wrote this post. AMA.
I've been using gitbutler since 09/24. It was the first git GUI I preferred over the command line. Being able to separate local changes into separate branches, drag missed changes into a past commit, etc. made tidy development so much easier. It is a great tool and the hate here is wild. However, I find it less useful when agents code for me. The surgical changes GitButler made so easy became less relevant as agents touch so many files at once. Have you found the same? Whats your vision for how GitButler will make agentic coding better in the way it did human coding? Does it move away from the UI you have now to something else? Does the UI get relegated and it becomes a tool the agent controls? (I liked the agent integration but it didn't feel like an improvement over using codex/CC so I went back to using them directly)
Remind me, how much venture capital did Linus need to raise for building git?
Linus didn’t build git. He built a proof of concept and then handed it over to real maintainers that wrote real code.
Fair enough, but he created it and I don't know the names of the real maintainers (sorry). And I don't think these two are writing the code for GitButler tbh. Anyhow, main point still stands: git is used by millions with no venture capital funding.
Huh. I look at what it took to build Git to begin with[1] and have to wonder if the thing that comes after it is really going to be _that much_ better. Git came about because there was a need for it. I feel like GitButler came about because there was a need for funding. Maybe I just need to have my coffee before commenting.
[1] https://en.wikipedia.org/wiki/Git#History
I'm trying not to comment on too many of these, but this one is interestingly wrong to me, so why not indeed?
GitButler came about many years ago because I have been using Git for almost the full 20 years of it being around and I thought there could be a better way to do the things it's trying to solve for us. I want version control to do more for us, easier, faster and smarter. Git is still pretty dumb. Plus, now, 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)
There does seem to be a lot of jaded pessimism this morning (buck up, fellas!)
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.
I bet I should've had that coffee first :)
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.
Why is GitButler still using Git if Git is the problem?
> As a _single_ example - agents can't use interactive editors, yet _so many_ of the powerful parts of Git absolutely _require_ it. Agents can't interactively rebase, meaning they can't very effectively squash, amend, reword, reorder, absorb. They can't very easily interactively add. They are middling at best when it comes to stacking branches. Git is designed to send patches over email and agents are not concerned with that.
Why aren't these just patches to Git itself? Or a fork of Git. You're layering tooling on top instead of fixing the foundations? You say stop layering? But you're clearly still using Git because you're calling it GitButler. You're another layer, like jj and like GitHub's UI.
Git is awesome in lots of ways. As a data storage layer and as a transport protocol, it's pretty great. The porcelain was built for a different era and is slow to adapt. Originally, Git was meant to just be these primitives and everyone was supposed to write their own "porcelain" or SCM on top. We're doing that and then some - creating new standards for more metadata, real time communications, built in review, etc. If anything, we're going back to the original point of git and doing what Linus wanted other people to do in the first place - write a good SCM for their workflows on top of the foundation he started.
Is this actually replacing git, or just a new frontend for the same git stuff? In any case, I'll be interested to see if this still exists in a year, and if that $17M actually made it replace git
Git is pretty close to ideal for the distributed model.
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.
No shade on these guys, looks like a cool tool and I'll try it. However, I find myself doing large majority of my git operations using a an agent[1] or a TUI [2], and I rarely open a git interface. I can get everything done straight from the terminal.
I guess I can overcome the "what if I cannot undo" anxiety.
[1] https://getcook.dev [2] lazygit
Is anyone from GitButler reading this?
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?
Apparently what comes after git is git
No CLI installer for Windows.
App itself for Windows won't proceed past my selected repo. Said something about bad permissions, but I use that repo every day.
> Imaging being able to work on a branch stacked on a coworkers branch while you’re both constantly modifying them
I think that's something I don't want to imagine
Makes sense. Git solved versioning, not collaboration at scale. Most real pain today is juggling context across PRs, tools, and now agents not writing code.
Doesn't jj basically do all this and more?
Humm at a quick glance git was functional enough for the linux kernel after 2 people worked on it for 4 months. That doesn't really add up to 17M.
I do not understand the problem solution, but if anything with git, I would want Codeberg style. I moved to gitlab and they were soldout and I am back on github slowly transitioning out. Common sentiment I believe is we want git, but on our own terms, not another VC funded project to move in.
My only issue is the title. It appears they are building a replacement for GitHub of which a replacement for Git is just a component. Building a replacement for GitHub is going to need at least the sort of funding they are mentioning. So once one reads the article it makes a bit more sense.
Some others mentioned pijul, but I will put in my two cents about it. I have been looking to make use of it because it seems really nice for working with an agent. Essentially you get patches that are independently and can be applied anywhere instead of commits. If there is ambiguity applying a patch then you have to resolve it, but that resolution is sort of a first class object.
I can't see any significant difference between their "Operations Log":
https://docs.gitbutler.com/cli-guides/cli-tutorial/operation...
and git's reflog:
https://git-scm.com/docs/git-reflog
Linus Torvalds was able to build this in a cave!
With a box of scraps!
the one feature which I have never seen in VCS is ability to stick commit message not just to all changes, but specifically to line/hunk. It looks like very intuitive for me - I don't want to invent "references style" to say something about specific changed line in my commit - I want comment this line directly.
The title mentions 'after git' but the video demo shows that it's very much tied to git and Github. The post also mentions the overhead of dealing with git, but the examples shown come with their own overhead and commands. I'm admittedly unable to see the appeal or just misunderstanding it, but the number of stars on the repo shows I'm in the minority.
Yes, I think that “after git” claim is just marketing. This is indeed just a nice frontend to git. It looks interesting and seems to solve real problems, in the same way that jj already does. But it is not a radical change.
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.
Linus built git in an afternoon with $17 for snacks
It was the early 2000s though, $17 got you like a weeks worth of snacks back then.
I watched the video but I don't quite get it. I feel like I'm missing something? A nicer git workflow is not what I need because I can ask an LLM to fix my git state and branches. This feels a bit backwards. LLMs are already great at working with raw git as their primitive.
I'm curious what their long term vision they pitched investors is.
I don't have to read the article to know that if it not just git with fixes and new features, it's not going to pan out. This is like building a new house because your current house needs a couple of leaks fixed and a coat of paint.
They need to have a dedicated page explaining me why should I change my current workflow. Else I don't get the point.
https://docs.gitbutler.com/why-gitbutler
Thanks for sharing. Parallel git branching seems to be a useful feature for me, given AI agents can be used work on multiple features at same time.
Why this and not jujutsu, pijul or sapling? These are all version control systems that are better than git in various ways.
This is is made for AI or ... something.
That money could've gone to something useful instead of building "git but better"
I feel like we’re over-capitalizing a problem that could be solved with better protocols. If the "Git successor" is just a wrapper to help agents not hallucinate their own worktrees, it feels like a very expensive solution to a context-window management problem.
I wonder what the development of git itself has cost in engineer time? Presumably more than $17 million? Assuming a fully loaded engineer is 250k, that only amounts to 68 engineer-years over 20 calendar years, which seems low.
LLMs have solved the Git problem without any need for other tooling. There is no learning curve anymore. You don't need to know any commands or even look at the CLI. You can explain in plain text what you're trying to do.
I was thinking- why on earth raise 17M for that, it sounds like something you make in a basement with a few friends, if that.
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.
“raise 17m to try to kill off and extract value from popular open source tool”
Pound foolish and folly
"What comes after Git" looks inside
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.
I'd like to see some kind of "whitespace aware" smart diff in whatever comes after git
There's `git diff -w`, and most forges expose a setting for that in their diff views.
Use difftastic. You can do so with current git :)
you can literally plug in any diff program you like into git and even make it extension-aware
So they're looking to replace something Torvalds built while steering the Linux kernel with no financial backing but they somehow need 17 million?
Sus.
I don't know about a new Git, but GitHub feels like the cruftiest part of agentic coding.
The Github PR flow is second nature to me, almost soothing.
But it's also entirely unnecessary and sometimes even limiting to the agent.
It’s weird because I could see raising money on the premise that GitHub is garbage, not git. But then you can’t say I co-founded GitHub as your bona fides.
Dunno what they’re trying to build, but I encourage everyone to try what they already have built. It helps me work on multiple changesets in parallel. This often just happens, for example you work on something and discover a bug in something else that needs to be fixed. In GitButler, I can just create another branch, drag the changes in there, push and done.
Also, if you ever worked with Perforce, you might be familiar with changelists. It’s kind of like that.
Now, GitButler is by no means perfect. There are many rough edges. It tends to get stuck in unexpected states and sometimes it isn’t easy to rectify this.
It also cannot split changes in a single file, which is a bummer, because that’s something I encounter routinely. But I understand this complicates the existing model tremendously.
Most of the comments here are clearly from people who haven't used GitButler. Try it out and it's a very sticky product, clearly superior workflow to vanilla Git.
> That’s fundamentally what is behind this round.
Drop the “fundamentally”.
“It’s cleaner that way.”
GitHub CEO also raised 60M for 'entire' to bring agent context to git. The dust is yet to settle here as it's difficult to bring a paridgm shift from today's git workflows
Looks like almost as good as JJ but with VC money.
I looked at the demonstration video and closed it after a couple of minutes. I don't see how this tool will replace git.
Well, I think it won't
Isn't that jj? Hopefully no one tells the VCs.
To me jj is an ok porcelain for git, but I find it worse than magit. Sure, it has some tricks under their sleves for merging, but I just don't run into weird merges and never needed more advanced commands like rerere.
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.
Which version control system should we not tell?
Idk if you're joking but I edited to make it clearer...
I was :(
a16z
Ok, ok, if you give me $16M I'll do it faster.
Is $17M private equity enough to poison the initiative? Or is software-by-committee still the real project killer? Let’s find out…
This will just force them to build in some sort of revenue extraction model. Pass! Git and copyleft are fine as is.
The only thing I want is an as far as Claude Code can tell 100% Github clone running on my $5 Hetzner VPS.
> I know what you’re thinking. You’re hoping that we’ll use phrases such as “we’re excited,” “this is just the beginning,” and “AI is changing everything”. While all those things are true, I’ll try to avoid them and instead make this announcement a little more personal.
Refreshing. I am so tired of the usual PR-approved phrases that you read in every announcement.
Other than that, I agree with other comments: not sure what Git's problem is, and what they are supposed to solve. Star Wars' "it's a trap" vibes.
this is cool. i don't understand why the word git is in the name if they are trying to get (pun intended) away from git.
buthub has a nice ring to it
I was skeptical at first, but then I watched the video and it really looks interesting. I wonder if this works with Azure DevOps?
Anything that leads off with how much money you've raised is automatically disqualifying.
I love how whole article described none of the ideas they have for product, just buzzwords
It's certainly a choice to lead with the funding and a photo with a venture capitalist.
"We’re not building some “better git”.
We’re building the infrastructure for how software gets built next."
Dude, aside from this type of phrasing being cringe, it's such blatantly obvious LLM induced psychosis phrase... ridiculous.
I didn't even read that insanely long article explaining why one would need this (the necessity should have rang one or two bells for the author)... but all i could think of before reading that cringe ending, was: you're building what comes after git, but carry "git" in your name seems kinda odd... already revealing you either don't believe your own claims, or you do, but don't really mean what you're claiming... either way: WTF. Insane what's getting funded.
Also: the trend of companies overly feeling the need to explain they're not just X + AI (which also means LLM API), should really ring a lot of other bells to everyone else... god damn, too many bells to ring... and it seems like there is only AI chatbots left, that respond to anyone ringing the bell... god damn... they already took over & infected the human brain...
If you are building for what comes after git, why name it git?
Great! Instead of solving actual problems we are seeing funding for stuff we don't need.
How do you intend to make money ?
Easier Git doesn't translate into something I can get my boss to pay for.
Rather confusing, your name has Git in it, “to build what comes after git”, what comes after your own Git product? Good luck.
Clearly butler comes after git.
"Gitbutler", really rolls off the tongue, doesn´t it :) Oh and the irony of raising $17M to "replace" a tool which kinda...does not need replacing at all? How about replacing some of the entshittified services, like Google Workspace? Now that would be worth the $17M raised.
First time I heard of gitbutler, is this like gitk? If anyone remembers gitk
Improving something that basically everyone uses is obviously worth money
For $17 milion there are few thibga without any gui that i couldnt build.
Wow, very impressive, great job! You mentioned monitoring, I think it might be a very interesting way to see the "ongoing" work of your agents and orchestrate them. Do you have a precise idea on how it's going to happen, or is this already planned?
The title is misleading, it's not a git replacement
How much money did they need to raise to make git?
> I know what you’re thinking. You’re hoping that we’ll use phrases such as “we’re excited,” “this is just the beginning,” and “AI is changing everything”. While all those things are true
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.
Ah, I see. You missed the part where that was funny.
How many millions were raised to build Git?
It’s called jj
There's definitely a need for this, but the underlying reason there's a need for this is so beyond me. I've worked with a lot of Software Engineers over the years, even at FAANG, that didn't have a good technical understanding of git (basically, your repo is a tree structure, most commands are just about manipulating that tree in some way). I mean, just spend the hour to go through a git tutorial. There's so many great ones like the interactive one that shows the tree as you go through the levels. It's your profession. Also, I think another layer on top of Git as this seems to propose won't fix it -- once something non-obvious happens, these people continue to be stuck.
Blog post written by llm.
No thanks.
Was their series A pitch also written by llm?
I would like to take this opportunity to kindly inform you that I wrote that post, as I write all of the blog posts on our blog (and everywhere else I write). You will never see something with my name on it that was written by AI. Thanks.
Meanwhile CVS just keeps working fine...
A lot of blood in the water for Github.
Raising a bunch of money to recreate the wheel.
gitbutler is actually a great product tbh
> I may have even had a small hand in some part of that.
Quite an understatement. I'm pretty sure GitHub is the primary reason that Git took off like it did.
Could be I live in a bubble, but I don't use git because of GitHub or with GitHub that much. No doubt, GitHub is/was great for distributing software but I feel we'd still all be using git without GitHub
Practically no one was using Git before GitHub (except Linux). Subversion was much more widespread.
Subversion was (and is) an admirable project, and filled a void by being much better than CVS.
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.
The initial version of Git was written in two weeks, what do you need $17m for?
I'm still not convinced we need a replacement for git.
> 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.
That's a lot of money for something very much not necessary... I'm in the wrong business!
Pijul?
Git has issues, but it works pretty well once you learn it and it's basically universal. Will be hard to dislodge.
please also build it for easy multimedia management
Jesus this website is overstimulating and it's extremely difficult to understand. What the hell they are selling other than a UI on top of Git? Git works perfectly fine especially if you take an hour or two to learn how to do a few more complicated but useful workflows (rebasing, cherry-picking).
Github fallout effect?
those hairlines. like father and son.
There is only a tiny final step left, a real piece of cake, to build the thing.
$17m to replace git with but. no fucking way
Real problem is how to cope with few billion of bots hammering APIs 24/7 saturating net cables, physical infrastructure and taking down platform with constant DDOS.
Im curious when it will be “SO BAD” we start blocking every AI agent on firewall level.
I refuse to use anything other than git for versioning.
Standard is better than better. For all of its flaws, I’ll take Git any day over any (better) alternative, because the value is in the absence of fragmentation. If a repo doesn’t use Git, I’m out.
Nothing needs to come after git. its perfect.
My impression from GitHub was always that it was nice to have someone else host Git repositories for free, and that the "added value" (the Web view, the user management, the CI, the Wiki) were all made by dilettantes: poor quality, mostly useless, never doing the right thing.
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.
But… why? (pun intended)
They raised $17M to build what appears to be solvable by some git wrapper scripts that could have been written by AI in 5 minutes?
To me the extra "wat" about this is that if I spend the sub-$1 to get the git wrapper scripts, I can get them exactly the way I want them, instead of being mandated to use the commands they made up. A huge gain for AI is the ability to have exactly the software you personally want, even if nobody else wants it just so.
So they are building the exact opposite of the need that AI brings forward. What they are building is not even median software that is in danger of being replaced (e.g. see Cloudflare spending a week to build "a wordpress"), but something that's the most extreme example of AI-will-replace-this that could possibly exist.
Who will buy this?
The only way this makes sense is as a plea for being acqui-hired (and the project dropped).
If you're building on top Git, you're not really coming after it are you - you're coming as well as it.
If you want to come AFTER Git... you need to not use Git.
From their docs:
> 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.
I like pijul's mental model much more but it's a single developer who's slightly prone to getting sidetracked.
You could have given Linus the weekend off.
$17M doesn't seem like enough for this. Perhaps for a prototype.
I started using Git around 2008, if memory serves. I have made myself more than familiar with the data model and the "plumbing" layer as they call it, but it was only a year ago -- after more than two decades of using Git, in retrospect -- that a realisation started downing on me that most folks probably have a much easier time with Git than I do, _due_ to them not caring as much about how it works _or_ they just trust the porcelain layer and ignore how "the sausage is made". For me it was always either-or situation -- I still don't trust the high-level switches I discover trawling Git's manpages, unless I understand what the effect is on the _data_ (_my_ data). Conversely, I am very surgical with Git treating it as a RISC processor -- most often at the cost of development velocity, for that reason. It's started to bug me really bad as in my latest employment I am expected to commit things throughout the day, but my way of working just doesn't align with that it seems. I frequently switch context between features or even projects (unrelated to one another by Git), and when someone looks at me waiting for an answer why it takes half a day to create 5 commits I look back at them with the same puzzled look they give me. Neither of us is satisfied. I spend most of the development time _designing_ a feature, then I implement it and occasionally it proves to be a dead-end so everything needs to be scrapped or stashed "for parts", rinse, repeat. At the end of the road developing a feature I often end up with a bunch of unrelated changes -- especially if it's a neglected code base, which isn't out of ordinary in my place of work unfortunately. The unrelated changes must be dealt with, so I am sitting there with diff hunks trying to decide which ones to include, occasionally resorting to hunk _editing_ even. There's a lot of stashing, too. Rebasing is the least of my problems, incidentally (someone said rebasing is hard on Git users), because I know what it is supposed to do (for me), so I deal with it head on and just reduce the whole thing to a series of simpler merge conflict resolution problems.
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.
no mentions of dura by nobody in the comments?
Good luck with that, I would still be using subversion if given the choice.
"We are going to spend $17M and have nothing to show for it"
> Proprietary git wrapper with pay-to-play "enterprise" gating
Oh boy. Thanks for the nightmares.
Bros wanted to work on dev tools. They sold it to VCs as "AI tools" to get easy money. Well played!
I really, genuinely, do not want a replacement for git developed by a company that raised money to build it, since it will inevitably be a walled garden of one kind or another that enshittifies as it tries to make the money back. Git is fine and there is one thing no VC funded effort can get: freedom from the vampires.
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.
No. Just no.
Leave Git alone.
I continue to be amazed at American capital allocation. $17M for an idea to improve Git? For a fraction of that money Ukrainian housewives build anti-drone air defence systems in their garage that protect their country. For that kind of money you could build an apartment block to ease the housing shortage. You could invest in electricity resilience and build mini nuclear power plants or a small wind farm. Soviet capital allocation: while they were pouring money into their space program and building the "biggest baddest military helicopters" there wasn't enough bread in grocery stores.
It’s not 17m for an idea to improve git.
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.
So it's gambling that they can extract money from open source project, by repackaging most of the existing features through a nice UX and hope business gamble their tech stack on it.
Great use of 17 million dollars.
I wouldn't say "buying software that saves us time" is gambling, but you do you.
It’s just gambling without the stigma of being called an addict.
After a decade of negative interest, there is still a lot of excess capital looking for high-risk-high-gain investments. Perceived future economic value is unfortunately not in the stuff we know and understand to be useful, essential.
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.
Oklo’s Aurora was budgeted at around $10 million to build, with about $3 million/year to operate
You'd have thought the same about all the big tech companies when they were startups. Yet now they're making piles of money and contributing to America's overall economic success.
Back then the landscape was a different one.
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...
> For every unicorn there are tens of thousands or even hundreds of thousands dead horses...
Nicely put!
There are dead horses and unicorns, which turns out to be better than just living horses and no unicorns like Ukraine and Europe are more like.
I don’t understand the negative sentiment here.
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.
The problem is they’re pouring insane amounts of money into non-problems. I use Git every day. There’s no problem with Git. Real problems that people suffer with everyday like healthcare and housing and even defense are doing so pitifully and we’re spending $17M on improving Git? If you don’t see the ridiculousness you really are in a bubble.
But then again, for a fraction of the money US-Americans pay for health insurance, we actually have public health insurance here...
Yes, we have higher taxes, yes, we pay more in social security... but in the end we have far less "Working Poor" and I know very, very, very, very few people who have more than 1 job.
But I guess that's just socialist bullshit.
What I am trying to convey is: The US lives in its own bubble, just like the rest of us does.
The difference is that the US hears the US propaganda and the rest of us heard the US propaganda for decades as well, through Hollywood and media.
Europe is far from perfect though. In all the three countries I'm familiar with (UK, Sweden, Spain) the healthcare system is really struggling. Extremely long wait times are becoming more common, for more procedures, even in the emergency departments.
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 wholeheartedly agree with that sentiment. We are definitely heading in the wrong direction. It's the same development here (not UK, Sweden or Spain)
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)
Long wait times are increasingly also a major problem in US healthcare, so I'm inclined to believe that the root causes behind wait time problems aren't related to public vs private insurance systems.
The worst part about what I see here is the inequity or imbalance of what we're seeing about where money gets allocated, and the material effects of what that inequity brings about. It's not "I have a good idea and a great team" it's "I am X, or know Y" and... ugh.
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.
> 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.
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.
[dead]
I feel like I really need to learn how to raise money. For $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. Parents worldwide would love it.
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?
Money is not given to good ideas (though, it doesn’t hurt). Money is given to friends. If you look at how VC (or really any network) funding circulates, it’s just people who are allowed to enter that circle and money just flows between them constantly. On one hand, you have trusted people who you are willing to give money, on the other hand, this inherently creates a clique.
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.
Another thing I've noticed is how when you go on the website for a VC funded B2B startup and look at the customers or testimonies they have listed, most of them will be other B2B startups funded by the same VC. It makes me wonder how much of that market is essentially a few friends standing in a circle and passing a $100 bill around, but on a larger scale.
The founder of GitButler is the co-founder of GitHub. It doesn't matter what he builds, the VC is going to throw money at them.
The reason “ideas don’t get funding” is usually (but not always) true is that usually a good idea alone doesn’t mean much. So usually you have to have good idea plus something else the investor feels is a proof point or evidence you can execute.
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.
Ideas shouldn’t get funding - ideas are just mere results of thought that haven’t been played through in depth.
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 friends."
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.
It hasn't been organically popular here[0] among people who would be forced to actually use it, so they have to build hype from investors instead.
[0] https://hn.algolia.com/?q=gitbutler
> money just flows between them constantly
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.
I don't think describing them as friends is entirely correct. People give money to people they trust. And friends often are in that subset of people. But that's not a strict requirement.
They trust people who look and smell like them or the people they golf or drink with or are part of the same fraternity or tennis club.
I'm sure VCs give money to friends but I didn't know any investors when I raised millions. They invested money because they thought it was a good idea.
More like an idea decently likely to be resold for more.
Good ideas are a decent subset, but you could also have a bit of "Greater Fool Theory" compliant ideas.
> Money is given to friends.
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.
That works under the assumption of the "wisdom of the markets", and we assume VC possesses that wisdom, but laid bare it's just as vulnerable to cronyism as any other institution.
Yeah, OK. There’s a lot hidden in that word, “pedigree”.
So it will be exactly like git, but with a monthly subscription fee.
or at least should be
This is the way!
> ... and sort LEGO bricks by colour
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.
As any DBA worth their salt knows.
Index the many valued column, not the column with few discrete values.
Are you sure that's a good strategy if every unique index value requires you to buy a physical container?
As someone who tried to sort many lego sets lately, I do like this. The problem lies that modern lego has so many unique forms that it feels like you'll have many bins with one or two pieces in.
As the “Disturbing the Piece” podcast points out - you “sort” the good important parts you want easy access to and you “bin” everything else in the giant box you can dig through if needed.
https://youtube.com/@disturbingthepiecepod
That's why you buy different sized bins, and then you can even combine some forms into one bin (but be careful not to combine similiar forms, this counters the goal).
You need to get some bins that have a top shelf like a toolbox. The low item counts go in the top shelf, segregate the bottom for efficiency. Bin by color.
Just keep those in a single bin
counterpoint (don't take this to seriously):
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.
That's why you have to group similar forms. - Bricks - Plates - Narrow Plates - Wheels - Windows/Doors - Smooth pieces - People bin
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
There are less different forms than any normal brick enjoyer has bricks of a specific color. Therefore the lookup is faster ;)
Unfortunately there are so many bespoke LEGO brick forms that this doesn't work.
[dead]
> Why is nobody solving actual problems anymore?
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.
people love solving problems, but most solutions are not VC fundable (fortunately/unfortunately)
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 problems are in fact that...
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.
The author is a founder of GitHub, he could raise $17m for “git but it’s called pit and a repository is a hole and committing code is called burying it” if he wanted to, investors care about pedigree.
pedigree is a great word here and being upfront about it (if true) would make for some fun VC slogans:
"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."
I would use this tool. Ship it
[dead]
> I feel like I really need to learn how to raise money. For $17M, one could probably ...
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.
Is it unrelated though?
> 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.
Investor narrative pointing out a relationship is not the same as substantive technological overlap.
HN has always been skeptical of VC, ironically, so that's no indication of anything in the overall industry.
HN is not a hive mind with a single opinion. You get the extreme opinions of both sides and every nuance in between. There are people here who despise VC and people who live for it and think it’s the greatest thing since sliced bread.
For what it's worth, that LEGO vacuum does exist[0], it was on Shark Tank[1]. I assume they stole the idea from The Office. It doesn't sort the bricks, but I assume that was more of a stretch goal based on the insane amount of money being discussed. After all, the LEGO vacuum only cost $495k to get to market.
[0] https://pickupbricks.com
[1] https://www.youtube.com/watch?v=X25MIpQqLIU
That one needs to be operated manually. I was thinking more along the lines of robot dog + OCR + 6 dof arm on the robot's back.
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.
> EDIT: BTW did you see that the page you linked to has this at the bottom of their landing page:
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...
Roborock Saros Z70 is about a year old:
https://us.roborock.com/pages/roborock-saros-z70
https://www.youtube.com/watch?v=I0AGhb6p8sE
i noticed the example product page too on their website. But why not make it like a bigger rumba on wheels?
> 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.
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.
Yeah it also sounded to me like they just want to extend git. Zed is trying the exact same thing.
Neither of them is doing to be remotely prepared for what I'm going to do, which is actually replace Git.
I like git, it works perfectly fine on my command line.
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.
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:
Docs: https://git-scm.com/docs/git-format-patchWhich 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.
You are right, PRs are not in git. format-patch and request-pull are originals designed for mailings lists. Github just put UI on top.
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 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.
I would argue that it was purposefully designed in contrast against that model.
GitHub is full of git anti patterns.
> or whatever GitHub and the like are called
GitHub is a social networking site that just so happens to have code hosting related features.
People keep saying this but I can't really find much anything social about GitHub.
Sorceforge predates git by about 11 years. As do several other projects like google code. Its not a new idea. Or basically most source control systems. Git, actually, is the more unique idea, of a DVCS... versus a cVCS...
git is not a new idea, various features of git existed in various SCMs for decades. The distributed aspect existed in Bitkeeper too, for example.
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.
À pull request is just you requesting someone to pull from you in git proper.
So the maintainer adds you as a remote and pulls from you.
There’s really nothing resembling a “pull request” that’s used by 99.999% of git users. We have merge requests. But we call them pull requests for some dumb reason.
Indeed they're not; they live on the 'user layer' rather than the 'application layer'. That's not to say many git-frontends (IntelliJ, Sourcetree, Github desktop) don't support them, but "git pullrequest" isn't a thing.
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.
> mentioned below (file:///C:/Program%20Files/Git/mingw64/share/doc/git-doc/git-request-pull.html)
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.
"Pull requests" are part of git though since it was originally a DCVS it meant you would pull from an individuals git repo ... services like github etc centralized the concept
They sure aren’t. Before github you set up remotes or emailed patches.
Perforce had change sets and there were lots of tools for code reviews that worked a lot like GitHub before GitHub (review board, phabricator, another one I can’t remember).
> I feel like I really need to learn how to raise money. For $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. Parents worldwide would love it.
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.
Not to shoot down your comment with sarcasm, I'm being really honest: I changed my shower gel with an expensive one this week, and it really had an unexpected, exciting effect. Small stuff can really have consequences much bigger than themselves.
That said, if you ever decide solve the tidying the toys problem, start a kickstarter, I pledge to pledge support! :D
I find that sometimes changing the font in my IDE can give me an inexplicable boost
i may be dense or something but what effect?
It smells better, my skin feels better after using it, and I feel happier. Showering may take little time, but I have my skin all the time :)
Some people are not sensitive to quality. A car is a car, a shower gel is a shower gel, etc. In the computer world, they curiously congregate around Microsoft...
Thing i learned about raising capital it, you need to build or have a network. Thats YC is great, accelerators, incubators help you do that. Network and story you tell. Also, every stage you raise, you have to make sure the folks you raise from help you craft the narrative for thr next round.
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.
> I think if you have a healthy busy growing well, you shouldnt raise unless you have ambition and urge to go faster.
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.
VC by default are founder friendly in my experience.
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.
> I think if you have a healthy busy growing well, you shouldnt raise unless you have ambition and urge to go faster.
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.
I am twice your age so i would assume i have some wisdom here.
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 think if you have a healthy busy growing well, you shouldnt raise unless you have ambition and urge to go faster.
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.
If the business is not growing well and VC invests money. I think that gambling and not true venture capital.
> 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. Parents worldwide would love it.
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.
Roborock released one of these about a year ago. It doesn't do as much as they want, but it can pick up things and put them into designated locations, shoes being the main example.
granted how much did Linus spend on Git? probably well south of $17M and he's not beholden to the likes of a16z
The first version was written in ten days apparently, so more in the ballpark of $17k.
I want people to read this sentence from https://www.linux.com/news/10-years-git-interview-git-creato...
> 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.
at the time he was probably thinking about how much time it would _save_ him
>Why is nobody solving actual problems anymore?
They went over this, in the documentary titled "Idiocracy".
https://www.youtube.com/watch?v=GFRzIOna2oQ
GitV2 - It's what Devs Crave.
> sort LEGO bricks by colour and size
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.
Unsure if you want the real answer, but the financials on gitv2 will be much more appealing to a VC. Hardware is hard, slow, expensive, risky. Finally, China is the place to build physical things not the US.
What would "the financials" be on a git replacement? No one makes money on git itself. Probably not much even on the services around git, given that Microsoft funds github for its own reasons, and gitlab is constantly running out of money.
17M seems like a rounding error these days with all the AI investments. Probably some spare cash in a fund that needed to be closed or something.
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.
Not to mention the irony that they need $17M to try and recreate/improve what Linus built in a week.
That’s not really fair. That first week prototype was proof of concept, not the Git we use today. It would easily have taken $17 million for a private team to put in equivalent work to all of the open source effort that has made Git into the tool we have today.
One reason I don't read HN as much as I used to is because I can't help translating numbers like that into the amount of research that could be accomplished with the same amount, and then I get angry.
> Why is nobody solving actual problems anymore?
Because that’s too risky for investors.
VCs have no clue. They have money and therefore they are in a dominant position. Everybody around them (professionally) is trying to flatter them and convince them that they should invest in their project.
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).
In fact, a certain amount of investment in frauds is acceptable and desirable; if you give £10m to 9 frauds who spunk it straight up the wall and to 1 true visionary who builds a unicorn, that's money well spent. Plus of course you can always hope that the fraudster is good enough to sucker the next guy so you can get out.
Per Matt Levine, the optimum amount of fraud is non-zero. Tune your detector too loosely or too tightly and you'll miss out.
The optimum amount of fraud is non-zero only because detection is expensive as you get close to zero. Getting less fraud needs to always be in mind. When someone gets away with fraud others will try to copy it so anything that has happened before has a much higher value to detect.
But for fraud that hasn't happened yet don't worry about it and hope nobody figures out how to do it.
An expert on crisps maybe XD? i'm not really sure about your last point on investing in frauds, i guess they only care if and when the fraud gets exposed, they might purposely choose to do exactly that given the right conditions though, it is a completely perverted and deranged system at this point.
Yeah sorry, I was saying "frauds" for "bullshit", I guess? Lacking some vocabulary to express this in a nuanced way.
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" :-).
> But instead, we get a replacement for Git. [...] Why is nobody solving actual problems anymore?
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.
> 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)
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/
As someone who makes things it always confuses me when millions just disappear whenever a company or government contractor makes things. Give me $17M and I'll build a vacuum robot prototype in under 2 years, I can't imagine 10 engineers getting paid $100+k/year can't do it in less time? Tooling is expensive, but not THAT expensive...
I would agree. CNC-ing POM also tends to work extremely well for prototype plastic parts.
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.
Get it approved in a lot of large markets? Deal with ongoing supply issues as suppliers change and you need to maintain your product? Market it? I could keep going on, but making a prototype is the easy part, making a sustaining business out of it is the hard part.
You sure? You ever ran a business? Prototyping costs, machines, licenses, overhead etc. etc.
For $17 mil you can't replace Git either. Can't get it done.
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.
But we are not even get a replacement for git, we are getting a CLI on top of git. Since agents can use GH CLI and mcp very well, I'm very interested to see what is it that Git butler can do so much better (I also might be a bit sceptic, but I'll give them the benefit of the doubt).
> Git butler can do so much better
Not be tied to Microslop and migrated to Azure?
Sounds like great use of 17M.
>Scott Chacon is a co-founder of GitHub
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
> I feel like I really need to learn how to raise money
Well, cofounding Github helps
On the other side, people who were using, say, Perforce, also thought there can't be anything better. Still, BitKeeper appeared as an innovation in the area, eaten later by Git, created by angry Linus (because of BitKeeper licencing changes).
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.
> For $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. Parents worldwide would love it.
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.
@fxtentacle I’m at the airport and spat out my coffee reading your comment .. this is legendary and super funny ! Happy Friday to you kind sir
Solutions to more actual problems are more expensive. It’s easier to ask millions of people for $0.01 than it is to ask thousands for $100. Things that are easy to sell to millions of people for $100 are rarely innovative (transportation, food, entertainment, etc), and if they are, they’re world-changing (cars, supermarkets, smartphones, etc).
You see, the actual problem is raising the money.
Totally agree - most of these co's that get funded are pointless. FWIW, the general math here is that you'd spend < 2-3mm developing new git and most of the money goes into distribution.
We've strayed really far from where technical innovation began
To be fair, discovering a new shower gel that smells better or feels better is a nice experience.
It's primarily focused on "take from someone else" rather than create something new and useful.
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.
I think it’s always good to dig a bit deeper on these things.
This seems ridiculous to you, compared to a very obvious win with a Lego sorting vacuum.
Lego isn’t niche, and the explanation isn’t a weird technical thing that only experts would get and understand how important or valuable it is.
Yet it’s not being done.
Is there nobody who has realised this gap but you? Has nobody managed to convince people with money that it’s worthwhile? Have you tried but failed?
Or is it not many many thousands of people who are wrong but you?
Is the problem harder than you think? I’ve worked with robotics but not for a long time and I think the core manipulation is either not really solved or not until recently. I don’t know about yours but my kids also don’t fully dismantle their Lego creations either so would the robot need to take them apart too? That’s a lot of force. And some are special.
How people want Lego sorted is pretty broad. Kids don’t even need it sorted that much. And the volume can be huge for smaller buckets of things.
Is the market not as big as you think? Is it big enough for the cost, I’d buy one for £100 but £1000? £10,000?
How does it compare for most people against having the kids play on a blanket and then tipping it into a bucket? Or those ones that are a circle of cloth with a drawstring so it’s a play area and storage all in one? I 3d printed some sieves and that’s most of the issue right there done.
People are solving actual problems, but lots of problems are hard, and not all of them are profitable.
As a gut feeling, there is such a large overlap of engineers and large Lego collections and willingness to spend lots of money and time saving some time sorting Lego that the small number of implementations usually split over many years is very telling about the difficulty.
For what it’s worth I want this too.
Hasn't someone already built that robot? At least my kids tell me this exists every time I tell them to clean up their Legos. Actually it just does Legos, not the general toys.
Git is still pretty lacking in the area of big files. This is quite annoying if you're dealing with big deep learning data. So your LEGO vacuum robot could actually benefit from a better Git.
Didn’t dvc try to fill this niche and absolutely fail at it?
When the sock bot dries the socks, matches and folds them together we're at peak robot. Come to think of it, its got to not lose either of them also. Current tech falls short of this.
> When the sock bot dries the socks, matches and folds them together we're at peak robot. Come to think of it, its got to not lose either of them also.
Missing socks (and containers or their lids) are still great unsolved problems in 2026. Solving this issue is like fusion, always 10 years away.
I feel exactly this way
Why are we trying to replace git? What is the problem with git?
It's the old broken. Clearly it must be replaced with the new hotness.
The same reasons the world needed AI for cats funded to the tune of tens of millions of dollars. How do you expect those precious people to do anything at all without a bi-yearly expenses-paid trip to Cabo and on-site baristas?
I feel like git started to feel outdated overnight as the company I work for went agentic development first.
I fought for years trying to convince my colleagues to write good commit messages. Now Claude is writing great commit messages but since I'm no longer looking at code - I never see them. I don't think Claude uses them either.
Branches are now irrelevant since all agents work in worktrees by default. But worktrees are awkward since you run out of disk space fast (since we're in a monorepo).
There is a constant discussion ongoing whether we commit our plans or not. Some argue that the whole conversation leading up to the PR should be included (stupid imo).
The game changed completely. It isn't weird that people are wondering if the tools should as well.
Definitely feels like there's opportunity to build something better
You guys cannot be serious, it feels like Poe’s Law day everyday in here!
It really is insane how much this topic is dividing technical folks.
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 have to agree that the comment you are referring to seems to be nothing other than sarcasm despite that it doesn’t read that way at all. If it’s true, the world is definitely in trouble…
if you can't get ai to handle git, that's certainly a skill issue
Have you considered returning to actual software engineering and workflows that tools were designed to support instead of playing the LLM slot machine?
Funny the replies you're getting here when already we see companies with engineers not having written a single line of code since late last year when models became good enough to go end to end.
We see companies running web apps on top of Oracle or not using any version control at all, let alone agentic coding; it doesn't mean it's a good idea because someone is crazy enough to do it.
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.
You mean the one they try to build in The Office?
I ask myself this all the time, I have ideas now and then that I need to start writing down. Its just sad, we have so much potential as a society, but all the money goes to things like AI and bitcoin blindly. While I love some aspects of AI, and hope to someday be like the Jetsons and have a robot in my home that helps with things, and frees up me and my wife to doing other things with our family, I also don't trust something that is feeding my most intimate events from my home to a server somewhere.
You missed the boat, baskets that open out into a giant play mat have flooded amazon and temu. Something like this:
https://www.amazon.co.uk/Toy-Storage-Organizer-Lego-Play/dp/...
I've long had the same idea.. this one has legs.
4 McDonalds. That’s a better way of measuring it.
Honestly it is. Investors value my company like 4 Mcdonalds.
Exactly. A safe bet vs a great bet.
I’m also contemplating a lego sorting machine.
jacquesm did that impressively 9 years ago: https://jacquesmattheij.com/sorting-two-metric-tons-of-lego, https://news.ycombinator.com/item?id=14226889 (follow-up posts with more details: https://news.ycombinator.com/item?id=14280569, https://news.ycombinator.com/item?id=14654223).
It doesn't solve the picking-up-off-the-floor problem.
Definitely sounded like a shower gel moment.
It’s probably because you’re not willing to lie enough. There was some founder back in the 2010s, I forgot his name, but he’d go around giving talks on fundraising and he basically said he just lied all the time.
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.
i am actually fine with how svn works.
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.
The vast majority of git users are using github as a central repository. There a a few other not github but serves the same purpose central repositories. Distributed sounds cool, but almost everybody wouldn't notice a thing if git was centralized.
u guessed right. im one of the world's few solo software developers left (behind).
or using branches.
> i am actually fine with how svn works.
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.
> To a first approximation, one could say that distributed version control is a problem nobody ever had, and nobody ever intends to have.
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.
Well, one person did: git exactly replicated the patch email system that Linus Torvalds was using.
you just need pedigree. any kind. where you went to school, where you worked etc.
Yes!
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).
You're fine with how git works, many others aren't.
I am actively looking for a replacement for GitHub and would prefer something that is not based on git.
I for one can't wait for open Ai to buy them and reroute every git commit to chatgpt.
Don't do that. Don't buy into the bullshit.
17M isn't a lot of money. It is for a person sure. Retire. Cessna. etc. But not to build a butler!
[dead]
Your kids need to learn how to clean up after themselves.
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
Actually, a camera that scores the clean up progress, together with some virtual gold coins and real loot boxes for a week of good compliance might really do the trick.
[dead]
Yes, you may be fine with git, but can you say the same thing about AI agents? /s
You didn't click the link. Who are you to say that they aren't solving actual problems? You might not be their target. The whole article is dedicated to explaining why they're building their product.
The article does a bad job at that, because it remains rather vague and doesn’t explain the concrete problems they are trying to solve, that aren’t either already solved by Git-linked issue trackers, or would be better solved by improving support in Git itself (like for stacked branches).
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.
You can think that because you've read the article.
Tbf, git is very much a problem that needs solving. It only works well for text data, the fact that it is decentralized adds a lot of complexity but doesn't matter for 99% of users since they use a centralized git forge like Github or Gitlab, and the UX is pretty much non-existent.
It works exacly as it was designed to work.. GIT as VCS.. Version Control System.. for text code sniplets. It can handle small binary blobs just fine.
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.
But do you really think $17M is going to give us that alternative, or will it come from some brilliant guy going on a caffeine-fueled weeklong side quest (like how Git was invented)?
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).
I think they are going to give us _something_. Devs probably won't pick it up though.
Yeah probably right :)
if you don't understand git you shouldn't be coding, full stop. The exact same skill set needed to write good code is required to use git in quick and efficient matter.
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
> Why is nobody solving actual problems anymore?
Let me just state the obvious. Of all the major problems of society, sorting legos isn't one. If you disagree, try emerging from the cellar.
Completely unnecessary retort. At no point did anyone in this thread state that sorting legos was a major problem of society.
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.
Maybe you're not a parent. To me, this sounds like arguing against the existence of the dishwasher by saying "of all the major problems of society, washing dishes by hand isn't one."
What a ridiculous statement from an obviously over-privleged phony. You are actually doubling-down on being completely isolated.
Kids face a lot of new problems these days. They also face some old one, like sorting their legos.
Replacing git is?
Successfully would be big business, because everyone and everyone and the F1000 uses git. Or at least it could more of a feature than a product, and gets merged into some other VC company, or some Jira feature or etc.
Who really wants cheap lego vacuums? Basement-dwellers who are getting yelled at by their mom? Not a good market.
[dead]
TL;DR we decided git needs more "ai" and we got money thrown at us!
[dead]
[dead]
[dead]
[dead]
[flagged]
Mmmh. git is perfect as it is. It does one thing and does it really well: version control. Exact bits that go in come out. And it reconciles different versions and handles transferring them to remotes.
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.