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

D. Hugh Redelmeier hugh at mimosa.com
Sat Mar 16 12:06:28 EDT 2019


I use git regularly.  I'll admit that I use it in a stylized way.  The 
index only seems to add confusion and complication.  Is it actually 
useful?

Background:

Git has a hierarchy of copies of the object under management:

- the working tree.  This is the one that you actually edit and use

- the index (which lives inside the .git subdirectory of the working tree)

- the repository (which also lives inside the .git subdirectory)

After this comes a federation of other repositories.  These relationships 
are chosen and configured by whoever manages the local repository.  In the 
simplest non-trivial case, there is a single "upstream" "remote" 
repository.

I'll explain part of my workflow

- to show how the index is used

- to invite suggestions on improving it

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 only time I use the index explicitly is when there is a merge 
conflict.  And that's not by choice: the workflow required to resolve a 
conflict seems to require the index.

Since I don't get a lot of merge conflicts, I don't get a lot of 
experience dealing with them.

Often during development I want to bring my repo up to date with the 
upstream repo.  Here's the procedure I follow:

If I have uncommitted changes the the working tree, save them in the
stash:
	git stash

If I have local committed changes:

	# get upstream commits into our repo, index, and working tree:
	git pull --rebase

	If this results in merge conflicts:
		edit each conflicted file to resolve the problem
		"git add" each such file
		At this point, the index differs from the repo!
		"git commit" the resolution

If I did not have local uncommitted changes, this will do and cannot
result in merge conflicts:
	git pull

If I started out with uncommitted changes (i.e. I stashed them):

	git stash pop

	If this results in merge conflicts:
		edit each conflicted file to resolve the problem
		"git add" each such file
		At this point, the index differs from the repo!
		"git reset" sets the index back to the repo
		(the conflict resolution remains in the working tree)

Done: upstream commits are now in the local repo, the index, and the
working tree.

If you want to, commit any local changes.

If you want to, push local commits upstream.


More information about the talk mailing list