
Git Koans (2013) - oxplot
http://stevelosh.com/blog/2013/04/git-koans/
======
xja
Amusing and depressing, awesome stuff.

Git's rise to become the de facto standard revision control system has been
fascinating to watch.

I think it does provided real benefit over Subversion, but there are also
smaller projects where the gain is marginal.

The tooling around (in particular GitHub) and perception that git is the
"right" way to do things probably helped it achieve prominence. As well as
early adoption by a few high profile projects.

~~~
SOLAR_FIELDS
It's well designed in the open source philosophy. It's designed for people who
are spread all over the world, working together but in seperate, isolated
repositories. There probably well are quite a few use cases where Git is not
the best suited tool for the task. I don't doubt there are several situations
where a team's workflow can be improved and sped up by everyone using SVN,
especially if everyone works together and in the same building for the most
part.

That being said, most complaints about Git are of its difficulty for
newcomers, non straightforward workflow, and lack of clear, concise
documentation. Once the concept is reasonably grok'ed, one would likely be
hard pressed to find a developer who prefers a centralized system such as SVN
over Git.

~~~
throwanem
It's well designed in terms of the underlying concepts and functionality,
which are (mostly) brilliant. Its user interface is a landfill fire.

~~~
geezerjay
> Its user interface is a landfill fire.

Are we talking about the same Git? Its command line interface is quite
straight forward and very simple to use to perform the usual everyday tasks.

Can you actually point out a single example of what you perceive as a
"landfill fire"?

~~~
shaftway
Can you give a succinct definition of what `git add` and `git checkout` do
without relying on documentation?

~~~
geezerjay
Is it that hard to understand that `git add` adds files to the list of files
tracked by the repository (which is updated when changes are committed to it)
and `git checkout` checks out a version that has been previously committed?

I mean, that's pretty much how __all __version control systems operate. Is it
that hard to wrap anyone 's head around the basic functionality that is common
to any version control system in use?

~~~
throwanem
No, it's not that hard to understand. It's also not how Git actually works.
You're ignoring, or perhaps forgetting, the concepts of the index ("staging
area"), and the many and various things which both these commands actually do,
_and_ the fashions in which these sorts of "oh, it's simple, really!" elisions
betray those not yet experienced enough to recognize them for the overextended
abstractions they are.

------
positr0n
Either I don't get most of the koans or they are intended to disparage git's
UX instead of truly enlighten. Is the joke just going over my head or am I not
thinking hard enough?

~~~
delecti
A Koan is "a paradoxical anecdote or riddle, used in Zen Buddhism to
demonstrate the inadequacy of logical reasoning and to provoke enlightenment"

I think that kinda implicitly means the author considers git to be either
paradoxical or illogical. That seems even more clear from the last two
paragraphs of "The Hobgoblin".

~~~
th0114nd
I didn't read the hobgoblin the same way as the author being purely critical.
I read it as a defense: a similarity between commands would make it easier to
choose the wrong one. Removing a branch is a more destructive than deleting a
file, so it should be a command chosen with conscious care rather than muscle
memory.

~~~
sidhantgandhi
That's the absolute opposite conclusion from what the author intended.

~~~
adamrezich
Are you the author? Or, if not, did the author specify their intended
conclusions in additional material somewhere?

------
shakencrew
This has been discussed on Hacker News before:
[https://news.ycombinator.com/item?id=5511863](https://news.ycombinator.com/item?id=5511863)

------
pwdisswordfish
To be honest, this is the first criticism of Git I've read that I can see
making concrete, coherent, _actionable_ points. And I actually agree with some
of them.

Most other complaints about git I've seen seem to be of the vague 'but git is
sooooo confusing' sort, which just invites people to talk past each other.

------
ebola1717
I was expecting an interactive koan like
[http://rubykoans.com/](http://rubykoans.com/)

It's my favorite way to learn the syntax for a new language.

Also, should the checkout one be enlightening? I never thought about it,
despite using git every day, but overloading git checkout like that seems like
it should be confusing.

~~~
sixo
I think the point is that these things should not require enlightenment, but
do. They ARE confusing. These are the kinds of examples that people have in
mind when every git thread devolves to an argument over whether it's a good
tool, power vs UX, because apparently that's a tradeoff you have to make.

~~~
throwanem
Mercurial's UX is miles better, and to the best of my understanding, its guts
are conceptually very similar. It's slow on larger repos and histories, but
other than that, I don't see why it doesn't get more love.

------
closed
Approaches like these seem packed with mnemonic benefits. As I read, I kept
thinking about how I would try to assemble something like this about git, and
the result is a really sort of intriguing learning experience.

(any other good examples of things like this?)

------
mooneater
"How can I find out which branch each parent was originally made on" \-- ouch.
Ive dreamed of automatically tacking on branch names to commit messages to
solve this very issue.

~~~
an_account
As long as the branch hasn't been deleted, it's possible to figure out based
on the commits, correct? (Not exactly easy, but possible.)

And if the branch has been deleted, which typically happens after merging,
then there's not much reason to know the branch name.

Is there something I'm missing here?

~~~
KayEss
> then there's not much reason to know the branch name

Most likely the branch names give you a good deal of information in working
out why things have happened.

~~~
qznc
That information should be in the merge commit message. If you merge something
git will offer you a default commit message like "Merge branch 'foo'".

(assuming a non-fast-forward commit, where the branch is not really a branch
because nothing happens in parallel)

~~~
lmm
So can I ask git to show me the merge commit that relates to the commit I'm
looking at?

------
xgbi
For those wondering for the first, from the help:

> To avoid confusion and troubles with script usage, aliases that hide
> existing Git commands are ignored.

------
jubalfh
To add a bit more context: I think that the author came to use git /after/
they learned mercurial. For a long time mercurial's history was completely
immutable, and hg's branches are very different from git ones (the mercurial
equivalent of git branches is called bookmarks).

------
SilasX
On the hobgoblin one it makes fun of how deleting a branch vs a remote use
inconsistent syntax.

I would add a third example, deleting a remote branch, which (at least as of
2013) is

    
    
        git push <remote name> :<branch name>
    

Neither `-d` nor `rm`!

~~~
glitchdout
That hasn't been true since 2010-02-13, when Git v1.7.0 was released.

[https://github.com/git/git/blob/master/Documentation/RelNote...](https://github.com/git/git/blob/master/Documentation/RelNotes/1.7.0.txt)

------
mrcactu5
there is ClojureScript Koans if you want to learn tiny bits of FP. I held a
meetup event once everyone really liked it. Since we were all learning
JavaScript already

[http://clojurescriptkoans.com/](http://clojurescriptkoans.com/)

------
Walkman
I love koans and I think it is the best way to learn.

