11 ms·

Git Koans (2013)

197 points by mmettler 6y ago

deleted 6y ago
[deleted]
l0b0 6y ago
tl;dr: Rehash of common Git gripes in the form of sarcastic koans. Funny & true, though.
- mewse 6y ago
  Also seven years old, now (link should probably have a (2013) on it), and many of the complaints have been addressed in the intervening time. For example, in regards to the first one (someone wanting pulls to fail if they’d trigger a merge instead of doing the merge automatically), modern git now gives you an option to enforce that restriction explicitly: `git config -global pull.ff only`, rather than trying to hack the behaviour together via an alias. Modern git is actually pretty pushy about that particular setting, these days! Until you’ve configured how you want to handle pulls, it pesters you to specify which pulling behaviour you want every time you pull changes into any repo from anywhere!
  - shakezula 6y ago
    I just always rebase :shrug:
    - mewse 6y ago
      In that case, you can use: `git config -global pull.rebase true` After that, `git pull` will automatically attempt to rebase your local commits on top of new commits pulled from a remote, so you don’t even have to do it manually. (I still do it manually, though, because I’m a little bit paranoid about my version control and prefer to do my merges/rebases explicitly, with a lot of extra testing and inspection. Though obviously that won’t work for everyone in every codebase!)
      - derefr 6y ago
        What I'd really like, is something in-between auto-rebase and ff-only: automatically try to "re-arrange" my commits and the upstream's commits so that they apply cleanly, but if there isn't a way to do that, then just refuse to do anything, rather than putting me in conflict-edit "both modified" mode.
        atq2119 6y ago
        Sounds fair, though you should be able to `git rebase --abort` when you get into that mode so it's not a huge deal. (I'm not 100% sure since I almost never use `git pull`; I almost always `git fetch`.) I can see how a "rebase with auto-abort" would be helpful in some situations, though.
        throwawaw 6y ago
        a "dirty" rebase sets $? to 1, so I think the auto-abort feature is just `git rebase foo || git rebase --abort`.
  - Zarel 6y ago
    The first one isn't criticizing the lack of ability to set default pull behavior, it's criticizing that if you try to set an alias overriding a built-in command, it fails silently, instead of giving any indication that your alias doesn't work. Basically all the criticisms in Git Koans still apply.
amingilani 6y ago
I was recently told by someone that since 2.23 `git switch` lets you switch branches. It was made to address the fact that `checkout` does too many things. Here: https://git-scm.com/docs/git-switch https://git-scm.com/docs/git-switch
- _ikke_ 6y ago
  And the counterpart to switch is restore: https://git-scm.com/docs/git-restore https://git-scm.com/docs/git-restore
  - divbzero 6y ago
    Thank you, both switch and restore are new to me. That said, checkout behaves quite predictably once you learn it, so I’ll probably wait for the “THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.” warnings to disappear before adopting the newer commands.
  - uses 6y ago
    To me, restore is one of the most frightening commands in git. It has an innocuous name but it can delete arbitrary amounts of uncommited work without any further interaction, warnings, or confirmation.
