<story><title>Why SQLite does not use Git (2018)</title><url>https://www.sqlite.org/draft/matrix/whynotgit.html</url></story><parent_chain><item><author>bonzini</author><text>Subversion is basically CVS done right. The problem is that CVS was a dead end that didn&amp;#x27;t scale to a distributed development model.&lt;p&gt;Git goes back to the local RCS model and adds atomic commits to that model. That&amp;#x27;s how it climbed out of the local optimum that was Subversion. There were a couple controversial choices that Git made, for example not tracking renames and not having linear revision numbers, but they turned out to be not a big deal and they allowed very efficient operations without the performance issues of e.g. darcs.&lt;p&gt;Given all the attempts to fix version control between 1995 and 2010, the basic data model of git seems to be very hard to improve on, especially with additions such as git-lfs.&lt;p&gt;There could be new command line interfaces but it has become harder and harder to kick away the incumbents. I know no one who is using git switch and git restore instead of the overloaded and confusing git checkout.</text></item><item><author>anon35</author><text>Made a list of all the revision control tools I&amp;#x27;ve used over the
decades, the year they were created, and the year I last used them:&lt;p&gt;&lt;pre&gt;&lt;code&gt;    sccs            1973    2000
    rcs             1982    2000
    cvs             1990    2004
    clearcase       1992    2004
    perforce        1995    2011
    subversion      2000    2015
    mercurial       2005    2015
    git             2005    present
&lt;/code&gt;&lt;/pre&gt;
So, at least for me, they last around 15 years or so.&lt;p&gt;But often time when I tell juinors that when they&amp;#x27;re my age, git will
be distant a strange memory to them, they look at me funny.  It&amp;#x27;s a
wonderful tool and earned its success, but I&amp;#x27;ll be sad if it&amp;#x27;s our
final take on the problem.</text></item></parent_chain><comment><author>sireat</author><text>git-lfs is horrible, at least it was horrible the last few times I tried it out.&lt;p&gt;More precisely git-lfs is horrible the way it works with Github and its insanely low git-lfs storage and transfer limit.&lt;p&gt;What ends up happening inevitably is that you add some file to git-lfs that you did not mean to.&lt;p&gt;Only half sane&amp;#x2F;insane way to fix this is to just say screw it and start a fresh git repository, hopefully with files that you salvaged before the whole git-lfs mess.&lt;p&gt;I am quoting Github documentation &amp;quot;To remove Git LFS objects from a repository, delete and recreate the repository.&amp;quot;&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;docs.github.com&amp;#x2F;en&amp;#x2F;repositories&amp;#x2F;working-with-files&amp;#x2F;managing-large-files&amp;#x2F;removing-files-from-git-large-file-storage&quot; rel=&quot;nofollow noreferrer&quot;&gt;https:&amp;#x2F;&amp;#x2F;docs.github.com&amp;#x2F;en&amp;#x2F;repositories&amp;#x2F;working-with-files&amp;#x2F;m...&lt;/a&gt;&lt;p&gt;You say that is user error. Of course, users will make errors.&lt;p&gt;However your version control tools should get out of your way not make your life hell.&lt;p&gt;EDIT: I felt fine using Subversion combine with Redmine for issues in mid 2000s&lt;p&gt;Why did we need to go to git for everything when we still end up remoting to&amp;#x2F;from centralized hubs?</text></comment>
<story><title>Why SQLite does not use Git (2018)</title><url>https://www.sqlite.org/draft/matrix/whynotgit.html</url></story><parent_chain><item><author>bonzini</author><text>Subversion is basically CVS done right. The problem is that CVS was a dead end that didn&amp;#x27;t scale to a distributed development model.&lt;p&gt;Git goes back to the local RCS model and adds atomic commits to that model. That&amp;#x27;s how it climbed out of the local optimum that was Subversion. There were a couple controversial choices that Git made, for example not tracking renames and not having linear revision numbers, but they turned out to be not a big deal and they allowed very efficient operations without the performance issues of e.g. darcs.&lt;p&gt;Given all the attempts to fix version control between 1995 and 2010, the basic data model of git seems to be very hard to improve on, especially with additions such as git-lfs.&lt;p&gt;There could be new command line interfaces but it has become harder and harder to kick away the incumbents. I know no one who is using git switch and git restore instead of the overloaded and confusing git checkout.</text></item><item><author>anon35</author><text>Made a list of all the revision control tools I&amp;#x27;ve used over the
decades, the year they were created, and the year I last used them:&lt;p&gt;&lt;pre&gt;&lt;code&gt;    sccs            1973    2000
    rcs             1982    2000
    cvs             1990    2004
    clearcase       1992    2004
    perforce        1995    2011
    subversion      2000    2015
    mercurial       2005    2015
    git             2005    present
&lt;/code&gt;&lt;/pre&gt;
So, at least for me, they last around 15 years or so.&lt;p&gt;But often time when I tell juinors that when they&amp;#x27;re my age, git will
be distant a strange memory to them, they look at me funny.  It&amp;#x27;s a
wonderful tool and earned its success, but I&amp;#x27;ll be sad if it&amp;#x27;s our
final take on the problem.</text></item></parent_chain><comment><author>jon-wood</author><text>I should at some point alias git checkout to throw a warning, git switch&amp;#x2F;restore are clearly a better choice, but unfortunately checkout is ingrained in muscle memory at this point.</text></comment>