
Git: A Nightmare of Mixed Metaphors - bellajara
https://ventrellathing.wordpress.com/2013/01/25/git-a-nightmare-of-mixed-metaphors/
======
csense
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>

~~~
JoeAltmaier
Disagree. Its ok to point out the emperor has no clothes, without offering a
working loom and spinning wheel.

~~~
chris_wot
Looks fully clothed to me. Imagining him naked?

~~~
JoeAltmaier
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
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.

------
chris_wot
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...](http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging)

~~~
JoeAltmaier
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
Half of that IS regular terminology. The test of the terms - there's no
equivalent.

------
MrMan
To paraphrase Linus: Mercurial is the only sane choice.