dang 6y ago
If curious see also 2017 https://news.ycombinator.com/item?id=13379572 https://news.ycombinator.com/item?id=13379572 2015 (a bit) https://news.ycombinator.com/item?id=9926330 https://news.ycombinator.com/item?id=9926330 Discussed at the time: https://news.ycombinator.com/item?id=5511863 https://news.ycombinator.com/item?id=5511863
vrnvu 6y ago
The writting style reminded me of the famous tao of programming: https://www.mit.edu/~xela/tao.html https://www.mit.edu/~xela/tao.html
windowojji 6y ago
See also Vim koans https://sanctum.geek.nz/arabesque/vim-koans/ https://sanctum.geek.nz/arabesque/vim-koans/
patrec 6y ago
Sadly the inconsistent and baroque command line interface of git for basic stuff is the least of its problems -- learning it is just a one time sunk cost every developer has to pay these days. What's more troubling is that git can't do some very basic stuff well, like merging branches. I mean you can do the merge, but good luck trying to revert it[+] or trying to get git to deal intelligently with non-linear history in general. Another fun thing is that every git repo starts its life with an off-by-one error: there is no canonical (and identical) first "root" commit, a NIL commit if you will. This is unfortunate for two reasons: 1. A lot of common scripting idioms will break on the first actual commit (e.g. finding changed files via git diff --name-only A A^ will not work if A is the first commit; yes it's possible to work around that, just like you can write shell scripts that deal with filenames with spaces). Also, it would be convenient in many cases to have an canonical initial empty NIL commit as symbolic reference, similar to how having HEAD is handy. 2. More subtle: the fact that there is no common shared root commit between arbitrary repos makes a couple of things more involved and confusing than they would otherwise be, for example rewriting several different repos into one after the fact. In theory it would be possible to work around that by everyone agreeing on a canonical first commit to start each repo with, but in practice that's of course unlikely to happen. Lastly, and not entirely unrelated: many, but no good solutions for sub-repositories. [+] https://github.com/git/git/blob/master/Documentation/howto/revert-a-faulty-merge.txt https://github.com/git/git/blob/master/Documentation/howto/r...
- tcoff91 6y ago
  What VCS does a significantly better job on branch merges? All the other ones that I've experienced were horrifying. Merging subversion branches was a nightmare compared to git. Perforce was better than subversion but still pretty bad compared to git. I've also reverted merges many times in git with no issue. You just choose which parent you're reverting to and then it just works. The only time I've seen branch merges in git really fuck up is one time when a novice git user at my company unstaged a file from the index before committing the merge. That was a disaster and took me hours to figure out what the hell was going on with that file.
  - patrec 6y ago
geluso 6y ago
I like the one called "The Hobgoblin." The student asks "why don't all these commands follow the same pattern?" It doesn't make sense to my why the three "view" commands have different nomenclatures, but it /sort of/ makes sense that the two destructive ones have different syntaxes. It would hurt to think you're deleting a remote reference and accidentally deleting a local branch. What's the point of the Master throwing himself off the railing when the novice runs `git -h branch`? I'm running it and git responds "unknown option: -h" then displays a short version of the help menu. Maybe it is a joke on showing the short help menu even when using incorrect syntax?
- boublepop 6y ago
  Hopefully someone can correct me if wrong, but I assumed that the joke was that 7 years ago in 2013 if you ran “got - branch” the cli would crash in some way. Though I would love to hear an explanation for someone who knows for sure what the intention of the joke was.
- aelred 6y ago
  I think it's just another inconsistency: `git --help branch` gives the long help for `git branch`, but `git -h branch` says "unknown option: -h".
chrisweekly 6y ago
Haha, these are brilliant! I love git but these are just spot-on. :)
NotPavlovsDog 6y ago
If you like the koan format, you might like to check out Lisp koans (Common Lisp), which I found to be quite enjoyable. https://github.com/google/lisp-koans https://github.com/google/lisp-koans
- dotancohen 6y ago
  Might I be mistaken that the VIM Koans were the original? https://sanctum.geek.nz/arabesque/vim-koans/ https://sanctum.geek.nz/arabesque/vim-koans/ The fine article also mentions the VIM Koans.
  - NotPavlovsDog 6y ago
    I'm actually not sure which one was the original, as I got introduced to the programming koans genre well long after it had been established.

Git Koans (2013)

197 points by mmettler 6y ago

deleted 6y ago

[deleted]

l0b0 6y ago

tl;dr: Rehash of common Git gripes in the form of sarcastic koans. Funny & true, though.

mewse 6y ago
Also seven years old, now (link should probably have a (2013) on it), and many of the complaints have been addressed in the intervening time. For example, in regards to the first one (someone wanting pulls to fail if they’d trigger a merge instead of doing the merge automatically), modern git now gives you an option to enforce that restriction explicitly: `git config -global pull.ff only`, rather than trying to hack the behaviour together via an alias. Modern git is actually pretty pushy about that particular setting, these days! Until you’ve configured how you want to handle pulls, it pesters you to specify which pulling behaviour you want every time you pull changes into any repo from anywhere!
- shakezula 6y ago
  I just always rebase :shrug:
  - mewse 6y ago
    In that case, you can use: `git config -global pull.rebase true` After that, `git pull` will automatically attempt to rebase your local commits on top of new commits pulled from a remote, so you don’t even have to do it manually. (I still do it manually, though, because I’m a little bit paranoid about my version control and prefer to do my merges/rebases explicitly, with a lot of extra testing and inspection. Though obviously that won’t work for everyone in every codebase!)
    - derefr 6y ago
      What I'd really like, is something in-between auto-rebase and ff-only: automatically try to "re-arrange" my commits and the upstream's commits so that they apply cleanly, but if there isn't a way to do that, then just refuse to do anything, rather than putting me in conflict-edit "both modified" mode.
      - atq2119 6y ago
        Sounds fair, though you should be able to `git rebase --abort` when you get into that mode so it's not a huge deal. (I'm not 100% sure since I almost never use `git pull`; I almost always `git fetch`.) I can see how a "rebase with auto-abort" would be helpful in some situations, though.
        throwawaw 6y ago
        a "dirty" rebase sets $? to 1, so I think the auto-abort feature is just `git rebase foo || git rebase --abort`.
- Zarel 6y ago
  The first one isn't criticizing the lack of ability to set default pull behavior, it's criticizing that if you try to set an alias overriding a built-in command, it fails silently, instead of giving any indication that your alias doesn't work. Basically all the criticisms in Git Koans still apply.

amingilani 6y ago

I was recently told by someone that since 2.23 `git switch` lets you switch branches. It was made to address the fact that `checkout` does too many things. Here: https://git-scm.com/docs/git-switch https://git-scm.com/docs/git-switch

