3 ms·

Mostly people who have this argument don't have a code base large enough to run into actual limitations of git. They run CI with wonky java implementations of g

by jupp0r 4y ago

Mostly people who have this argument don't have a code base large enough to run into actual limitations of git. They run CI with wonky java implementations of git and/or have giant amounts of binaries in their repos. Actually having Gigabytes of source code is pretty rare.

pianoben 4y ago
Or, they run in to limits with Github and mistake them for git limitations...
colonwqbang 4y ago
It depends on the size of the company. The Linux kernel has about 1500 active developers. This is a lot, but many companies also exist that reach this size. I think another thing that matters is how you store branches/code under review. In Linux, each team/person has their own repo. The main "Linus" repo has mostly the finished code. In a company it is much more common for everyone to store their unfinished code centrally. Perhaps this also accounts for some increase in size.
maccard 4y ago
> and/or have giant amounts of binaries in their repos. Firstly, it's not "giant amounts of binaries" it's "a very small amount of binaries". A few GB is enough to cause significant problems. Secondly, This _is_ an issue with git. If my project requires binary files, git should handle it. How should we handle logos in a mobile app, branding images on a website, audio files for background? That's before you get to the question of "how does a video game store the source version of a 100GB worth of compressed assets?"
- nicoburns 4y ago
  In fairness, there is git LFS, which is a well-maintained solution to do this. It's not fantastic, but it does exist.
  - maccard 4y ago
    Git LFS is a reasonably good example of git being half baked. It is provider dependent, and requires configuring separately on both the server and client. It turns git into a centralised VCS, removing the option of working offline in the process. A bit like submodules, LFS has its own warts that seem to multiply when you add more people to the mix. Working with git LFS has been the _only_ time the solution to my problem has been "nuke and clone again", in almost 15 years using source control. Last time I used git LFS, it didn't support ssh cloning at all, and the issue had been open for years at that time.

by jupp0r 4y ago

pianoben 4y ago

Or, they run in to limits with Github and mistake them for git limitations...

colonwqbang 4y ago

It depends on the size of the company. The Linux kernel has about 1500 active developers. This is a lot, but many companies also exist that reach this size. I think another thing that matters is how you store branches/code under review. In Linux, each team/person has their own repo. The main "Linus" repo has mostly the finished code. In a company it is much more common for everyone to store their unfinished code centrally. Perhaps this also accounts for some increase in size.

maccard 4y ago

> and/or have giant amounts of binaries in their repos. Firstly, it's not "giant amounts of binaries" it's "a very small amount of binaries". A few GB is enough to cause significant problems. Secondly, This _is_ an issue with git. If my project requires binary files, git should handle it. How should we handle logos in a mobile app, branding images on a website, audio files for background? That's before you get to the question of "how does a video game store the source version of a 100GB worth of compressed assets?"

nicoburns 4y ago
In fairness, there is git LFS, which is a well-maintained solution to do this. It's not fantastic, but it does exist.
- maccard 4y ago
  Git LFS is a reasonably good example of git being half baked. It is provider dependent, and requires configuring separately on both the server and client. It turns git into a centralised VCS, removing the option of working offline in the process. A bit like submodules, LFS has its own warts that seem to multiply when you add more people to the mix. Working with git LFS has been the _only_ time the solution to my problem has been "nuke and clone again", in almost 15 years using source control. Last time I used git LFS, it didn't support ssh cloning at all, and the issue had been open for years at that time.