3 ms·
Git scales well enough for almost everyone (especially if you have a little discipline with what you put in the repo). It’s only huge megacorps that need large
by mikl 7y ago
Git scales well enough for almost everyone (especially if you have a little discipline with what you put in the repo).
It’s only huge megacorps that need larger scale things like GVFS.
As for large files, that is not what Git is for. Git is for source code. Much like how you don’t put large files in your RDBMS, you should not be putting them in your SCM either.
- int_19h 7y agoWhat if you need to version them? Git imposes a very specific versioning model: version is a property of the entire repository. Thus, not including some file in the repo implies that it's not versioned in the same manner. It's not just a function of binary vs source.
- mikl 7y agoVersioning big binary blobs is not what Git was designed for. It’ll do fine with smaller assets like icons and the like, but its data model is based on everyone using the repo having a local copy of the full repository history. You can’t easily purge old data. That scales poorly if you want to use it for audio/video files or other large data sets. You can still do it if you want, but you might be better served using https://git-lfs.github.com/ https://git-lfs.github.com/ or using another system designed for that purpose.
- P_I_Staker 7y agoHonestly, you can use Git for large files with lfs. I wouldn't say I love this approach, but it isn't that bad now. You do have to make room for yet-another-tool, and you now have centralized version control comingling with your distributed tool (essentially making it central); but you can still use everything you love about git, and if your lfs doesn't change, you don't need to be connected to a server. It certainly feels pretty absurd. This isn't even a problem in SVN, but now we're tacking on another tool that you have to learn, and introduces issues.