5 ms·

Binaries aren't source code. It sounds like you want a versioned file system, not source control. Git is a beautiful solution for its use case.

forrestthewoods 3y ago
Git is a “distributed version control system” (DVCS). You’re just adding the term “source code” for no particular reason. I make video games. Video games contain far more data than mere source code. Almost all game devs use Perforce because Git is insufficient. Artists and designers desperately need more version control in their lives. They are mostly absent because their programmers use Git which is insufficient. Its a god damn shame how much of our businesses use “stuff_final_final_05.psd” for “version control”.
- gorjusborg 3y ago
  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.
  - 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
  Amen. I also work[ed] in video games, and this rings very true to me. Git worked well enough for the programmers, but when you're dealing with artists, producers, designers, writers, audio engineers all needing to share work on assets that are also tied to specific versions of source, Git falls apart. One studio I was at actually had a custom VCS that was a combination of SVN + homebrew asset versioning that worked decently well. By that I mean we all hated the shit out of having to use it, but it worked better than most anything we could get our hands on at the time for a reasonable price.
- KerrAvon 3y ago
  Ah, this is why you have a bad attitude about the “D” part of “DVCS”, right? The workflow for art is “I need to lock that graphics asset so that no one else edits it while I’m editing it,” which you can’t do with a DVCS. Disallowing exclusive edits is generally what most programming teams want; otherwise it’s a daily occurrence to try to get someone to unlock a file they locked for editing and forgot about.
  - forrestthewoods 3y ago
    Not really. Locking of binary assets is a separate topic I’ve ignored. I don’t actually like or dislike the “distributed” part. I don’t care about it. At all. In the slightest. Almost all projects are defacto centralized. If decentralization was free then great, more features for free. My experience is that distributed is not free. It appears to me to be a fatal flaw that prevents Git from ever being a good tool for large projects with large binary assets, such as games. So I would sacrifice it in a heartbeat IF it gave me the features I do care about.
  - erik_seaberg 3y ago
    Locking is just punting on the problem. If a version control system can't merge non-conflicting changes to the same file by different people, that file is unmaintainable and shouldn't have been checked in as if it were source code. Instead it should be generated from a set of files that can be edited normally.

forrestthewoods 3y ago

Git is a “distributed version control system” (DVCS). You’re just adding the term “source code” for no particular reason. I make video games. Video games contain far more data than mere source code. Almost all game devs use Perforce because Git is insufficient. Artists and designers desperately need more version control in their lives. They are mostly absent because their programmers use Git which is insufficient. Its a god damn shame how much of our businesses use “stuff_final_final_05.psd” for “version control”.

gorjusborg 3y ago
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.
- 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
Amen. I also work[ed] in video games, and this rings very true to me. Git worked well enough for the programmers, but when you're dealing with artists, producers, designers, writers, audio engineers all needing to share work on assets that are also tied to specific versions of source, Git falls apart. One studio I was at actually had a custom VCS that was a combination of SVN + homebrew asset versioning that worked decently well. By that I mean we all hated the shit out of having to use it, but it worked better than most anything we could get our hands on at the time for a reasonable price.
KerrAvon 3y ago
Ah, this is why you have a bad attitude about the “D” part of “DVCS”, right? The workflow for art is “I need to lock that graphics asset so that no one else edits it while I’m editing it,” which you can’t do with a DVCS. Disallowing exclusive edits is generally what most programming teams want; otherwise it’s a daily occurrence to try to get someone to unlock a file they locked for editing and forgot about.
- forrestthewoods 3y ago
  Not really. Locking of binary assets is a separate topic I’ve ignored. I don’t actually like or dislike the “distributed” part. I don’t care about it. At all. In the slightest. Almost all projects are defacto centralized. If decentralization was free then great, more features for free. My experience is that distributed is not free. It appears to me to be a fatal flaw that prevents Git from ever being a good tool for large projects with large binary assets, such as games. So I would sacrifice it in a heartbeat IF it gave me the features I do care about.
- erik_seaberg 3y ago
  Locking is just punting on the problem. If a version control system can't merge non-conflicting changes to the same file by different people, that file is unmaintainable and shouldn't have been checked in as if it were source code. Instead it should be generated from a set of files that can be edited normally.