Live data from Hacker News

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

blog.gitbutler.com

641–650 of 785 posts

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

#641
post #623

Earlier quoted context omitted.

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

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

have you heard startups

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

#642

Earlier quoted context omitted.

Yes, this is the obvious solution. Multiple agents working on multiple features should use feature branches. Can’t believe how this whole AI movement seems to want to reinvent software engineering, poorly.

Their goal is not to give us a better tool, it's to get us to think our old tools are rubbish so we give them money instead.

Has that ever been achieved in software/dev industry?

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

#643
post #578

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

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

#644
post #533

> The old model assumed one person, one branch, one terminal, one linear flow. Not only has the problem not been solved well for that old model, it’s now only been compounded with our new AI tools. A bit of a strange thing to say in my book. Git isn't SVN and I think these problems are already solved with git. I agree that the interface is not always very intuitive but Git has the infrastructure which is very much fo…

> To me it's not clear what the problem is that would require a redesign.

The interface is still bad. Teaching people to use git is still obnoxious because it's arcane. It's like 1e AD&D. It does everything it might need to, but it feels like every aspect of it is bespoke.

It's also relatively difficult to make certain corrections. Did you ever accidentally commit something that contains a secret that can't be in 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.

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

#645
post #618

Earlier quoted context omitted.

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…

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 t…

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

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

#646
post #533

> The old model assumed one person, one branch, one terminal, one linear flow. Not only has the problem not been solved well for that old model, it’s now only been compounded with our new AI tools. A bit of a strange thing to say in my book. Git isn't SVN and I think these problems are already solved with git. I agree that the interface is not always very intuitive but Git has the infrastructure which is very much fo…

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

[dead]

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

#647

Earlier quoted context omitted.

Okay, please explain why the replies are funny.

Explaining a joke is like dissecting a frog, you learn more but you kill it in the process.

It was a joke? It comes across like you pointing out someone missing evidence and being wrong. Obviously you used the word "funny" but that's not usually a word that goes in a joke.

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

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

#648
post #412

Earlier quoted context omitted.

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.

Sure, but that doesn't really change anything. The poster plainly states: > Money is not given to good ideas (though, it doesn’t hurt). Money is given to friends. I have an obvious counter example. I'm sure money is invested for all sorts of reasons to all sorts of people. I'm also sure that money is not exclusively invested based on friendships, and I'm quite sure that money is at times invested based on the merits…

What I meant is that yes, good ideas will get funding, if they like you and if you are a good ROI (though, not all are required). This also may allow you to enter the clique/network. However, a lot of this money circulates between the same network. Convincing the right person of the value of your idea can enable you to join the network and access that money at a much, much lower threshold later on.

Obviously, it is not that cut and dry, but it is kind of impressive how much of the money circulating around is between the same people. I’m not really condemning it. I think it is a natural consequence because humans trust other humans they know. People should be more aware of it and need to make sure they keep it in check. Otherwise, you eventually start getting high on your own supply.

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

#649
post #533

> The old model assumed one person, one branch, one terminal, one linear flow. Not only has the problem not been solved well for that old model, it’s now only been compounded with our new AI tools. A bit of a strange thing to say in my book. Git isn't SVN and I think these problems are already solved with git. I agree that the interface is not always very intuitive but Git has the infrastructure which is very much fo…

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

> 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

Post reply on HN