<story><title>What I Hate About Git</title><url>https://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git/</url></story><parent_chain><item><author>encoderer</author><text>&amp;#62; The OP already pointed out that the official Git documentation is bad, bad bad. So, already it&apos;s not just &quot;RTFM&quot; but &quot;Google around for a decent Git tutorial and hope you pick the right one.&quot; Great.&lt;p&gt;I have a hard time believing that there are scores of software developers out there who have learned their craft enough to want source control but are somehow overwhelmed by the basic task of finding a good Git tutorial.&lt;p&gt;The real impediment that I&apos;ve observed is developers that certainly &lt;i&gt;could&lt;/i&gt; learn Git but don&apos;t because they don&apos;t see it as a good investment. That&apos;s where they&apos;re so, so wrong. Git is like power tools for your code. If you embrace and learn it, you&apos;ll be much better off for it. Yes, SVN is easier. It&apos;s also a lot less powerful.&lt;p&gt;And there&apos;s always Mercurial, which is very similar to Git and addresses some of the confusing-API criticism.</text></item><item><author>ender7</author><text>Like others, I think telling people to RTFM is unhelpful.&lt;p&gt;The OP already pointed out that the official Git documentation is bad, bad &lt;i&gt;bad.&lt;/i&gt; So, already it&apos;s not just &quot;RTFM&quot; but &quot;Google around for a decent Git tutorial and hope you pick the right one.&quot; Great.&lt;p&gt;Add to this the fact that the Git commands are simply &lt;i&gt;poorly designed.&lt;/i&gt; Yes, it is possible to understand what they do after expending a significant amount of time simply learning to think like Linus, but &lt;i&gt;why should we have to do that?&lt;/i&gt; I refer you to the gitref.org entry for &apos;git reset&apos;:&lt;p&gt;&lt;i&gt;git reset is probably the most confusing command written by humans. I&apos;ve been using Git for years, even wrote a book on it and I still get confused by what it is going to do at times.&lt;/i&gt; [0]&lt;p&gt;This is not a problem of people not wanting to learn DVCS concepts. This is simply people who don&apos;t want to jump through a set of arbitrary, confusing, and completely unnecessary mental hoops in order to get to the DVCS concepts they wanted to use.&lt;p&gt;[0] &lt;a href=&quot;http://gitref.org/basic/#reset&quot; rel=&quot;nofollow&quot;&gt;http://gitref.org/basic/#reset&lt;/a&gt; (gitref.org is maintained by GitHub)</text></item><item><author>klodolph</author><text>Number 1-5 are mostly &quot;I don&apos;t want to learn new things&quot;, so I&apos;ll ignore them.  Do you remember when you learned source control for the first time?  I don&apos;t, it was too long ago.  Just like you have to learn SVN if you&apos;ve never used source control before, you have to learn Git if you&apos;ve never used distributed source control before.&lt;p&gt;* &quot;Unsafe version control&quot;, and then gives examples using -f or +&amp;#60;refspec&amp;#62;, both of which advertise their destructive nature.  Yes, you can also go in with SVN and obliterate history too, using svnadmin dump and svnadmin load.  Git&apos;s reflog will have your back when you make mistakes, as long as the mistakes don&apos;t get too old.&lt;p&gt;* &quot;Power for the maintainer, at the expense of the contributor&quot; Yes, most people write code on one branch for a long period of time.  Git does this just fine.&lt;p&gt;* &quot;Burden of VCS maintainance pushed to contributors&quot; First of all, nobody says that contributors have to merge.  That is a decision that each project makes.  Plenty of projects have the lead developers merging in everyone else&apos;s work.  Second, the reason this is even an issue is because merging is such a pain in SVN that most people don&apos;t want to do it.&lt;p&gt;* &quot;Git history is a bunch of lies&quot; Again, this is up to the individual project.  Some developers like to work on six different things at the same time, and then they go back and rewrite history so that their six changes end up as six commits.  The difference with SVN, is that these same developers would simply avoid committing until they&apos;re done with all six changes.  Some projects expect rebased patches, some prefer proper merges.  Worse, the author says that &quot;filtering&quot; should solve this problem, but doesn&apos;t propose how such a filter would work.&lt;p&gt;* Complexity of simple tasks: Let&apos;s try not to artificially inflate the complexity of the Git tasks.  For example, the Git examples assume no commit access, whereas the SVN examples assume direct commit access.  If you don&apos;t have commit access to an SVN project, how do you do it?  You either use git-svn and mail them a patch, or you use svn and mail them a patch.&lt;p&gt;A recurring complaint seems to be that &quot;git add&quot; is not the same as &quot;svn add&quot;.  I don&apos;t see why it would be.  It&apos;s not the same as &quot;ssh-add&quot; or &quot;useradd&quot; either.</text></item></parent_chain><comment><author>CJefferson</author><text>The problem with git isn&apos;t following a tutorial, the problems I have had are nasty corner cases. I have to keep looking up strange a-symmetries, like why does &apos;git push&apos; push just the current branch, and &apos;git pull&apos; pull all branches? Then I have to look up how to make &apos;git pull&apos; pull just the current branch.&lt;p&gt;Also, due to inconsistencies in how commands take branches, I sometimes realise I have a branch called &apos;origin/stuff&apos;, when I meant to do something with stuff on origin. It&apos;s also hard to find which branches are tracking what. Of course, you can find the options to do all these things. But there are just so many little things to learnt.&lt;p&gt;The fundamental question is, does the complexity of git come from the power it offers over svn, or does it come from the most terrible UI I think I have ever seen on a command line tool? I think it is the second.&lt;p&gt;I still use git every day, but I think it is putting usability by less computer-savvy users back years.</text></comment>
<story><title>What I Hate About Git</title><url>https://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git/</url></story><parent_chain><item><author>encoderer</author><text>&amp;#62; The OP already pointed out that the official Git documentation is bad, bad bad. So, already it&apos;s not just &quot;RTFM&quot; but &quot;Google around for a decent Git tutorial and hope you pick the right one.&quot; Great.&lt;p&gt;I have a hard time believing that there are scores of software developers out there who have learned their craft enough to want source control but are somehow overwhelmed by the basic task of finding a good Git tutorial.&lt;p&gt;The real impediment that I&apos;ve observed is developers that certainly &lt;i&gt;could&lt;/i&gt; learn Git but don&apos;t because they don&apos;t see it as a good investment. That&apos;s where they&apos;re so, so wrong. Git is like power tools for your code. If you embrace and learn it, you&apos;ll be much better off for it. Yes, SVN is easier. It&apos;s also a lot less powerful.&lt;p&gt;And there&apos;s always Mercurial, which is very similar to Git and addresses some of the confusing-API criticism.</text></item><item><author>ender7</author><text>Like others, I think telling people to RTFM is unhelpful.&lt;p&gt;The OP already pointed out that the official Git documentation is bad, bad &lt;i&gt;bad.&lt;/i&gt; So, already it&apos;s not just &quot;RTFM&quot; but &quot;Google around for a decent Git tutorial and hope you pick the right one.&quot; Great.&lt;p&gt;Add to this the fact that the Git commands are simply &lt;i&gt;poorly designed.&lt;/i&gt; Yes, it is possible to understand what they do after expending a significant amount of time simply learning to think like Linus, but &lt;i&gt;why should we have to do that?&lt;/i&gt; I refer you to the gitref.org entry for &apos;git reset&apos;:&lt;p&gt;&lt;i&gt;git reset is probably the most confusing command written by humans. I&apos;ve been using Git for years, even wrote a book on it and I still get confused by what it is going to do at times.&lt;/i&gt; [0]&lt;p&gt;This is not a problem of people not wanting to learn DVCS concepts. This is simply people who don&apos;t want to jump through a set of arbitrary, confusing, and completely unnecessary mental hoops in order to get to the DVCS concepts they wanted to use.&lt;p&gt;[0] &lt;a href=&quot;http://gitref.org/basic/#reset&quot; rel=&quot;nofollow&quot;&gt;http://gitref.org/basic/#reset&lt;/a&gt; (gitref.org is maintained by GitHub)</text></item><item><author>klodolph</author><text>Number 1-5 are mostly &quot;I don&apos;t want to learn new things&quot;, so I&apos;ll ignore them.  Do you remember when you learned source control for the first time?  I don&apos;t, it was too long ago.  Just like you have to learn SVN if you&apos;ve never used source control before, you have to learn Git if you&apos;ve never used distributed source control before.&lt;p&gt;* &quot;Unsafe version control&quot;, and then gives examples using -f or +&amp;#60;refspec&amp;#62;, both of which advertise their destructive nature.  Yes, you can also go in with SVN and obliterate history too, using svnadmin dump and svnadmin load.  Git&apos;s reflog will have your back when you make mistakes, as long as the mistakes don&apos;t get too old.&lt;p&gt;* &quot;Power for the maintainer, at the expense of the contributor&quot; Yes, most people write code on one branch for a long period of time.  Git does this just fine.&lt;p&gt;* &quot;Burden of VCS maintainance pushed to contributors&quot; First of all, nobody says that contributors have to merge.  That is a decision that each project makes.  Plenty of projects have the lead developers merging in everyone else&apos;s work.  Second, the reason this is even an issue is because merging is such a pain in SVN that most people don&apos;t want to do it.&lt;p&gt;* &quot;Git history is a bunch of lies&quot; Again, this is up to the individual project.  Some developers like to work on six different things at the same time, and then they go back and rewrite history so that their six changes end up as six commits.  The difference with SVN, is that these same developers would simply avoid committing until they&apos;re done with all six changes.  Some projects expect rebased patches, some prefer proper merges.  Worse, the author says that &quot;filtering&quot; should solve this problem, but doesn&apos;t propose how such a filter would work.&lt;p&gt;* Complexity of simple tasks: Let&apos;s try not to artificially inflate the complexity of the Git tasks.  For example, the Git examples assume no commit access, whereas the SVN examples assume direct commit access.  If you don&apos;t have commit access to an SVN project, how do you do it?  You either use git-svn and mail them a patch, or you use svn and mail them a patch.&lt;p&gt;A recurring complaint seems to be that &quot;git add&quot; is not the same as &quot;svn add&quot;.  I don&apos;t see why it would be.  It&apos;s not the same as &quot;ssh-add&quot; or &quot;useradd&quot; either.</text></item></parent_chain><comment><author>mgkimsal</author><text>&quot;...but are somehow overwhelmed by the basic task of finding a good Git tutorial.&quot;&lt;p&gt;Ummm.... when you &lt;i&gt;don&apos;t know&lt;/i&gt; the tool, you&apos;re not in a good place to judge what a &apos;good&apos; tutorial is.  This is the same reason we&apos;ve got generations of bad PHP developers out there - they can&apos;t tell what&apos;s good or not.&lt;p&gt;&quot;scores of software developers out there who have learned their craft enough to want source control&quot;&lt;p&gt;How many people &apos;want&apos; to learn source control, and how many people are told &apos;this is what we use here, go learn it&apos;?  I suspect far more of the latter, especially with git.  People would &lt;i&gt;not&lt;/i&gt; flock to git purely based on the documentation quality.  Further, I suspect that had git just been written by some random dude off the street with no major project behind it, it would have never taken off.  Using it for Linux kernel work has ensured a sizeable number of people are going to have to use it, whether they like it or not.</text></comment>