git's CLI design is byzantine and inconsistent, with terms that are both overloaded and underloaded (many commands do multiple, unrelated things while at the same time many common tasks do not have commands). It's very easy for newcomers to place their local repo into a limbo or failure state that they can't get out of without consulting a git guru. git's error messages and man pages are written for its developers, not for its users. git's overall CLI structure maps poorly onto its underpinnings, half-hiding parts and not explaining the rest. Pushing and pulling have really bizarre default behavior that easily confuse those who have not carefully studied how they work.
git is extremely powerful and is, buried underneath its abysmal UI, a thoughtful and elegant work of engineering. However, as a product it's incredibly difficult to explain to other people. Until you've invested a thoroughly unnecessary amount of time learning its gotchas, quirks, and vagaries it is a monumental pain in the ass to use.
(Don't get me wrong, I use git all the time and appreciate its power. I just wish Linus has asked someone else to design the CLI.)
> git is extremely powerful and is, buried underneath its abysmal UI, a thoughtful and elegant work of engineering. However, as a product it's incredibly difficult to explain to other people. Until you've invested a thoroughly unnecessary amount of time learning its gotchas, quirks, and vagaries it is a monumental pain in the ass to use.
To some extent, the same arguments can be used by newbies against any powerful tool (such as vim).
As far as I am concerned, the gap in power between git and hg is much smaller than the gap in ease of use. The ease-of-use argument is only countered when there is real value to using the more frustrating alternative, and I'm not sure there is with git (besides the existence of GitHub, and the support of Linus Torvalds).
This is precisely the reason I couldn't force myself to use Git. The UI of Mercurial is so much more consistent and intuitive. I find it easier for non-technical people in the company to share files.
That came quite close to happening. Quite quickly after git appeared, several alternative CLI's called porcelains were developed. The most popular was cogito. Git itself quickly stole the nice features from the porcelains withered. At that time only power users used git, so there was little interest in the porcelains and the nicer interfaces were list.
git is extremely powerful and is, buried underneath its abysmal UI, a thoughtful and elegant work of engineering. However, as a product it's incredibly difficult to explain to other people. Until you've invested a thoroughly unnecessary amount of time learning its gotchas, quirks, and vagaries it is a monumental pain in the ass to use.
(Don't get me wrong, I use git all the time and appreciate its power. I just wish Linus has asked someone else to design the CLI.)