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

staging vs index vs cache

Posted Apr 14, 2009 20:32 UTC (Tue) by rfunk (subscriber, #4054) [Link]

Sounds to me like a classic case of developers wanting to use names based
on internal concepts, and users/teachers wanting to use names based on
user-visible behavior. And in this case, the preference for "index"
appears to be primarily for historical reasons. (I can't really blame
them for that.)

As a user, I'd prefer to have both consistent user-visible naming and
naming that's consistent with the behavior I see. Based on that mailing
list post, the developers appear to be already stuck with the
inconsistency of "index" vs "cache", and don't want a third name even if
it's more consistent with the bahavior.

Even (especially) after reading the developer's explanation, I
think "index" is the wrong name for the concept and just adds confusion.
I'm not sure "cache" is much better, though it is a little better.

staging vs index vs cache

Posted Apr 17, 2009 16:58 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

Learning Git, I wasted far too much time and effort trying to reconcile what I was reading about "the index" with my understanding of "index" as a common English (and data processing) word.

In fact, I don't think I ever did figure out what the index is; I eventually had to give up on Git for lack of quality documentation. I'm looking forward to reading this book, especially now that I know the author isn't afraid to improve on classic terminology. Maybe, unlike so many engineers, he's able to place himself in the shoes of a beginner.

Book Review: Pragmatic Version Control Using Git

Posted Apr 16, 2009 16:04 UTC (Thu) by bronson (subscriber, #4806) [Link]

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!)

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