Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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


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.


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.


> Git is buggy

Citation needed on this one. Every problem I've ever seen arise with git came from someone not understanding the model or not knowing all the commands. Those don't make it better, but they don't mean it's buggy either.


I'm a huge fan of lazygit




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: