Comment by tsimionescu
1 day ago
That is a complete no-go for many use cases. Large files can have exactly the same use cases as your code: you need to branch them, you need to know when and why they changed, you need to check how an old build with an old version of the large file worked, etc. Just because code tends to be small doesn't mean that all source files for a real program are going to be small too.
Yeah but GIT is not the tool for that.
That is why I don’t understand why people „need to use GIT”.
You still can make something else like keeping versions and keeping track of those versions in many different ways.
You can store a reference in repo like a link or whatever.
A version control system is a tool for managing a project, not exclusively a tool for managing source code.
Wanting to split up the project into multiple storage spaces is inherently hostile to managing the project. People want it together because it's important that it stays together as a basic function of managing a project of digital files. The need to track and maintain digital version numbers and linking them to release numbers and build plans is just a requirement.
That's what actual, real projects demand. Any projects that involve digital assets is going to involve binary, often large, data files. Any projects that involve large tables of pre-determined or historic data will involve large files that may be text or binary which contain data the project requires. They won't have everything encompassed by the project as a text file. It's weird when that's true for a project. It's a unique situation to the Linux kernel because it, somewhat uniquely, doesn't have graphics or large, predetermined data blocks. Well, not all projects that need to be managed by git share 100% of the attributes of the Linux kernel.
This idea that everything in a git project must be all small text file is incredibly bizarre. Are you making a video game? A website? A web application? A data driven API? Does it have geographic data? Does it required images? Video? Music or sound? Are you providing static documentation that must be included?
So the choices are:
1. Git is useful general purpose VCS for real world projects. 2. Git does not permit binary or large files.
Tracking versioning on large files is not some massively complex problem. Not needing to care about diffing and merging simplifies how those files are managed.
That’s what I disagree with. For me Git is for managing source code. Everything else is trying to fit square peg through round hole.
There are other tools for managing projects and better ways to version large files or binary assets.
Git is great at handling text changes and that’s it. It sucks with binary blobs.
Git is an scm, not a vcs. By design.
> Yeah but GIT is not the tool for that.
Yes because Git currently is not good at tracking large file. That's not some fundamental property of Git; it can be improved.
Btw it isn't GIT.
I care to disagree on it being an improvement or not being good at tracking large files being flaw of Git.
The important point is that you don't want two separate histories. Maybe if your use case is very heavy on large files, you can choose a different SCM, which is better at this use case (SVN, Perforce). But using different SCMs for different files is a recipe for disaster.
Git is the right tool. It's just bad at this job.
That's pretty much what git LFS is...