Re: VC mode and git

[Stefan Monnier]

> However, with the index, I can do all of these things as soon as I
> feel the need. Then I call up the Magit status buffer which shows me
> all unstaged changes. I go over them and stage only those that I want
> to put in a single commit, e.g. all the spelling fixes. I make a
> commit, then repeat with the reduced set of changes. With a single
> key, I can stage all changes, or all changes to a single file, or an
> individual hunk, or a selected region.

This means you only use the index to do partial commits.
This use-case is typically transient.
But the index is much more omnipresent.

IIUC one of the motivations for the index was also to handle situations
such as: I want to merge a change (with "git merge" or "git stash pop")
into a non-committed tree, and I don't want to commit before the merge
because the pending change is not clean enough (or some other reason).

In this case, a naive "git merge/unstash" would lose information, since
after the merge you get a tree with potential conflicts and no way to go
back to the before-merge state.  The problem here is that the merged
tree may be so messed up that you *do* want to go back.  So the "index"
(and I so agree with Alan that this is a poor choice of name) lets Git
store the "pre-merge" state without actually making a commit.

I've never made use of this "feature", tho.  Just like I never make use
of the "feature" that "git stash pop" keeps the stash if the result
has conflicts, which is a design clearly motivated by the same desire to
make it harder for the user to lose some of the work he's done.


        Stefan