High-Level Problems with Git and How to Fix Them
One personal anecdote:<p>In a decade of using Mercurial, I&#x27;ve managed to get a repository in such a confused state that I had to blow it up and start from scratch just once. In the same time, I&#x27;ve had to do the same for git repositories at least 5 or 6 times--and I never really used git all that much. Even nowadays, where I&#x27;m more or less forcing myself to use git [1], I&#x27;m incredibly hesitant to try any sort of complex git operation because of the risk that I might lose my in-progress commits.<p>While the problems of git&#x27;s UI is well-known, I don&#x27;t think it&#x27;s as appreciated that git&#x27;s complexity generally discourages people from trying things out. I&#x27;m never really sure what could cause me to lose unpushed commits or uncommitted working files, especially with git&#x27;s predilection for reusing the same verb to do slightly different operations for different concepts. In stark contrast, it&#x27;s more difficult to get Mercurial to chew up your work without telling you [2], and it&#x27;s easier to explore the command lists to see if there&#x27;s something that can do what you want it to do.<p>[1] The repositories I&#x27;m working on involve submodules, which hg-git is exceptionally poor at supporting well. Even so, the list of git alias commands on the whiteboard is entitled &quot;Forcing myself to use git before I rage-quit and switch to Mercurial.&quot;<p>[2] I have done it, though. Worst offender was discovering that hg qrefresh &lt;list of files&gt; causes only those file changes to be committed, and files not mentioned are decommited to working-directory-only changes... which hg qpop happily deleted without warning me, causing me to lose a large patch. That was when I put the patch queue directory in version control.