git reset documentation — how is it the opposite of git add?

Question

Docs say:

  git reset [-q] [<tree-ish>] [--] <paths>...
This form resets the index entries for all <paths> to their state at <tree-ish>. (It does not affect the working tree or the current branch.)

This means that git reset <paths> is the opposite of git add <paths>.

I kinda think that the "...this means that git reset is the opposite of git add..." is wrong.

If git add copies from working directory to the index, one might think that the opposite of that copies from index to working directory.

But this form of git reset copies from a treeish to the index and git checkout-index would actually do the opposite.

How is it the opposite of git add? If it is not opposite, is it worth trying to update the docs?

`git add` adds changes to the staging area. `git reset` removes changes from the staging area. That is why they are opposites: they undo each other (at least in simple usage, this changes when a tree-ish or `--soft/--hard` are specified). — Colonel Thirty Two, Jul 31 '16 at 00:55
I see what you're saying, and already being familiar with git, I'm inclined to say you're being pedantic. But this sounds like a useful insight for a newcomer, so might make a good point in a blog article. — Jeff Puckett, Jul 31 '16 at 01:20
Also, is it possible to have something in the index that's not already in the working directory? I'm on my phone now, so can't test, but it seems like copying from index to working directory might not be possible. — Jeff Puckett, Jul 31 '16 at 01:22
Jeff, its possible, that's what git checkout-index does. And it is possible to stage directly into the index from the repo, thats what reset with the tree-ish does. If the tree-ish is omitted, then its assumed to be HEAD, so thats where we copy from HEAD to index. But if you had updated working dir and then did the reset HEAD to the index, it doesnt update the working directory . Guys, I understand the -2, this isnt really a good question for SO. — David Neiss, Jul 31 '16 at 01:33
It's worth trying to update the docs if you can improve them. Perhaps you should edit your question with your proposal for community feedback - gonna need to be specific to avoid the off topic opinion based answers though... Not my DV btw — Jeff Puckett, Jul 31 '16 at 01:33
Jeff, yes, realize it wasn't your DV. And I actually agree with the DV, so I'm not too worked up about it. I'm just not connected with any other git groups, so just wanted to throw it out there. — David Neiss, Jul 31 '16 at 04:20

score 2 · Answer 1 · edited May 23 '17 at 11:58

This particular way of describing git reset was introduced in commit 7b8cd49 by Thomas Rast (trast) for Git v1.7.3.2 (July 2010)

At the time, the discussion proposed the initial form

This means that git reset <paths> is the opposite of git add +<paths>, provided that the <paths> were already tracked

Junio C. Hamano commented:

The above is a clearer description of "with-path" mode than what we currently have. I doubt that we need ", provided that...", though.

"git reset HEAD frotz" from a head commit without frotz gets rid of frotz from the index, no?

I mentioned in "git reset vs git reset HEAD" how git reset <tree-ish> <file> unstage (un-add) a file.

When you consider only the index (and not the working directory at all), git reset <tree-ish> <file> is indeed the opposite of git add.

git reset documentation — how is it the opposite of git add?

1 Answers1