3 ms·

Hacks upon hacks upon hacks. On the inside, Git is a thing of beauty, marvel of engineering. On the outside, it is a mess of inconsistent command line options,

Hacks upon hacks upon hacks. On the inside, Git is a thing of beauty, marvel of engineering. On the outside, it is a mess of inconsistent command line options, terrible documentation, and snobbish community that thinks everything of this is fine and small surface details are irrelevant as long as the core works exactly as advertised. They probably also work in Emacs with default keymap.

arunc 10y ago
That's what I felt too. I started using mercurial and I never looked back at git. Mercurial CLI is a pleasure to work with.
- randomsearch 10y ago
  Without starting a VCS war: +1 for Mercurial. If, like me, you do not have a good memory for arbitrary syntax, then mercurial is a lot easier. Takes a bit of cognitive load away from using your VCS. It is thus also much easier to learn than git, so the cost of giving it a whirl is much lower. It also has that nice feeling of being designed with the end user interface in mind, which is satisfying if you care about such things. I enjoy using tools that give me clarity about what I'm doing, and mercurial achieves this by carefully separating the different actions VCS must support. (I regularly use both systems and have done so for years. I am not a power user. I use mercurial whenever I have a choice).
sangnoir 10y ago
> On the inside, Git is a thing of beauty, marvel of engineering. On the outside, it is a mess of inconsistent command line options, terrible documentation, and snobbish community that thinks everything of this is fine and small surface details are irrelevant as long as the core works exactly as advertised The core working exactly as advertised is vitally important! Rotten core + shiny, 'user-friendly' exterior would be a polished turd. I do agree - the outside of git didn't have to be ugly and I'm yet to meet any git 'apologist' who disagrees or thinks it's fine. In mitigation though, the git command can be wrapped by friendlier CLI tools or GUIs. Git has succeeded largely in part of the massive tooling around it - things like GitHub would have been less likely to exist had Git's internal data structures been opaque or poorly designed. It might be instructive to hear it from the horses mouth: Linux, on git "git actually has a simple design, with stable and reasonably well-documented data structures. In fact, I'm a huge proponent of designing your code around the data, rather than the other way around, and I think it's one of the reasons git has been fairly successful […] I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important."

arunc 10y ago

That's what I felt too. I started using mercurial and I never looked back at git. Mercurial CLI is a pleasure to work with.

randomsearch 10y ago
Without starting a VCS war: +1 for Mercurial. If, like me, you do not have a good memory for arbitrary syntax, then mercurial is a lot easier. Takes a bit of cognitive load away from using your VCS. It is thus also much easier to learn than git, so the cost of giving it a whirl is much lower. It also has that nice feeling of being designed with the end user interface in mind, which is satisfying if you care about such things. I enjoy using tools that give me clarity about what I'm doing, and mercurial achieves this by carefully separating the different actions VCS must support. (I regularly use both systems and have done so for years. I am not a power user. I use mercurial whenever I have a choice).

sangnoir 10y ago

> On the inside, Git is a thing of beauty, marvel of engineering. On the outside, it is a mess of inconsistent command line options, terrible documentation, and snobbish community that thinks everything of this is fine and small surface details are irrelevant as long as the core works exactly as advertised The core working exactly as advertised is vitally important! Rotten core + shiny, 'user-friendly' exterior would be a polished turd. I do agree - the outside of git didn't have to be ugly and I'm yet to meet any git 'apologist' who disagrees or thinks it's fine. In mitigation though, the git command can be wrapped by friendlier CLI tools or GUIs. Git has succeeded largely in part of the massive tooling around it - things like GitHub would have been less likely to exist had Git's internal data structures been opaque or poorly designed. It might be instructive to hear it from the horses mouth: Linux, on git "git actually has a simple design, with stable and reasonably well-documented data structures. In fact, I'm a huge proponent of designing your code around the data, rather than the other way around, and I think it's one of the reasons git has been fairly successful […] I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important."