8 ms·

Git Koans (2013)

194 points by oxplot 10y ago

ebola1717 10y ago
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 10y ago
  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 10y ago
    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.
- alyandon 10y ago
  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. :)
xja 10y ago
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 10y ago
  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 10y ago
    It's well designed in terms of the underlying concepts and functionality, which are (mostly) brilliant. Its user interface is a landfill fire.
    - geezerjay 10y ago
      > 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"?
      - cellularmitosis 10y ago
        This is the most obscure command mentioned in the article: git rev-parse --abbrev-ref HEAD
      - shaftway 10y ago
        Can you give a succinct definition of what `git add` and `git checkout` do without relying on documentation?
        10y ago
positr0n 10y ago
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?
- rout39574 10y ago
  Yeah, I read it as jeering, too.
- treve 10y ago
  It is meant as a bit of a joke.
- delecti 10y ago
  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 10y ago
    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 10y ago
      That's the absolute opposite conclusion from what the author intended.
      - adamrezich 10y ago
        Are you the author? Or, if not, did the author specify their intended conclusions in additional material somewhere?
closed 10y ago
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?)
shakencrew 10y ago
This has been discussed on Hacker News before: https://news.ycombinator.com/item?id=5511863 https://news.ycombinator.com/item?id=5511863
mooneater 10y ago
"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 10y ago
  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 10y ago
    > 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.
    - mooneater 10y ago
      This
    - qznc 10y ago
      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 10y ago
        So can I ask git to show me the merge commit that relates to the commit I'm looking at?
  - Vinkekatten 10y ago
    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.
NotThe1Pct 10y ago
Git is Linus' covert way to say fuck you to the universe
Walkman 10y ago
I love koans and I think it is the best way to learn.
jubalfh 10y ago
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 10y ago
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 10y ago
  That hasn't been true since 2010-02-13, when Git v1.7.0 was released. https://github.com/git/git/blob/master/Documentation/RelNotes/1.7.0.txt https://github.com/git/git/blob/master/Documentation/RelNote...
- deleted 10y ago
  [deleted]
- pwdisswordfish 10y ago
  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.
xgbi 10y ago
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.
pwdisswordfish 10y ago
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.
mrcactu5 10y ago
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/

Git Koans (2013)

194 points by oxplot 10y ago

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 10y ago
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 10y ago
  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.
alyandon 10y ago
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. :)

xja 10y ago

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 10y ago
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 10y ago
  It's well designed in terms of the underlying concepts and functionality, which are (mostly) brilliant. Its user interface is a landfill fire.
  - geezerjay 10y ago
    > 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"?
    - cellularmitosis 10y ago
      This is the most obscure command mentioned in the article: git rev-parse --abbrev-ref HEAD
    - shaftway 10y ago
      Can you give a succinct definition of what `git add` and `git checkout` do without relying on documentation?
      - 10y ago

positr0n 10y ago

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?

rout39574 10y ago
Yeah, I read it as jeering, too.
treve 10y ago
It is meant as a bit of a joke.
delecti 10y ago
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 10y ago
  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 10y ago
    That's the absolute opposite conclusion from what the author intended.
    - adamrezich 10y ago
      Are you the author? Or, if not, did the author specify their intended conclusions in additional material somewhere?

closed 10y ago

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

shakencrew 10y ago

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

mooneater 10y ago

"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 10y ago
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 10y ago
  > 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.
  - mooneater 10y ago
    This
  - qznc 10y ago
    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 10y ago
      So can I ask git to show me the merge commit that relates to the commit I'm looking at?
- Vinkekatten 10y ago
  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.

NotThe1Pct 10y ago

Git is Linus' covert way to say fuck you to the universe

Walkman 10y ago

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

jubalfh 10y ago

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 10y ago

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 10y ago
That hasn't been true since 2010-02-13, when Git v1.7.0 was released. https://github.com/git/git/blob/master/Documentation/RelNotes/1.7.0.txt https://github.com/git/git/blob/master/Documentation/RelNote...
deleted 10y ago
[deleted]
pwdisswordfish 10y ago
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.

xgbi 10y ago

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.

pwdisswordfish 10y ago

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.

mrcactu5 10y ago

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/