<story><title>Is Git Irreplaceable? (2019)</title><url>https://fossil-scm.org/forum/forumpost/b251b6e48e</url></story><parent_chain><item><author>Ace17</author><text>I work for a 40-people game studio.&lt;p&gt;A major limitation of git is how it deals with many &amp;quot;big&amp;quot; (~10Mb) binary files (3D models, textures, sounds, etc.).&lt;p&gt;We ended up developing our own layer over git, and we&amp;#x27;re very happy ; even git-lfs can&amp;#x27;t provide similar benefits. This technique seems to be commonplace for game studios (e.g Naughty Dog, Bungee), so certainly git has room for improvement here.</text></item><item><author>kemitche</author><text>I disagree that Git&amp;#x27;s biggest flaw is its lack of scalability. Cases where git needs to scale tend to be isolated to companies that have the manpower to build a finely-tuned replacement (see: MS, Google).&lt;p&gt;Git&amp;#x27;s flaws are primarily in usability&amp;#x2F;UX. But I think for its purpose, functionality is far more important than a perfect UX. I&amp;#x27;m perfectly happy knowing I might have to Google how to do something in Git as long as I can feel confident that Git will have the power to do whatever it is I&amp;#x27;m trying to do. A competitor would need to do what git does as well as git does it, with a UX that is not just marginally better but categorically better, to unseat git. (Marginally better isn&amp;#x27;t strong enough to overcome incumbent use cases)&lt;p&gt;And for the record: I think git-lfs issues are primarily usability issues, and tech improvements. The tech enhancements will be solved if there&amp;#x27;s enough desire, and as I mentioned the usability problems are more annoyances than actual problems.</text></item><item><author>comex</author><text>Git&amp;#x27;s biggest flaw is that it doesn&amp;#x27;t scale.  If a new system can fix that without sacrificing any of Git&amp;#x27;s benefits, I think it can topple Git.&lt;p&gt;It&amp;#x27;s ironic that Git was popularized in the same era as monorepos, yet Git is a poor fit for monorepos.  There have been some attempts to work around this.  Google&amp;#x27;s `repo` command is a wrapper around Git that treats a set of smaller repos like one big one, but it&amp;#x27;s a (very) leaky abstraction.  Microsoft&amp;#x27;s GVFS is a promising attempt to truly scale Git to giant repos, but it&amp;#x27;s developed as an addon rather than a core part of Git, and so far it only works on Windows (with macOS support in development).  GVFS arguably has the potential to become an ubiquitous part of the Git experience, someday... but it probably won&amp;#x27;t.&lt;p&gt;Git also has trouble with large files.  The situation is better these days, as most people have seemingly standardized on git-lfs (over its older competitor git-annex), and it works pretty well.  Nevertheless, it feels like a hack that &amp;quot;large&amp;quot; files have to be managed using a completely different system from normal files, one which (again) is not a core part of Git.&lt;p&gt;There exist version control systems that do scale well to large repos and large files, but all the ones I&amp;#x27;ve heard of have other disadvantages compared to Git.  For example, they&amp;#x27;re not decentralized, or they&amp;#x27;re not as lightning-fast as Git is in smaller repos, or they&amp;#x27;re harder to use.  That&amp;#x27;s why I think there&amp;#x27;s room for a future competitor!&lt;p&gt;(Fossil is not that competitor.  From what I&amp;#x27;ve heard, it neither scales well nor matches Git in performance for small repos, unfortunately.)</text></item></parent_chain><comment><author>mathw</author><text>This does not surprise me. Git&amp;#x27;s original purpose of managing versions of a tree of text files (i.e. the source code of the Linux kernel) pervasively influences it, and I wouldn&amp;#x27;t expect it to be any good for working with binary files or large files.&lt;p&gt;If somebody comes up with something that matches Git&amp;#x27;s strengths and also handles binaries and biggies much, much better then they could definitely topple Git with it. It&amp;#x27;d take time for the word to spread, the tools to mature and the hosting to appear, but I can definitely see it happening.&lt;p&gt;I think most people know that Git isn&amp;#x27;t perfect, but it&amp;#x27;s also the case that coming up with anything better is an extremely difficult task. If it wasn&amp;#x27;t, someone would have already done it. It&amp;#x27;s not like people haven&amp;#x27;t been trying.</text></comment>
<story><title>Is Git Irreplaceable? (2019)</title><url>https://fossil-scm.org/forum/forumpost/b251b6e48e</url></story><parent_chain><item><author>Ace17</author><text>I work for a 40-people game studio.&lt;p&gt;A major limitation of git is how it deals with many &amp;quot;big&amp;quot; (~10Mb) binary files (3D models, textures, sounds, etc.).&lt;p&gt;We ended up developing our own layer over git, and we&amp;#x27;re very happy ; even git-lfs can&amp;#x27;t provide similar benefits. This technique seems to be commonplace for game studios (e.g Naughty Dog, Bungee), so certainly git has room for improvement here.</text></item><item><author>kemitche</author><text>I disagree that Git&amp;#x27;s biggest flaw is its lack of scalability. Cases where git needs to scale tend to be isolated to companies that have the manpower to build a finely-tuned replacement (see: MS, Google).&lt;p&gt;Git&amp;#x27;s flaws are primarily in usability&amp;#x2F;UX. But I think for its purpose, functionality is far more important than a perfect UX. I&amp;#x27;m perfectly happy knowing I might have to Google how to do something in Git as long as I can feel confident that Git will have the power to do whatever it is I&amp;#x27;m trying to do. A competitor would need to do what git does as well as git does it, with a UX that is not just marginally better but categorically better, to unseat git. (Marginally better isn&amp;#x27;t strong enough to overcome incumbent use cases)&lt;p&gt;And for the record: I think git-lfs issues are primarily usability issues, and tech improvements. The tech enhancements will be solved if there&amp;#x27;s enough desire, and as I mentioned the usability problems are more annoyances than actual problems.</text></item><item><author>comex</author><text>Git&amp;#x27;s biggest flaw is that it doesn&amp;#x27;t scale.  If a new system can fix that without sacrificing any of Git&amp;#x27;s benefits, I think it can topple Git.&lt;p&gt;It&amp;#x27;s ironic that Git was popularized in the same era as monorepos, yet Git is a poor fit for monorepos.  There have been some attempts to work around this.  Google&amp;#x27;s `repo` command is a wrapper around Git that treats a set of smaller repos like one big one, but it&amp;#x27;s a (very) leaky abstraction.  Microsoft&amp;#x27;s GVFS is a promising attempt to truly scale Git to giant repos, but it&amp;#x27;s developed as an addon rather than a core part of Git, and so far it only works on Windows (with macOS support in development).  GVFS arguably has the potential to become an ubiquitous part of the Git experience, someday... but it probably won&amp;#x27;t.&lt;p&gt;Git also has trouble with large files.  The situation is better these days, as most people have seemingly standardized on git-lfs (over its older competitor git-annex), and it works pretty well.  Nevertheless, it feels like a hack that &amp;quot;large&amp;quot; files have to be managed using a completely different system from normal files, one which (again) is not a core part of Git.&lt;p&gt;There exist version control systems that do scale well to large repos and large files, but all the ones I&amp;#x27;ve heard of have other disadvantages compared to Git.  For example, they&amp;#x27;re not decentralized, or they&amp;#x27;re not as lightning-fast as Git is in smaller repos, or they&amp;#x27;re harder to use.  That&amp;#x27;s why I think there&amp;#x27;s room for a future competitor!&lt;p&gt;(Fossil is not that competitor.  From what I&amp;#x27;ve heard, it neither scales well nor matches Git in performance for small repos, unfortunately.)</text></item></parent_chain><comment><author>taftster</author><text>Do you have tools that you can utilize diffs from your binary file changes?  Or does a change simply just replace all the bytes.&lt;p&gt;I&amp;#x27;d argue if it&amp;#x27;s the later, that git was never the right choice to begin with. You don&amp;#x27;t really want to record a full 10MB of data every time you change one pixel in your texture or one blip in your sound, right?&lt;p&gt;So I don&amp;#x27;t know if this is a &amp;quot;major limitation&amp;quot; of git per se. Not saying there&amp;#x27;s a better solution off-the-shelf (you&amp;#x27;re obviously happy with your home grown). But this was probably never a realistic use for git in the first place.</text></comment>