Book Review: Pragmatic Version Control Using Git [LWN.net]

Book Review: Pragmatic Version Control Using Git

Posted Apr 16, 2009 16:04 UTC (Thu) by bronson (subscriber, #4806)
In reply to: Book Review: Pragmatic Version Control Using Git by nye
Parent article: Book Review: Pragmatic Version Control Using Git

Oof, that's really too bad. The index / cache / staging ambiguity is probably the single most confusing part of trying to learn git. That's where I've had to spend most of my time explaining things anyway, merge commits are a distant second.

Most people have memorized "git diff --cached" as an idiom. The word "cache" doesn't appear anywhere in git add's help page, the word "index" doesn't appear anywhere in the help for --cached, and "staging" has been scattered all throughout the docs but rarely connects to "index" or "cache".

Now, what does "git-diff-index --cached "do? Why should this require yet another trip to the docs? It's a mess.

Consistent naming would make Git a lot more usable.

Unfortunately, this leads to quite a poor first impression. It has contributed to a lot of people believing that Git internals are complex and chaotic when they're actually simple and rather pretty.

Is my experience atypical? Is there any other concept that causes as much trouble for people trying to learn git? (an honest question, not rhetorical at all!)

(Log in to post comments)

Book Review: Pragmatic Version Control Using Git

Posted Apr 19, 2009 1:38 UTC (Sun) by jlokier (subscriber, #52227) [Link]

Your experience is similar to mine. I tried to learn Git twice, and decided it wasn't worth it both times. (I'll try again one of these days...)

I could understand some of the excellent tutorials which are around. The concepts are nice, and easy enough. I love data structures. But the terminology and command structure didn't help: I'd never have confidence that I wasn't going to accidentally wreck my repository - or someone elses - by accidentally not using the right set of obscure options to each command.

Book Review: Pragmatic Version Control Using Git

Posted Apr 23, 2009 14:37 UTC (Thu) by Duncan (guest, #6647) [Link]

I figured this was basic *ix sysadmin/developer strategy, but as soon as I
begin to get familiar enough with a command set I'm going to be using
regularly to discern what commands and variants I'll be using frequently,
I generally setup scriptlet/alias wrappers expressing the commands as I
interact with and think of them. Characteristically, these wrappers are
far shorter than the original commands, and devoid of slightly difficult
to touch-type characters like =/-/+. I might use g* to indicate git
commands, and gru for git remote update, for instance.

When there's enough scriptlet/alias task families that the short-form
namespaces start colliding, it's time to make them switchable. Put the
scriptlets in their own subdir and add it to the path. or source the alias
file to turn it on for instance, and remove it from the path and hash -r
or source the alias unsetter file to turn it off. It's also easy enough
to extend any supplied tab-completion scripts to include the wrappers as
well, making things even easier, as one then has /both/ tab-completion and
naturally/logically expressed wrappers to help them.

One quickly finds themselves with a set of 2-4 letter commands, obtuse to
others perhaps, but easy enough for the individual to work with as they've
been effectively customized to match his own thought processes. This
technique has certainly served me well over a reasonable range of task
families here, and generally, one either finds themselves learning the
commands and options the individual letters correspond to almost by
accident, if the mapping to the original commands is close enough (as I
did with my distribution's package management commands and options, for
instance), or can quickly lookup the wrapper to see what it does and
invoke the appropriate original command with appropriate modification as
necessary (as I've done with my kernel fetch/config/compile/install
scripts, for instance).

Book Review: Pragmatic Version Control Using Git

Posted May 12, 2009 0:56 UTC (Tue) by fbriere (subscriber, #4961) [Link]

> Is my experience atypical? Is there any other concept that causes as much trouble for people trying to learn git? (an honest question, not rhetorical at all!)

As much as I love git, it's been over a year, and I still occasionally get confused with checkout vs. reset, path vs. no path, --hard vs. --mixed, etc.

And wait until you realize that git will gladly let you commit to a detached HEAD. Be prepared to fish from the reflog if you checkout another branch before realizing what you did. (This was deemed a "cool" feature on the mailing-list, and is therefore unlikely to go away.)