Short of me downing distressing amounts of coffee, could someone explain these please for those of us still trying to grok git?
He's criticizing git.
Git koans
41–50 of 143 posts
Re: Git koans
#42Short of me downing distressing amounts of coffee, could someone explain these please for those of us still trying to grok git?
> pull = pull --ff-only From "git --help config": "To avoid confusion and troubles with script usage, aliases that hide existing git commands are ignored." > “Use git checkout.” This is just a jab at how "checkout" does too many different things. > “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?” Git doesn't let you do this. > “Surely…
But you should recommend 'git help', i.e. the help subcommand, since that's what git refers to on its own.
Re: Git koans
#43Earlier quoted context omitted.
Either you or I have misunderstood the article. These koans aren't criticism. They are stories meant to enlighten readers to lessons regarding git. If you see each of these stories as criticism's about git, then you are the novice. Once you receive enlightenment on each story you will realize why each story is not criticism--you will see the error of the reasoning of the novice in the story and you will understand wh…
Surely you can't say that about `git branch -d` vs. `git rm` and other puzzling inconsistencies.
Yes I can, and am. As pointed out elsewhere, the commands are named for what they do not necessarily for how you would use them.
Re: Git koans
#44Short of me downing distressing amounts of coffee, could someone explain these please for those of us still trying to grok git?
I'm not sure what Silence is about. My git-config-fu fails me. One Thing Well demonstrates how one command (git checkout), while it does do 'one thing well' (changing your working directory to match something in the index), can handle a wide variety of seemingly unrelated use cases. Only the Gods demonstrates how history can mean different things: commit parentage, which is usually immutable, and branch history, whic…
Each git command is a designed tool itself. Others expect it to be 'git' to be the wholly designed tool as one unit, but it's a toolbox.
Re: Git koans
#45The 'Only the Gods' one seems weird to me; maybe I just don't understand Git well enough, but it seems like that one's just a case of failing to understand what a branch is . A particular commit isn't made 'on' a branch, so to speak; it's just a SHA hash that has a particular SHA as a parent. And then a branch is a pointer to a particular SHA. So there's no way to know which branch a commit originated 'on', merely wh…
One thing that does happen though is if you have a non-ff merge, the default commit message has the name of the branch being merged from (though not the branch being merged to).
Re: Git koans
#46Git commands are not consistent. This is a result of it growing organically, and having a maintainer who strongly values backwards compatibility. But you know, having used git for years that doesn't bother me. Let me explain.
Git is conceptually straightforward[1]. It is difficult if not impossible to discern those concepts from its baroque CLI. So learning git from its built-in help and/or man pages is suboptimal if not a complete waste of time. Either read the Pro Git book[2] or pop the hood[3]. Then the inconsistent CLI is no longer a big deal. If it were, someone would have come up with a new porcelain (high-level CLI) that would have taken hold by now. And no one really has. There is Easy Git[4] but I don't know anyone who uses it.
And really, I see git as not much different than Unix in this regard. Unix commands vary widely in their usage. Does knowing awk help with sed? cpio and tar? wget vs curl? Eventually you understand concepts such as pipes, regular expressions, file descriptors, etc and you become familiar with the commands where you are able to apply these concepts, at which point does strict interface consistency between them matter? I dunno, but I started with both git and hg around the same time and ended up happier with git. Mercurial had the "better" CLI, but I found git was better at doing what I wanted. Before that I used clearcase, which has a very consistent CLI and yet I was constantly cursing at it.
Or maybe I just have stockholm syndrome and I'd feel differently if I'd ever used plan 9. :)
1. http://tom.preston-werner.com/2009/05/19/the-git-parable.htm...
Re: Git koans
#47I don't understood the suicidal git thing... Also of course I had to test the help commands! git branch --help opens man git branch -h throws those short commandline help summaries. Interestingly, -h does not mention -h itself or --help, so the only way to know that --help exists, is someone else telling you, you will never find on your own.
Or by using every other Unix command ever.
(Disclaimer: This is a hyperbole.)
Re: Git koans
#48Sometimes I feel like Git is an elaborate troll by Torvalds. Doing my taxes is more intuitive.
It's more like Linus refusing to suffer fools on the largest scale possible.
Re: Git koans
#49I don't understood the suicidal git thing... Also of course I had to test the help commands! git branch --help opens man git branch -h throws those short commandline help summaries. Interestingly, -h does not mention -h itself or --help, so the only way to know that --help exists, is someone else telling you, you will never find on your own.
-h is not a valid option. You could put --floogahbar in there and it'll give you the help by way of response.
Re: Git koans
#50A lot of these are just plain wrong though or have a good reason and it makes me sad because I know Steve Losh uses a lot of Mercurial which I think has a much worse UI. 1. Silence: you can't alias built-in commands — for good reason. You don't change the defaults of commands, that's just going to cause problems with scripts. Why is it ignored silently? For starters because new git versions can add a command that wou…
Your bookmarks swipe, I don't get it?
Branches in mercurial are called Named Branches. And they have the benefit that commits made in the branch will always know where they were created.
They have Bookmarks which really are a better name than "git branches" anyway because you can't really understand branching in Git until you understand that a branch name is just a pointer--a bookmark if you will--to a specific HEAD commit.