Seems like you are just complaining that something useful to a great many people isn't perfect for you particular use case.
Use something thats's a better fit for your use case.
There's nothing wrong with a hammer, you just want a screwdriver.
Use something thats's a better fit for your use case.
There's nothing wrong with a hammer, you just want a screwdriver.
I think Git is a very clunky rock that results in people smashing their fingers and is custom designed for a very specific use case (Linux open source) that isn’t actually relevant to 99.99% of projects.
I think Git is a local minimum that people are ignorantly satisfied with. Everyone is using a mishappen rock and the popularity of this rock is inhibiting the creation of a proper hammer.
I could be wrong! But I am unfortunately forced to used Git due to its ubiquity even though it’s an extremely limited tool. Git does not spark my joy.
Mercurial is very similar to Git but incrementally better. In a different world we’d all use MercurialHub. I wouldn’t be fully happy with Mercurial either. But the point is that Git’s ubiquity has to do with ecosystem factors beyond its intrinsic capabilities and design.
Git is a mediocre hammer, at absolute best. I want a great hammer. Users incorrectly think Git is a great hammer which is making it difficult for an actually great hammer to be built.
Almost all HN users will disagree with me. They’re quite happy with Git and think it’s a great hammer. I think they’re all wrong. But maybe it is me who is wrong! :)
There is far more development going on outside of games.
It's been quite a while since I used other version control systems (such as Mercurial) to any greater extent, so I'll have to rely on my recollection of the feelings and thoughts I had when I did. I also don't really know what the current state of Mercurial is.
My impression of Git in relation to e.g. Mercurial was that Git was harder to get into. Once I did become comfortable and began to kind of understand how git works, though, it seemed to make it possible to do just about anything I wanted to do with source code. In particular, branches, merging, cherry-picking etc. work well and are fast. Doing local experiments before settling for a solution, rebasing your work on latest (already shared) other developments before publishing it to others, etc. are well enabled by those features.
Limited is not how I would describe Git. In fact, it seems rather versatile, as far as managing source code or other similar line-oriented text-based formats go. Grokking it well enough to use that versatility isn't easy, and some of the terminology it uses is just confusing, but once I got past that, it seems to enable lots of workflows that are useful for actual work on source code.
What it of course probably doesn't do that well is handling large blobs. Most software projects don't actually have lots of those, and when there are some, they're often somewhat static. So for most developers, that's usually not a major limitation of the tool. But it almost certainly is to you.
Another thing, of course, is that it's basically just a tool for keeping track of and managing versions and contents of text files. It's not, by itself, a tool for managing higher-level workflows of an entire development project, or for really handling specific formats, or anything else higher level that's not somehow related to managing source code or something similar. That can also be a major limitation. But I don't think that makes it a poor tool; in lots of programming, keeping track of and managing versions and contents of source code in multiple branches is the central use case. Tools for code reviews and other higher level project workflows can then be built separately on top of that.
When you say it's a mediocre hammer, I think you and other people just have different ideas of what a hammer is and what they typically need out of it.
Mercurial probably also allows for all of those things that lots of people like Git for. I honestly don't quite remember what the differences were or how I felt about them when I used both, except that Mercurial seemed easier to handle at first but Git felt possibly more versatile once I got used to it. I can't quite remember what gave me the latter feeling but it's quite possible the choice really made little difference in the end.
For what it's worth, I think BitBucket used to support Mercurial, so we did kind of have something along the lines of GitHub (at the time) for Mercurial.
To continue along the "mediocre hammer" line, is there something specific about Git that makes it seem only mediocre to you if you considered a hammer to be a tool for handling source code alone? How is it limited in that regard?
I have never encountered that. Binary files are generally kept in something like SharePoint, where it is SharePoint which is then hated by everyone.
It's interesting that regardless of the tool, everyone seems to hate it. Perhaps if all tools are wrong, you are trying to force a bad usecase?
The world has non-text files that require version control support. Version control systems are mostly bad-to-terrible for anything other than source code. Implying that the use case is wrong is borderline offensive.
It’d be nice if there were some artist/designer friendly version control systems. I can teach someone who has never even heard of version control how to use Perforce in 10 minutes. It’s darn near idiot proof and near impossible to shoot your foot off. Git is not easy to use. This is evidenced by the tens of thousands of blogs explaining how easy and simple to use it is. If that were the case there wouldn’t be need for all those posts!
Someday.
I would also love some kind of good (even decent would be enough) VCS for binary/non-text files. I get a stress rash just watching our designers work with "final_final_2023_1_backup_new.psd".
I think Git is relatively simple in relation to all the complicated things you can do with it. If you don't need/use those complicated things, it of course feels like way too much work for too little pay off.
Which is fine, but saying that git is rubbish because it doesn't handle binary files as you want it to is a bad usecase.
How version control would handle diffs between PDFs is not the same as photos, which is not the same as video. They have to be content aware for these sorts of things.
If you just want images then gitlab does a good enough job.
https://gitlab.com/gitlab-org/gitlab-test/-/commit/2f63565e7...
How would we represent video diffs? I don't deal with video so I'm not an expert, but there appears to be people complaining without suggesting solutions.
A theoretical Git2 could provide Perforce-tier support for large binary files. But, imho, this would likely require dropping the D in DVCS. I would gladly trade distributed for large binary file support. Without even a moment’s hesitation. Other people wouldn’t. But I wouldn’t call their use case “bad”.
Git is rubbish for my needs. It’s rubbish for a lot of needs. It’s ok at some things. Mercurial is much better at those things though.
That's not really a problem with the tool, though. That's a social problem.