[GTALUG] What good is GIT's "index"?

[Anthony de Boer]

D. Hugh Redelmeier via talk wrote:
> In my workflow, the index is almost always identical to the
> repository.  I almost never use "git add" (which affects the index but
> not the repo).  I almost always use "git commit -a" which updates both
> the index and the repo at the same time.

The index is effectively the working candidate version of the project
that will be the next commit.  Doing "git commit -a" runs past that at
high speed, going straight from the working tree via the index into a
commit in the repository, so you're not really using it.  The other
workflows, with intermediate versions of a further-changed file in the
index, or selected changes staged there, or as resolving-ground[0] of a
nasty merge conflict, make more use of the index.  It does involve
storing all your new files in the repository; the index then records the
OID of each, along with the mtime etc of the files in your working tree,
which helps git very rapidly scan your working tree and tell you what is
or isn't added.  Other than that you could almost think of it as a
candidate-tree OID for the next commit.

Git is a collection of tools to cover just about everyone's different
workflow, so there are a lot of bits that we're not all expected to use,
or that might be extra moving pieces to get in our way.  Sometimes it's
not until you have a particular issue to crack, or have multiple
developers committing to the same project at the same time, or have to
comply with some maintainer's repo policy, that the use of a particular
tool suddenly makes sense.

[0] Why would it be that after some decades of Unix, I can't spell
"resolving" without stopping at the "v"?

-- 
Anthony de Boer