[trashb]

> 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

[bmitc]

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.

[trashb]

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.

[bmitc]

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.