Git koans

Post by chrismorgan » Mon, Apr 08, 2013, 4:07 PM UTC

stevelosh wrote: post #29

the_mitsuhiko wrote: post #19

A 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…

1. If a new version of git adds a command that shadows one of your aliases, you'd really prefer "git foo" to silently run the new command? That's better than telling you "hey this isn't going to do what you think any more"? Do you have `try: foo except: pass` in your Python code too? Come on. There's no reason git shouldn't at least warn you on stderr here. 2. `git checkout -- somefile.py` does not have anything to d…

Post by philwelch » Mon, Apr 08, 2013, 4:08 PM UTC

pilgrim689 wrote: post #22

kevingadd wrote: post #3

The '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…

Although in implementation, a commit is not done on a branch, for the user, that is precisely what happens. You checkout a branch and you do a commit while on that branch. Thus, to the novice, it might be perfectly normal to expect Git to tell him what branches the commit was made on , even though that makes no sense from Git's point of view. I've never had that use case (knowing what branch a commit was made on ), b…

Post by the_mitsuhiko » Mon, Apr 08, 2013, 4:14 PM UTC

tootie wrote: post #33

the_mitsuhiko wrote: post #26

Earlier 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). 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.

Post by josso » Mon, Apr 08, 2013, 4:16 PM UTC

ozh wrote: post #31

The best part of this article IMO is the scrolling header on the left hand. Nice touch.

Post by aidenn0 » Mon, Apr 08, 2013, 4:17 PM UTC

philwelch wrote: post #53

pilgrim689 wrote: post #22

Earlier quoted context omitted.

Although in implementation, a commit is not done on a branch, for the user, that is precisely what happens. You checkout a branch and you do a commit while on that branch. Thus, to the novice, it might be perfectly normal to expect Git to tell him what branches the commit was made on , even though that makes no sense from Git's point of view. I've never had that use case (knowing what branch a commit was made on ), b…

Branches are just mutable pointers to commits. You're imposing a mental model onto Git that simply isn't present. Git is revolutionary, in part, because instead of asking "what's the mental model we want to emulate and then never mind if that matches the implementation", they gave developers credit that they can understand a handful of simple concepts and made the actual design and data model as simple as possible. P…