Re: High-level Problems with Git and How to Fix Them

Tue 12 December 2017

(originally written as a comment on the blogpost by Gregory Szorc)

Some comments:

  1. I like your ideas about the improved documentation and better sounding options (yes, git commit --cached is stupid). Did you file them as RFE to I don’t think they are that controversial.
  2. I like your idea about workspaces, and it truly seems like an ideal, but I think such drastic measures are not completely necessary. If we just told everybody that more important than git clone is git remote add command, and that it is easy to have five different remotes in the local repository, things would be better [1]. I agree that design of Git{Lab,Hub}/Bitbucket/Sourceforge is poorly based on the idea of hard clone, but the solution is more in the web user interface and presentation than in the substance. For example, I have never understood what's the point of the master branch on my personal clone of the main repository. That branch should never be used (git checkout master && git branch -u origin/master are my first two commands I do after cloning; origin is of course the primary repository, not my clone) and it is confusing that it is the default branch displayed on the webpage of my clone.
  3. Concerning the need to name everything, I completely disagree. The web is full of complaints of people who prefer something else than git and complain bitterly. I suspect that git fanboys (and fangirls) who got bitten by Mercurial/bzr are just silent, being happy that their preferred VCS prevailed. When doing some Firefox-related projects, I tried hard to do it in Mercurial (I have even found a repository hosting which supported hg), but after some weeks of working on my projects, I got completely frustrated with hg, and moved my project to git. I have never returned to hg again and I have never looked back (and yes, it was couple of years ago, and no, I won't try the latest version, because I don't see one reason why I should). Multiple unnamed heads in my branches were one of the biggest pet-peeves I had with hg. Yes, I tried all methods how to get rid of them I found on the Internet, and no I have never found a reliable way how to avoid them. So, if the need to invent short brief name for every branch I make is the price to pay for sanity, I am all for it. I have never needed to ask my hosting server admins for wiping out my git repos and starting over, I had to do it three times with one project in hg. Never again!
  4. Also, I disliked I couldn't overwrite history (yes, I know about mq extension and other hopeless hacks which try to make hg model at least somehow palatable, but I just prefer git rebase -i), and that branches are more or less permanent (yes, again, I know there is some hack around that).
[1]I know there are a way better introductions to git, but the first good description of how to work with git in the collaborative manner for me was (yes, it is possible that this page was the best product of whole Empathy project ;)).

Category: computer Tagged: blogComment git DVCS mercurial gitlab


Page 1 of 1