5 ms·

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

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.

genocidicbunny 3y ago
Except it seems the world keeps insisting that I use the hammer to bash on the screws.
- gorjusborg 3y ago
  Sure, if someone is forcing you to use a tool unfit for the purpose, that's bound to frustrate you. That's not really a problem with the tool, though. That's a social problem.
- happymellon 3y ago
  The world wants you to use git for binary file versioning? 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?
  - forrestthewoods 3y ago
    > 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.
    - LinXitoW 3y ago
      Text is a universally understood file format. That means it can be easily diffed, compressed, smartly stored (like storing only changes). That's not true of binaries, at least most of them. That's why I'm pessimistic about a good universal VCS ever existing. 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.
    - happymellon 3y ago
      > The world has non-text files that require version control support 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.
      - genocidicbunny 3y ago
        Well, to be frank, git doesn't really handle binary files _at all_. I don't really consider treating binary files as opaque blobs of data as 'handling them'. It's more akin to throwing your hands up and saying 'fuck it, we'll treat it like the text stuff and whatever happens, happens.' Yes, over time git has gained some capability for handling binary data as delta patches, but it is so far away from anything even remotely resembling content-awareness.
        happymellon 3y ago
        Because no one is driving a universal content aware diff, as far as I can tell. If you just want images then gitlab does a good enough job. https://gitlab.com/gitlab-org/gitlab-test/-/commit/2f63565e7aac07bcdadb654e253078b727143ec4?view=inline 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.
forrestthewoods 3y ago
Kind of. 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! :)
- Delk 3y ago
  To me, Git is more like a Swiss army chainsaw. 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?

genocidicbunny 3y ago

Except it seems the world keeps insisting that I use the hammer to bash on the screws.

gorjusborg 3y ago
Sure, if someone is forcing you to use a tool unfit for the purpose, that's bound to frustrate you. That's not really a problem with the tool, though. That's a social problem.
happymellon 3y ago
The world wants you to use git for binary file versioning? 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?
- forrestthewoods 3y ago
  > 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.
  - LinXitoW 3y ago
    Text is a universally understood file format. That means it can be easily diffed, compressed, smartly stored (like storing only changes). That's not true of binaries, at least most of them. That's why I'm pessimistic about a good universal VCS ever existing. 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.
  - happymellon 3y ago
    > The world has non-text files that require version control support 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.
    - genocidicbunny 3y ago
      Well, to be frank, git doesn't really handle binary files _at all_. I don't really consider treating binary files as opaque blobs of data as 'handling them'. It's more akin to throwing your hands up and saying 'fuck it, we'll treat it like the text stuff and whatever happens, happens.' Yes, over time git has gained some capability for handling binary data as delta patches, but it is so far away from anything even remotely resembling content-awareness.
      - happymellon 3y ago
        Because no one is driving a universal content aware diff, as far as I can tell. If you just want images then gitlab does a good enough job. https://gitlab.com/gitlab-org/gitlab-test/-/commit/2f63565e7aac07bcdadb654e253078b727143ec4?view=inline 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.

forrestthewoods 3y ago

Kind of. 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! :)

Delk 3y ago
To me, Git is more like a Swiss army chainsaw. 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?