The best part of this article IMO is the scrolling header on the left hand. Nice touch.
Git koans
31–40 of 143 posts
Re: Git koans
#32A 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 critique seems to be based off comparing git to mercurial and declaring that git is designed better. I don't think you're going to see a ton of disagreement with that in this community. You make good points too, with context a lot of those commands make more sense.
However well designed software shouldn't need the context. Well designed software is intuitive. We shouldn't need to know the intricacies in the git data model to able to understand the major commands and tools. As we begin to do more complex operations then more knowledge can be a prerequisite.
The fact that these commands all made sense with a detailed explanation is only a symptom of the problem, not an excuse.
Re: Git koans
#33Earlier quoted context omitted.
I learned hg before git and the experience of switching to git was shockingly bad. I'm comfortable in both now and the big thing I'd miss if I went back to hg would be git stash (and I'm sure there's a hg plugin for it).
> I learned hg before git and the experience of switching to git was shockingly bad. I'm comfortable in both now and the big thing I'd miss if I went back to hg would be git stash (and I'm sure there's a hg plugin for it). What about the index? Or the branching (bookmarks kinda work now I think), or the better remote management?
I personally hate the index. It gets in my way far more often than I actually make use of it.
Re: Git koans
#34A 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…
> There is just a convenience operation on `git checkout` that also changes branches. Isn't that violating 'doing one thing'? (Your other examples in this point are valid, and serve to show how powerful building concepts on top of a few primitives can be, if confusing at times)
Here's how I view the checkout command: It is used to check out stuff from your git database into your working tree. Stuff here means either the whole tree or some files in it. You can check out a whole tree (branch) by specifying its sha1, or you can check out a single file by specifying the tree and the filename. The fact that checkout can be used to create a branch is just a convenience because most of the time it's easier to give the tree sha1 a name to refer to for further git commands.
Re: Git koans
#35Earlier quoted context omitted.
Ah, nothing like pointing out someone else's flaws to feel better about your own. Git is powerful but hard to learn and is often not intuitive. Knowing Hg also has issues doesn't help me when I'm trying to use git.
I just find it unfair criticism because hg has just as many UI kinks or just lack of UI to begin with. `hg diff` or how it's randomly split into different commands with a `-p` flag is just one example.
Hg having kinks is not an excuse for git to have kinks too
Re: Git koans
#36Earlier quoted context omitted.
This may seem like a joke, but having used Hg a little bit, I do think it has a superior interface. The error messages are clear, the commands are intuitive. The command addremove is genius. But I still use git because I already grokked it before I learned hg.
> The command addremove is genius That's the default of what git does even without a command.
No it's not.
[alias]
addremove = !git add . && git add -u
Re: Git koans
#37A 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…
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.
Re: Git koans
#38Earlier quoted context omitted.
This may seem like a joke, but having used Hg a little bit, I do think it has a superior interface. The error messages are clear, the commands are intuitive. The command addremove is genius. But I still use git because I already grokked it before I learned hg.
I learned hg before git and the experience of switching to git was shockingly bad. I'm comfortable in both now and the big thing I'd miss if I went back to hg would be git stash (and I'm sure there's a hg plugin for it).
Switching to git was very easy for me after hg screwed my repo. And git had much saner branching back then, not sure if anything changed in mercurial land.
Re: Git koans
#39Sometimes I feel like Git is an elaborate troll by Torvalds. Doing my taxes is more intuitive.
Wanna trade? I'll do your git if you do my taxes?
Re: Git koans
#40The best part of this article IMO is the scrolling header on the left hand. Nice touch.
Agreed. Reminds me of the list headers in iOS, e.g. in the Address Book.