And to be fair your point is entirely opinion based anyways. You don't like git (fair enough), but you might be getting bashed because it is a lot of people's tool of choice.
Personally I absolutely love Git.
And to be fair your point is entirely opinion based anyways. You don't like git (fair enough), but you might be getting bashed because it is a lot of people's tool of choice.
Personally I absolutely love Git.
http://www.catb.org/esr/writings/taoup/html/ch01s06.html
There's only a few guidelines there that git obeys. The most obvious one it obeys is "separation".
For example "Clarity is better than cleverness": Git provides a clear internal structure (Blob DAG). It does not try to provide clever merge algorithms, since "Buying a small increase in performance with a large increase in the complexity and obscurity of your technique is a bad trade".
Or another example "Design programs to be connected with other programs". In contrast to Mercurial, many git commands are separate programs and it is trivial to implement your own in any language.
Arguably git violates "In interface design, always do the least surprising thing", since it does not try to provide a comfy start for svn exiles.
If you are learning a set of 'incantations', git will always seem hard to use. But if you take some time to learn how git works on the inside (which is really not that hard), it gets much easier to understand why and how you need to use a certain command.
Some argue that this is why git is bad, but I'd argue that this in the end is a good thing, because it gives you so much more power.
Learning how to use git is an investment, bit in my opinion an investment worthwhile.