有没有办法存储当前的 git 索引，`git add -u`，然后将索引恢复到存储的 state？

Question

The idea here is that I want to (temporarily) stage all pending changes, then later undo it, without ever changing files in the working tree. It seems like it should be in the domain of git stash , but I can't figure out how to make it happen using that command. Thanks!

Answer 1

Edit: regarding your comment :

@phd sure, that's how I can grab an initial snapshot of the working copy+index state. But the challenge is how to roll back to that state after git add -u without changing any files in the working copy .

For reference, the @phd here is looking at an answer involving a git stash store of the result of a git stash create . The git stash create operation first creates two trees: one is the result of git write-tree (as outlined below), and the other is in effect the result of copying the index to a temporary index, running git add -u , and then running git write-tree again, all using the temporary index. These two trees—if they're written at all; git stash create does nothing when your index and working tree are both "clean"—are then wrapped up into the I and W commits described in the git stash documentation , and git stash create prints the hash ID of the W commit (suitable for use with git stash store ).

Note that your working tree is not disturbed by this part of the operation. There is nothing to restore. What disturbs your working tree is the git reset step of git stash push . But git stash create does not run this step! It just makes the I and W commits. So if that's all you want, git stash create will get you what you want.

my project has a pre-commit hook that lints only the staged file states...

In this case, why not:

• make the W commit (use git stash create if you like), then
• optionally, give that a temporary branch name just for sanity purposes, then
• use git worktree add to check out that branch, or that commit as a detached-HEAD, then
• run the pre-commit hook over the added work-tree.

If the linter is really well behaved, you could perhaps skip the added worktree entirely and just set GIT_INDEX_FILE to a temporary file into which you read the tree from the W commit, and run the linter with that GIT_INDEX_FILE setting in place.

[Edit 2:] If the linter is really well behaved—few of them seem to be this well-behaved—you should be able to just set GIT_INDEX_FILE to a temporary file, run git add -u , run the linter, and then remove the temporary file. Of course it might be even easier to run the linter over the working tree, rather than over an index. That requires a pre-commit linter that is flexible: it can either use a working tree (ignoring the existence of Git entirely) in the style of older, dumber, non-Git-aware linters; or use a Git index. This would be a lot faster and easier overall.

[original answer below line]

---

I think we have an XY problem here, but just to answer the question as asked:

• there's no point as there is only one index; but
• you can temporarily use a temporary index; and
• you can literally do that, it's just pointless.

The way Git uses the index is complicated, so there are many rough edges here. You could cut yourself on any of them. For instance, the index could have assume-unchanged and/or skip-worktree bits set on particular entries, or could be in the expanded state that Git uses in the middle of a conflicted merge (including cherry-pick, revert, and rebase operations). But in general, the index can be turned into one of Git's internal tree objects at almost any time using git write-tree :

hash=$(git write-tree) || echo "unable to turn index into a tree"

This write-tree operation fails if the index is in the expanded, unmerged state; otherwise, it succeeds, even if there are some flag bits set. If it succeeds, hash now contains the hash ID of a tree object. This tree object will live on in the repository for at least 14 days by default, so you have up to 14 days to create a commit that uses it, or otherwise link to it with a tag or some other reference, which will keep it alive more permanently.

Having written out the index as a tree, you can now do anything you like to the index, including running git add -u . Later, you can restore the index to the state it has in that saved tree using git read-tree :

git read-tree $hash || echo "unable to restore index"

The read-tree operation can fail in various cases; consult the documentation . Some flags make some operations succeed or fail when they might otherwise fail or succeed respectively, and you can also completely empty the index first, then read into it, for instance.

To use a temporary index, set the environment variable GIT_INDEX_FILE to the name of the temporary index file. This file must either not exist at all, or be a valid index file. An empty file (as made by mktemp for instance) is not suitable. You can, however, use:

TF=$(mktemp) || exit
rm -f $TF                     # remove it now
trap "rm -f $TF" 0 1 2 3 15   # arrange to remove it on exit or signal
export GIT_INDEX_FILE=$TF     # point Git at this name from here on

in sh or bash scripts. (Use a similar construct in whatever language you like.) Operations will now create an index and fill it in, using the temporary file, so you can now fiddle with that, without affecting the real index. Run Git commands with GIT_INDEX_FILE unset to use the real index, and with GIT_INDEX_FILE=$TF to use the temporary index:

git read-tree --empty        # create empty $TF index file
echo "temp index contents:"
git ls-files --stage

echo "real index contents:"
(unset GIT_INDEX_FILE; git ls-files --stage)

# back to using the temporary index in $TF

for instance will demonstrate the effect. The last line uses a subshell so as to unset the environment variable for the duration of the final git ls-files , but retain the environment variable in the mainline execution, for whatever commands come after the final comment.

As always, temporary objects created for whatever purpose—including any blobs you might put in the temporary index—have that 14-day grace period to turn into real commits. After that, git gc might remove them, even if you are not yet done with them.