Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

blog.gitbutler.com

Post reply on HN
Print view View original

771–780 of 785 posts

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

#771

Post by DrScientist »

debarshri wrote: post #469
DrScientist wrote: post #281

Earlier quoted context omitted.

> VC by default are founder friendly in my experience. Founders are only one stakeholder. There are employees ( I think they fall into that category ), customers, suppliers, and the wider society. It all comes back to why does the company exist - and for which stakeholders. I think that's the point the original author is making. I don't buy the argument that making money in the end is a perfect surrogate for overall…

I dont this wisdom can be applied generically. Lets consider your example, if leader or founder comes across the fact that a river is getting polluted whether it makes profit or not, they will not take that decision as it would impact longer term. What you are mixing is founder led business vs ceo led business. CEO often takes a short term view, when stakeholders are PE Firm, wall street, short term gains are priorit…

Not sure why you went the founder versus CEO route - wasn't particularly picking on founders.

The general point is that leaders are people and many CEO/founders are decent, hardworking, brave people, and some people are arseholes - and I just wanted to highlight one of the excuses arseholes make for their behaviour.

Also note I have no special insight into the specific situation the original poster talked about - I do know working out how to hand on a company you've grown and led to the next generation is one of the hardest challenges.

That's not to say there isn't a lot to say about the positive power of markets - it's just that simplifying that to 'if I'm making money therefore it must be a societal optimal outcome' kind of justification is BS.

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

#772

Post by nikolay »

qrobit wrote: post #295
nikolay wrote: post #122

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

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.

I am fully aware of that. Rewriting commits of code already pushed to production with container images, etc., is just crazy. And GitHub charges an arm and a leg for Advanced Security. And it ignored my pre-commit Git hooks, which include GitLeaks.

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

#773

Post by trashb »

bmitc wrote: post #752
gtowey wrote: post #658

Earlier quoted context omitted.

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.

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

> It also doesn't work for anything that's not a text file.

You can define a custom git merge driver to teach git how to handle your proprietary format.

Edit: after a quick google search I found the following curated list, https://github.com/jelmer/awesome-merge-drivers

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

#774

Post by trashb »

da_chicken wrote: post #644
trashb wrote: 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…

> The interface is still bad.

This is not the problem they are redesigning for, they are redesigning the infrastructure. Github is a live example of a different interface on top of git and that is working fine (though some may have their complaints with it), no redesign of git's underlying "infrastructure" needed.

> Did you ever accidentally commit something that contains a secret that can't be in the repository?

This is an inconvenience for secrets (have become more commonplace since the creation of git) but by my understanding this was a very deliberate choice in the design of git. It grantees integrity in the distributed source. For example you can check the hash of the last commit en be sure that your mirror did not inject malicious code.

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

#775

Post by trashb »

MagicMoonlight wrote: post #661
MidnightRider39 wrote: post #593

Earlier quoted context omitted.

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

It’s not solved because it’s trash. There’s no good interface for it and people find it difficult to use.

I didn't think Github is that bad but if you think that is the case, why would you give the same guys 17M to try again instead of fix the existing?

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

#776

Post by trashb »

mexicocitinluez wrote: post #721
ruszki wrote: post #669

Earlier quoted context omitted.

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

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

  gitcli != git
If you want to create (or use) another git client that makes removing a secret easy for you and your team you are free to do so.

> It was never about whether it was possible. It was about how it's being done.

That's what I was saying originally, no need to change the infrastructure but you can change how you interact with it.

> Arguing that there shouldn't be a simpler way to remove an enormous security flaw feels a bit disingenuous.

First of all, skill issue educate your employees. Secondly, this is a well considered and a huge part of why git is preferred over older systems like SVN or SCCS especially in an open source context where you are distributing your code through unknown channels and where the publisher might have moved on.

Perhaps Git is not the best VCS for your situation. But I think that if you try other options you will run into bigger problems, there is a reason git became the standard in the industry.

[0] https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3... [1] https://git-scm.com/book/en/v2/Getting-Started-The-Command-L...

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

#777

Post by mexicocitinluez »

trashb wrote: post #776
mexicocitinluez wrote: post #721

Earlier quoted context omitted.

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

gitcli != git If you want to create (or use) another git client that makes removing a secret easy for you and your team you are free to do so. > It was never about whether it was possible. It was about how it's being done. That's what I was saying originally, no need to change the infrastructure but you can change how you interact with it. > Arguing that there shouldn't be a simpler way to remove an enormous security…

> First of all, skill issue educate your employees. Secondly, this is a well considered and a huge part of why git is preferred over older systems like SVN or SCCS especially in an open source context where you are distributing your code through unknown channels and where the publisher might have moved on.

If you're entire argument rests on people being perfect, it's a trash argument.

Implying that accidents don't happen when you have skills is absurd.

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

#778

Post by bmitc »

trashb wrote: post #773
bmitc wrote: post #752

Earlier quoted context omitted.

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

> It also doesn't work for anything that's not a text file. You can define a custom git merge driver to teach git how to handle your proprietary format. Edit: after a quick google search I found the following curated list, https://github.com/jelmer/awesome-merge-drivers

Git still doesn't work well with non-text data, including being incredibly slow. There's a reason why game studios use things like Plastic SCM and Perforce.

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

#779

Post by trashb »

bmitc wrote: post #778
trashb wrote: post #773

Earlier quoted context omitted.

> It also doesn't work for anything that's not a text file. You can define a custom git merge driver to teach git how to handle your proprietary format. Edit: after a quick google search I found the following curated list, https://github.com/jelmer/awesome-merge-drivers

Git still doesn't work well with non-text data, including being incredibly slow. There's a reason why game studios use things like Plastic SCM and Perforce.

There may be situations where the git defaults aren't ideal.

I found that for the special scenario of game development git-lfs did the job quite well for me.

> Git still doesn't work well with non-text data

Seems like you are either mishandling git in your situation or you require another tool (different merge driver or difftool?). But I would argue that in either case git infrastructure is not "Buggy" as you suggest neither does it need a rewrite like the original article suggests.

It works as intended and additionally it provides you with the hooks and possibilities to adapt it to your workflow, for example handling large binary format files.

Perhaps for your usecase you would be better off using an alternative for example: one drive business, Plastic SCM, Perforce, google drive or an internal file server. That doesn't mean that git should be rewritten to fit your needs.

It feels like you want a regular sedan to both race in F1 and carry the same load as a lorry, use a specialized tool for your needs.

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

#780

Post by bmitc »

trashb wrote: post #779
bmitc wrote: post #778

Earlier quoted context omitted.

Git still doesn't work well with non-text data, including being incredibly slow. There's a reason why game studios use things like Plastic SCM and Perforce.

There may be situations where the git defaults aren't ideal. I found that for the special scenario of game development git-lfs did the job quite well for me. > Git still doesn't work well with non-text data Seems like you are either mishandling git in your situation or you require another tool (different merge driver or difftool?). But I would argue that in either case git infrastructure is not "Buggy" as you suggest…

I mean, this can go both ways. "Git solves the problems I care about and any problem outside of that is a misuse of Git" versus what I'm stating.

> Seems like you are either mishandling git in your situation

It's not my fault that Git has become the standard for source control even though not all source is text-based. All the tools integrated with Git, like GitHub, diffing, merging, etc. are based upon text being the norm.

> There may be situations where the git defaults aren't ideal.

Certainly, and that's the point.

Post reply on HN