I think it’s generally agreed upon that large files that change often do not belong while small files that never change are fine. But there’s still a lot of middle ground where the answer is not so clear to me.
So what’s your stance on this? Where do you draw the line?
hiss The point of source control is keeping a history of the code that produces binary artifacts. For convenience’ sake or because of some wild project-specific constraints people can do all kinds of things but IMO binaries in source control are yucky yucky bad bad bad.
I agree that the repository should only contain source files, not the output of the build process. However, in some cases (like icon images) the source files may be binary. I think small binaries that are required to build and/or run the software, and that are not an output of any build process, do make sense to put in the repository.
That’s not really responding to their point. Are you saying that there are no project resources that aren’t (or couldn’t be) encoded as text representation in any conceivable project that is stored in a git repo?
I agree with your general point. I’m just curious if you have some unique project pattern techniques that allow you to draw such a hard line so confidently.
Never do this.
Git is all about tracking changes over time which is meaningless with binary files. They are bloat for your repo, slowing down operations. Depending on the repo, they are likely to change from CI with every commit. That last one means that every commit turns into 2 commits btw. They are can ruin diffs. I could go on for a long time here.
There are basically 0 upsides. Use an artifact repository instead!
Git is all about tracking changes over time which is meaningless with binary files.
Utter codswallop. You can see the changes to a PNG over time. Lots of different UIs will even show you diffs for images.
Git can track changes to binary files perfectly well. It might not be great at dealing with conflicts in them but that’s another matter.
The only issue is that binary files tend to be large, and often don’t compress very well with Git’s delta compression. It’s large files that are the issue, not binary files. If you have a 20 kB binary file it’s going to be absolutely fine in Git. Likewise a 10 GB CSV file is not going to be such a good idea.
If it’s a build artifact, put it in a registry. If it’s resource type files, Git LFS can be used if it’s not an absolute ton.
I’ll go to quite a bit of effort to avoid them. Arguably too much effort, but I often find that the path that avoids them is also useful in other ways.
For example, for a personal project, I automated rendering a PNG fallback icon from an SVG, so now I can have as many different resolutions as I want and don’t need to manually update them, if I want to tweak the icon.
I’d also like to publish a screenshot of the project. The simple solution is to check a PNG into the repo and link it in the README.md. But what would be a lot nicer, is to set up a project webpage, which with Codeberg Pages isn’t even that much effort, but I would have less motivation to do it otherwise.
The main downside is Git downloads all history by default, and so any large files will bloat the download for people cloning your repo forever. It isn’t about binary vs text. It’s just the size that matters.
