Re: as promised, docs: git for the confused

[linux@horizon.com]

> I do not necessarily agree with this claim that merging is the
> whole story about index.  As the steps in the hello/example
> tutorial demonstrate, index is used to build up what you will
> commit incrementally, and you can use this facility to view your
> changes incrementally.
> 
> Your workflow could be like this:

(Good example)

> This is sometimes very useful, and I suspect your comment about
> "commit -a will take care of everything, so you do not need to
> know about update-index" is coming from your ignoring this
> aspect of update-index.

Well, yes and no.  I'm quite aware that the index can be used that way,
but I'm less certain it's a good idea.

I have often wished for a very lightweight "snapshot" feature that I could
(say) put in a Makefile at the end of every successful compile.  I don't
want to share those snapshots with the world, and I'll delete them next
"real" commit, but they'll help me recover if I fumble-finger something.

Think of it as an undo feature.  (With, of course, additional features
like the ability to see diffs between various stages.)

You can use the index as a one-level undo feature in a similar way.
Or maybe, since it's manual, its like hitting save from an editor.
Either way, the fact that it's only one level means that I have to
think about what I'm throwing away when I use it, which is somewhat
annoying.


Add that to the fact that it's unlike other version control systems
(including cogito) which go straight from the working directory into
the history, and I thought it better do downplay it.

Certainly I think that people will *usually* just "git-commit -a" to
commit their current version.  Edit, compile, test, commit.  Except in
unusual cases, I want the commit to reflect what I just tested.

Using git-update-index in the meantime is an optional extra.