_ikke_ 6y ago
And the counterpart to switch is restore: https://git-scm.com/docs/git-restore https://git-scm.com/docs/git-restore
- divbzero 6y ago
  Thank you, both switch and restore are new to me. That said, checkout behaves quite predictably once you learn it, so I’ll probably wait for the “THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.” warnings to disappear before adopting the newer commands.
- uses 6y ago
  To me, restore is one of the most frightening commands in git. It has an innocuous name but it can delete arbitrary amounts of uncommited work without any further interaction, warnings, or confirmation.

dang 6y ago

If curious see also 2017 https://news.ycombinator.com/item?id=13379572 https://news.ycombinator.com/item?id=13379572 2015 (a bit) https://news.ycombinator.com/item?id=9926330 https://news.ycombinator.com/item?id=9926330 Discussed at the time: https://news.ycombinator.com/item?id=5511863 https://news.ycombinator.com/item?id=5511863

vrnvu 6y ago

The writting style reminded me of the famous tao of programming: https://www.mit.edu/~xela/tao.html https://www.mit.edu/~xela/tao.html

windowojji 6y ago

See also Vim koans https://sanctum.geek.nz/arabesque/vim-koans/ https://sanctum.geek.nz/arabesque/vim-koans/

patrec 6y ago

Sadly the inconsistent and baroque command line interface of git for basic stuff is the least of its problems -- learning it is just a one time sunk cost every developer has to pay these days. What's more troubling is that git can't do some very basic stuff well, like merging branches. I mean you can do the merge, but good luck trying to revert it[+] or trying to get git to deal intelligently with non-linear history in general. Another fun thing is that every git repo starts its life with an off-by-one error: there is no canonical (and identical) first "root" commit, a NIL commit if you will. This is unfortunate for two reasons: 1. A lot of common scripting idioms will break on the first actual commit (e.g. finding changed files via git diff --name-only A A^ will not work if A is the first commit; yes it's possible to work around that, just like you can write shell scripts that deal with filenames with spaces). Also, it would be convenient in many cases to have an canonical initial empty NIL commit as symbolic reference, similar to how having HEAD is handy. 2. More subtle: the fact that there is no common shared root commit between arbitrary repos makes a couple of things more involved and confusing than they would otherwise be, for example rewriting several different repos into one after the fact. In theory it would be possible to work around that by everyone agreeing on a canonical first commit to start each repo with, but in practice that's of course unlikely to happen. Lastly, and not entirely unrelated: many, but no good solutions for sub-repositories. [+] https://github.com/git/git/blob/master/Documentation/howto/revert-a-faulty-merge.txt https://github.com/git/git/blob/master/Documentation/howto/r...

tcoff91 6y ago
What VCS does a significantly better job on branch merges? All the other ones that I've experienced were horrifying. Merging subversion branches was a nightmare compared to git. Perforce was better than subversion but still pretty bad compared to git. I've also reverted merges many times in git with no issue. You just choose which parent you're reverting to and then it just works. The only time I've seen branch merges in git really fuck up is one time when a novice git user at my company unstaged a file from the index before committing the merge. That was a disaster and took me hours to figure out what the hell was going on with that file.
- patrec 6y ago

geluso 6y ago

I like the one called "The Hobgoblin." The student asks "why don't all these commands follow the same pattern?" It doesn't make sense to my why the three "view" commands have different nomenclatures, but it /sort of/ makes sense that the two destructive ones have different syntaxes. It would hurt to think you're deleting a remote reference and accidentally deleting a local branch. What's the point of the Master throwing himself off the railing when the novice runs `git -h branch`? I'm running it and git responds "unknown option: -h" then displays a short version of the help menu. Maybe it is a joke on showing the short help menu even when using incorrect syntax?

boublepop 6y ago
Hopefully someone can correct me if wrong, but I assumed that the joke was that 7 years ago in 2013 if you ran “got - branch” the cli would crash in some way. Though I would love to hear an explanation for someone who knows for sure what the intention of the joke was.
aelred 6y ago
I think it's just another inconsistency: `git --help branch` gives the long help for `git branch`, but `git -h branch` says "unknown option: -h".

chrisweekly 6y ago

Haha, these are brilliant! I love git but these are just spot-on. :)

NotPavlovsDog 6y ago

If you like the koan format, you might like to check out Lisp koans (Common Lisp), which I found to be quite enjoyable. https://github.com/google/lisp-koans https://github.com/google/lisp-koans

dotancohen 6y ago
Might I be mistaken that the VIM Koans were the original? https://sanctum.geek.nz/arabesque/vim-koans/ https://sanctum.geek.nz/arabesque/vim-koans/ The fine article also mentions the VIM Koans.
- NotPavlovsDog 6y ago
  I'm actually not sure which one was the original, as I got introduced to the programming koans genre well long after it had been established.