Git Koans (2013) | Hacker News Reader

Git Koans (2013)

stevelosh.com

194 pointsoxplot50 comments

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.

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.

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

> 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"?

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

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?

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.

I'm talking about the same Git as the article author is. If you have a different Git in mind, please point me to it! Perhaps I would prefer to use that one instead.

I see you failed yet again to provide any example to substantiate your baseless claims.

The article's full of them! That wheel doesn't need reinventing.

I get that you like Git's UI, or at least don't mind it. That's fine. Others feel differently. That's fine too.

This is the most obscure command mentioned in the article:

    git rev-parse --abbrev-ref HEAD

I don't understand the hostility towards it. These types of complaints like "oh if you misuse this tool that you didn't bother learning about, it does things you probably didn't expect" are basically completely useless.

Try randomly slapping your hands on a keyboard and writing software in <insert language>. Now complain that because you can't do that, <insert language> sucks. That's basically how I see these types of complaints about git.

> "oh if you misuse this tool that you didn't bother learning about, it does things you probably didn't expect" are basically completely useless.

These koans point out how the UX of Git often makes it harder (than necessary) to learn.

> try randomly slapping your hands on a keyboard [...] you can't do that

Well it worked when they chose all those command line arugment letters... </s>

He? Branching in GIT is natural thing to do where in SVN it is at least not user friendly.

"Subversion has no internal concept of a branch—it knows only how to make copies"

Now even if I do not need distributed features of git, I have VCS with local repo with git and I have easy branching. So even if I work on my side project I use branching a lot because I can do cheap experiment branches, go back to previous state or pick what I liked in my experiment. For me it is just totally different approach to development. When I stopped using Subversion and started using GIT my world changed for better, GIT gives me more control. I can pick parts of files to be staged or pick what I need to be commited. Where partial commits with subversion is at least black magic.

So even for smaller projects it is like a whole world of difference for using GIT.

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?

Yeah, I read it as jeering, too.

It is meant as a bit of a joke.

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".

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.

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

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

That's a reference to an Emerson quote; if I remember rightly it's "A foolish consistency is the hobgoblin of little minds". I suspect the implication is that only little minds expect consistency... but over and above Emerson being a questionable source for UI design principles, he qualifies it. The quote isn't "Consistency is the hobgoblin of little minds."

I can't speak for the author's intention, but yes, these "koans" highlight some of git's worst UX warts; or, arguably, not just UX warts but conflicts internal to the conceptual underpinnings of git (http://people.csail.mit.edu/sperezde/onward13.pdf).

> but yes, these "koans" highlight some of git's worst UX warts; or, arguably, not just UX warts but conflicts internal to the conceptual underpinnings of git

If that's the case, the "One Thing Well" kohan misses the mark rather glaringly.

I feel like they're meant to be jokey about UX failings, but I'm unsure what the author is trying to convey.

For example:

> [something about history being present and immutable]

>“Splendid!” exclaimed the historian. “I have a historical record of a merge commit with two parents. How can I find out which branch each parent was originally made on?”

>“History is ephemeral,” replied Master Git, “the knowledge you seek can be answered only by the gods.”

the pedantic explanation here is that branches are a separate subsystem, with each branch just being a pointer to a commit. And the history works off of the commit.

The answer from "Master Git" doesn't feel like an answer from a master. Maybe I'm reading too much into this but Git becomes way less confusing if you think more about what things are, rather than how they're used .

That is exactly the joke.

git beats positr0n with its UX

at that moment, positr0n was enlightened

This has been discussed on Hacker News before: https://news.ycombinator.com/item?id=5511863

I was expecting an interactive koan like 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.

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.

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.

I've always thought that site is actually meant to be a clever critique of the absolute mess that is git's command line interface. :)

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.

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?)

"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.

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?

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

This

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)

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

We use Jira and bitbucket - most if not all branch names contain an issue number and the name of the issue, while commit messages can be more cryptic. This is often helpful when the branch has been deleted, as it usually is.

We use bitbucket server for pull requests and merges, and it does this. It's brilliant, since the branch name often describes the solved problem better than the commit messages.

> Ive dreamed of automatically tacking on branch names to commit messages to solve this very issue.

I believe mercurial does this by default. Why not give it a try?

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).

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`!

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

I actually quite like this syntax for deleting remote branches. You can think of it as a special case of

    git push $remote $local_commit:$remote_branch

which updates the remote ref $remote_branch so that it points to $local_commit; here it updates the remote ref so that it points to nothing (which means deleting it). Sure, this is inconsistent with other git commands, but it's not completely illogical. Though I'd probably prefer something like

    git push $remote $remote_branch=$local_commit

where the '=' makes you think of assignment, hinting at what this command actually does.

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/

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

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.

Reply on news.ycombinator.com