4 ms·

Git: A Nightmare of Mixed Metaphors

12 points by bellajara 14y ago

csense 14y ago
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 http://marklodato.github.com/visual-git-guide/index-en.html [2] http://www.git-legit.org/ http://www.git-legit.org/ [3] https://github.com https://github.com [4] http://gitlab.org/ http://gitlab.org/ [5] https://github.com/gitlabhq/gitlabhq https://github.com/gitlabhq/gitlabhq
- JoeAltmaier 14y ago
  Disagree. Its ok to point out the emperor has no clothes, without offering a working loom and spinning wheel.
  - chris_wot 14y ago
    Looks fully clothed to me. Imagining him naked?
    - JoeAltmaier 14y ago
      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?
Joeboy 14y ago
I'm not sure the mixed metaphors are a problem. Cherry picking and pulling from upstream both make sense, and understanding one doesn't interfere with the other. I also doubt there's any set of metaphors you could come up with that would have the kind of consistency required by the author. I am typing this in a box on a page in a window on a desktop on a notebook, and it doesn't seem to bother me.
MrMan 14y ago
To paraphrase Linus: Mercurial is the only sane choice.
chris_wot 14y ago
The only thing remarkable about this blog is how completely unremarkable the concepts chosen by the author really are. Let's go through them: fetch - fetching the objects and metadata from a branch or branches from a remote repository pulling from upstream - fetching from a remote repository (upstream, in other words all the changes flow down the stream to you, colloquial expression), then merge in the objects you fetched cherry pick - choose which changes to apply ("cherry pick" them, colloquial term) filter branch - modify a branch's history via filters untracked - files that aren't being tracked by the source control system symlink - a symbolic link, not even a git concept. rebase - replaying all the changes committed from one branch onto another. Literally taking one base, and changing the base of a branch. i.e. re-basing the branch tag - marking (or "tagging") a significant change in the repository HEAD, head (note, mentioned twice by author) - a reference to the head of the revision history working copy - the copy of a branch that you work on path - really? stash - you start working on some code, then you realise you want to change to another branch. So you stash away the working copy for later. clone - cloning an existing repository so you can have your own to work on. That's why it's a DVCS submodule - an external project from the main repository fast-forward - when you merge a branch from another branch, git has the ability to forward the revision pointer quickly to the right point, see [1] merge - merging changes origin/master - the original repository. Convention. staging area - also known as the "index", basically the concept is that you checkout a branch into a directory (called the working copy, see above), then you commit any changes into a staging area, then you push the changes into the repository See? none of this was particularly hard to understand (although I grant you that "rebasing" and "fast forward" is a tricky concept, but hey, it's a source control system) [1] http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging http://git-scm.com/book/en/Git-Branching-Basic-Branching-and...
- JoeAltmaier 14y ago
  It all goes under the column labelled "Lore of the Jungle". Other tools have regular terminology; GIT seems to have grown its own language.
  - chris_wot 14y ago
    Half of that IS regular terminology. The test of the terms - there's no equivalent.

12 points by bellajara 14y ago

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 http://marklodato.github.com/visual-git-guide/index-en.html [2] http://www.git-legit.org/ http://www.git-legit.org/ [3] https://github.com https://github.com [4] http://gitlab.org/ http://gitlab.org/ [5] https://github.com/gitlabhq/gitlabhq https://github.com/gitlabhq/gitlabhq

JoeAltmaier 14y ago
Disagree. Its ok to point out the emperor has no clothes, without offering a working loom and spinning wheel.
- chris_wot 14y ago
  Looks fully clothed to me. Imagining him naked?
  - JoeAltmaier 14y ago
    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?

Joeboy 14y ago

I'm not sure the mixed metaphors are a problem. Cherry picking and pulling from upstream both make sense, and understanding one doesn't interfere with the other. I also doubt there's any set of metaphors you could come up with that would have the kind of consistency required by the author. I am typing this in a box on a page in a window on a desktop on a notebook, and it doesn't seem to bother me.

MrMan 14y ago

To paraphrase Linus: Mercurial is the only sane choice.

chris_wot 14y ago

The only thing remarkable about this blog is how completely unremarkable the concepts chosen by the author really are. Let's go through them: fetch - fetching the objects and metadata from a branch or branches from a remote repository pulling from upstream - fetching from a remote repository (upstream, in other words all the changes flow down the stream to you, colloquial expression), then merge in the objects you fetched cherry pick - choose which changes to apply ("cherry pick" them, colloquial term) filter branch - modify a branch's history via filters untracked - files that aren't being tracked by the source control system symlink - a symbolic link, not even a git concept. rebase - replaying all the changes committed from one branch onto another. Literally taking one base, and changing the base of a branch. i.e. re-basing the branch tag - marking (or "tagging") a significant change in the repository HEAD, head (note, mentioned twice by author) - a reference to the head of the revision history working copy - the copy of a branch that you work on path - really? stash - you start working on some code, then you realise you want to change to another branch. So you stash away the working copy for later. clone - cloning an existing repository so you can have your own to work on. That's why it's a DVCS submodule - an external project from the main repository fast-forward - when you merge a branch from another branch, git has the ability to forward the revision pointer quickly to the right point, see [1] merge - merging changes origin/master - the original repository. Convention. staging area - also known as the "index", basically the concept is that you checkout a branch into a directory (called the working copy, see above), then you commit any changes into a staging area, then you push the changes into the repository See? none of this was particularly hard to understand (although I grant you that "rebasing" and "fast forward" is a tricky concept, but hey, it's a source control system) [1] http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging http://git-scm.com/book/en/Git-Branching-Basic-Branching-and...

JoeAltmaier 14y ago
It all goes under the column labelled "Lore of the Jungle". Other tools have regular terminology; GIT seems to have grown its own language.
- chris_wot 14y ago
  Half of that IS regular terminology. The test of the terms - there's no equivalent.