this post was submitted on 24 Jul 2024
16 points (100.0% liked)

Git

2826 readers
2 users here now

Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

Resources

Rules

  1. Follow programming.dev rules
  2. Be excellent to each other, no hostility towards users for any reason
  3. No spam of tools/companies/advertisements. It’s OK to post your own stuff part of the time, but the primary use of the community should not be self-promotion.

Git Logo by Jason Long is licensed under the Creative Commons Attribution 3.0 Unported License.

founded 1 year ago
MODERATORS
Ategon@programming.dev
canpolat@programming.dev
jnovinger@programming.dev
16
How do you feel about storing binary files with Git? (lemmy.ca)
submitted 1 month ago by howrar@lemmy.ca to c/git@programming.dev
10 comments fedilink hide all child comments
 

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?

you are viewing a single comment's thread
view the rest of the comments
[–] terrehbyte@ani.social 4 points 1 month ago

I don't like it, but if they're part of the project files, then they belong in version control. I do worry about the challenges of combining the difficult-to-merge nature of binaries with the distributed workflows that Git encourages. While data doesn't get lost, the inability to merge them may mean that someone needs to spend extra time re-performing their changes if they "lose" the push/merge race.

Game engines have been doing a better job of transitioning away from large monolithic binaries by either serializing them in somewhat mergeable text files or at least splitting them into large numbers of smaller binaries to reduce file contention.

Git LFS does offer the ability to off-load them from the repository, reduce download and checkout times as well as the ability to lock files (which does introduce centralization...), but it doesn't seem to be as ubiquitous and can be more expensive to use, depending on the team's options for Git repo providers.

Note: I assume you mean binaries as in "non-text files", not build artifacts, which definitely don't belong in version control at all.