Git Koans (2013)

https://stevelosh.com/blog/2013/04/git-koans/

by mettler • 6 years ago

197 65 6 years ago

l0b0• 6 years ago

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

mewse2• 6 years 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• 6 years ago

I just always rebase :shrug:

Zarel• 6 years 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• 6 years 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

_ikke_• 6 years ago

And the counterpart to switch is restore:

https://git-scm.com/docs/git-restore

divbzero2• 6 years 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• 6 years 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• 6 years ago

If curious see also

2017 https://news.ycombinator.com/item?id=13379572

2015 (a bit) https://news.ycombinator.com/item?id=9926330

Discussed at the time: https://news.ycombinator.com/item?id=5511863

vrnvu• 6 years ago

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

windowojji• 6 years ago

patrec18• 6 years 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/r...

tcoff91• 6 years 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.

patrec18• 6 years ago

The problem with reverts of merge commits in git is that it doesn't behave like most people intuitively expect. If you merge B into master, find a problem, revert the merge and push a fix to B and try merging B again most devs would expect the result in master to be equal to having just merged the fixed version of B to begin with. But it ain't so.

I agree of course that SVN is much worse than git for most purposes, although it's still used frequently in preference to git in design artifact heavy settings because it won't choke as quickly as git on binary assets from artists or designers. The question of what tool handles merge commits better is a bit academic to me, so I do not know the answer. The two reasons for this are: 1. there is currently no practical benefit in learning a better VCS given the dominance of git 2. I gave up on using merge with git.

lmm12• 6 years ago

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.

IME Git handles non-linear history pretty well. AFAICT any DVCS will inherently have the same problem; you can't necessarily memory-hole the fact that the merge has happened because other people may already have your merge. What are you claiming is the "right" way to handle that case?

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.

I believe there is a known commit hash that's there in the datamodel. So it would be possible to treat this as NIL with just changes an the UI level. I agree it's a deficiency, though I don't think it's the most important problem with git (the huge inconsistencies around the staging area are much more important IMO).

Lastly, and not entirely unrelated: many, but no good solutions for sub-repositories.

I don't think a good solution is possible, personally. The repository is the unit of history, branching, tagging and so on, and that makes for a nice model that I don't want to change. If you have multiple repositories, it's better to deal with them as such.

patrec18• 6 years ago

The issue is not one of memory holing: non-merge commit reverts work as people expect (and leave a historical record). I think the right way handle this in git, in most cases, is to just avoid merging altogether. Do work on feature branches and rebase those into master (possibly adding some meta-info like Feature: 123 to the individual commits as you do the rebase). Apart from not having to explain the semantics of merge reverts to everyone in your team this saves a lot of other conceptual overhead as well.

I disagree that git deals well with non linear history, everything about dealing with non-linear history in git is pretty painful, from bisecting to querying (compare to revsets in mercurial, for example) or logging.

Multiple independent repositories across a single org (working on one product) don't work well, in my experience. Unless your org is large enough to hit scalability problems monorepo seems the way to go with git -- it makes it easy for everyone to find stuff and use a consistent shared "timeline". However, other than submodules and co in git being a tire fire, I see no reason why the same purpose could not be served by subrepos in many cases; what makes you think they are inherently problematic?

patrec18• 6 years ago

What things about the staging area do you dislike at a fundamental level (i.e. going beyond a one-off cost of having to memorize a quirk)?

user-the-name3• 6 years ago

Mercurial subrepos use basically the exact same model as git submodules, but unlike git submodules, they actually work and are useful.

The differences aren't huge, either. It would not take much effort to implement the final 20% of functionality to make git submodules useful. But it's just been left as a half-finished, half-broken feature that is not good for anything.

andreareina• 6 years ago

The commit hashes will be different, but I always start a fresh repo with `git commit --allow-empty -m "initial commit"`

patrec18• 6 years ago

Why not got the whole mile, and do something like this:

    GIT_AUTHOR_NAME='nil' GIT_AUTHOR_EMAIL='nil@example.com' \
    GIT_COMMITTER_NAME='nil' GIT_COMMITTER_EMAIL='nil@example.com' \
    GIT_AUTHOR_DATE='1970-01-01 00:00:01' GIT_COMMITTER_DATE='1970-01-01 00:00:01' \
    git commit --no-gpg-sign --allow-empty -m 'NIL'

This will give you an identical commit hash every time. [Edit: added --no-gpg-sign as suggested in reply below]

JNRowe2• 6 years ago

You can ensure the hashes are consistent by setting GIT_AUTHOR_DATE and GIT_COMMITTER_DATE in your initial commit alias.

They still won't be consistent if you've enabled commit.gpgSign though. So, you'd want --no-gpg-sign on that initial commit or someone to reply with a better idea.

scrollaway2• 6 years ago

I always initialize my repos with git commit --allow-empty -m "Initial commit", for that exact reason. I agree with you that git should provide a root commit on init.

patrec18• 6 years ago

See my reply to sibling on how to do it in a reproducible fashion. Maybe we should just all agree on a canoncial initial commit after all? :)

bmn__• 6 years ago

by everyone agreeing on a canonical first commit

Make git-insert-empty-root a standard.

https://stackoverflow.com/a/14729121

divbzero2• 6 years ago

Not a full solution to the no-common-root challenge but rebase [1] does provide the option to:

  git rebase -i --root

[1]: https://git-scm.com/docs/git-rebase#Documentation/git-rebase...

geluso• 6 years 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• 6 years 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• 6 years 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• 6 years ago

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

NotPavlovsDog2• 6 years 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

dotancohen• 6 years ago

Might I be mistaken that the VIM Koans were the original? https://sanctum.geek.nz/arabesque/vim-koans/

The fine article also mentions the VIM Koans.

NotPavlovsDog2• 6 years 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)

Related Stories