alt Hacker NewsWe've raised $17M to build what comes after Git
Comments
Rather confusing, your name has Git in it, “to build what comes after git”, what comes after your own Git product? Good luck.
Meanwhile CVS just keeps working fine...
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.
A lot of blood in the water for Github.
please also build it for easy multimedia management
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?
> 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.
Blog post written by llm.
No thanks.
Was their series A pitch also written by llm?
no mentions of dura by nobody in the comments?
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).
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.
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.
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).
Raising a bunch of money to recreate the wheel.
Ok, ok, if you give me $16M I'll do it faster.
> 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
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.
The title is misleading, it's not a git replacement
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.
That's a lot of money for something very much not necessary... I'm in the wrong business!
Github fallout effect?
> 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.
Pijul?
Git has issues, but it works pretty well once you learn it and it's basically universal. Will be hard to dislodge.
Nothing needs to come after git. its perfect.
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
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.
> Proprietary git wrapper with pay-to-play "enterprise" gating
Oh boy. Thanks for the nightmares.
Good luck with that, I would still be using subversion if given the choice.
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.
"We are going to spend $17M and have nothing to show for it"
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.
Bros wanted to work on dev tools. They sold it to VCs as "AI tools" to get easy money. Well played!
> 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.
Why is nobody solving actual problems anymore?
[dead]
[dead]
TL;DR we decided git needs more "ai" and we got money thrown at us!
Improving something that basically everyone uses is obviously worth money