TLDR version: The author thought Git was hard. Git would be better if learning it was easier for people in general, and the post's author in particular. This is unquestionably true.
As a guide to understanding Git, the article fails; he mentions many git terms, but doesn't explain any of them. As a guide to others' guides to understanding git, it only mentions one: Mark Lodato's "visual git guide" [1]. There are many, many other tools and guides for learning and enhancing git. One of the blog's commenters mentioned Legit [2], which the blog post's author may personally find useful.
Offering a constructive means to improve Git is the best non-obvious point an article like this can make, but the author doesn't make it: I came away from this article unsure what, if anything, he's advocating for improvement. Better documentation? A better set of commands? A better set of metaphors? A higher-level wrapper? Better GUI tools? More features in web UI's like Github [3] or Gitlab [4] [5]? A complete switch to some other current or future version control system?
To be fair, he does mention a couple of these concepts in passing. But the best way he could help improve the situation is by engaging with them head-on, giving developers something actionable -- working code would be best, but a sketch of a GUI, a spec for a new command-line interface, or an explanation of an improved metaphor for a particularly confusing git concept would also encourage productive discussion. (I don't think much of his advice to "Let people who never learned to program write the next great version control system" (paraphrased) as something that's advisable or even possible.)
Yeah, well, read the article - the guy is mentioning the Git has a steeper learning curve than most tools. Terminology is pointlessly complex. That its unnecessary. Seeing some skin?
Comments
TLDR version: The author thought Git was hard. Git would be better if learning it was easier for people in general, and the post's author in particular. This is unquestionably true.
As a guide to understanding Git, the article fails; he mentions many git terms, but doesn't explain any of them. As a guide to others' guides to understanding git, it only mentions one: Mark Lodato's "visual git guide" [1]. There are many, many other tools and guides for learning and enhancing git. One of the blog's commenters mentioned Legit [2], which the blog post's author may personally find useful.
Offering a constructive means to improve Git is the best non-obvious point an article like this can make, but the author doesn't make it: I came away from this article unsure what, if anything, he's advocating for improvement. Better documentation? A better set of commands? A better set of metaphors? A higher-level wrapper? Better GUI tools? More features in web UI's like Github [3] or Gitlab [4] [5]? A complete switch to some other current or future version control system?
To be fair, he does mention a couple of these concepts in passing. But the best way he could help improve the situation is by engaging with them head-on, giving developers something actionable -- working code would be best, but a sketch of a GUI, a spec for a new command-line interface, or an explanation of an improved metaphor for a particularly confusing git concept would also encourage productive discussion. (I don't think much of his advice to "Let people who never learned to program write the next great version control system" (paraphrased) as something that's advisable or even possible.)
[1] http://marklodato.github.com/visual-git-guide/index-en.html
[2] http://www.git-legit.org/
[3] https://github.com
[4] http://gitlab.org/
[5] https://github.com/gitlabhq/gitlabhq
Disagree. Its ok to point out the emperor has no clothes, without offering a working loom and spinning wheel.
Looks fully clothed to me. Imagining him naked?
Yeah, well, read the article - the guy is mentioning the Git has a steeper learning curve than most tools. Terminology is pointlessly complex. That its unnecessary. Seeing some skin?