Usually, to discard changes to a file you would do:
git checkout -- <file> What if the change I want to discard is deleting the file? The above line would give an error:
error: pathspec '<file>' did not match any file(s) known to git. What command will restore that single file without undoing other changes?
bonus point: Also, what if the change I want to discard is adding a file? I would like to know how to unstage that change as well.
Assuming you're wanting to undo the effects of git rm <file> or rm <file> followed by git add -A or something similar:
# this restores the file status in the index git reset -- <file> # then check out a copy from the index git checkout -- <file> To undo git add <file>, the first line above suffices, assuming you haven't committed yet.
end-of-options-marker required in the deleted file case only?
git reset HEAD <file>, which is equivalent), but git reset treats its first argument before end-of-options-marker as a ref name, not a file name. Could it be written a bit more flexibly? Probably. Why wasn't it? Probably only the developers know for sure.
git reset filename works fine for non-deleted files.git reset [-q] [<tree-ish>] [--] <paths>.... If your <file> argument matches the name of a <tree-ish> (a branch, or HEAD or a tag or ...), then it's going to do something other than what you might think, if you don't use --. That's the reason it's there.Both questions are answered in git status.
To unstage adding a new file use git rm --cached filename.ext
# Changes to be committed: # (use "git rm --cached <file>..." to unstage) # # new file: test To unstage deleting a file use git reset HEAD filename.ext
# Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # deleted: test In the other hand, git checkout -- never unstage, it just discards non-staged changes.
git status cited; shows users a way to self-help now and next time, and in case information is added or updated in future git versions.
git reset. After the git reset, you see "Changed but not updated" which means "Changes not staged" in the native language of the git authors, apparently. More importantly, the whole dogma about "git status tells you everything you know" is a lie. (Managers who say that are wasting people's time and should be fired.)
git restore --staged deleted-file as of at least git 2.24.3 (but could be earlier versions too)If it has been staged and committed, then the following will reset the file:
git reset COMMIT_HASH file_path git checkout COMMIT_HASH file_path git add file_path This will work for a deletion that occurred several commits previous.
git revert COMMIT_HASHThe answers to your two questions are related. I'll start with the second:
Once you have staged a file (often with git add, though some other commands implicitly stage the changes as well, like git rm) you can back out that change with git reset -- <file>.
In your case you must have used git rm to remove the file, which is equivalent to simply removing it with rm and then staging that change. If you first unstage it with git reset -- <file> you can then recover it with git checkout -- <file>.
I tried the above solutions and I was still having difficulties. I had other files staged with two files that were deleted accidentally.
To undo the two deleted files I had to unstage all of the files:
git reset HEAD . At that point I was able to do the checkout of the deleted items:
git checkout -- WorkingFolder/FileName.ext Finally I was able to restage the rest of the files and continue with my commit.
The answer here already addresses the basic case for unstaging a specific file deletion. However, if you accidentally staged the deletion of many files which are mixed in with changes you want to keep, you can use this pipeline of commands:
git diff --staged --name-status | awk '$1=="D"{print $2}' | xargs git restore --staged -- The first portion, git diff --staged --name-status, shows all the staged changes with a letter to identify the type of change. Deleted files have a "D".
The second portion prints the file name if the status letter (first column) is "D". This effectively filters the list to just the staged deletions.
The last line calls the git restore --staged command (that the other answers have so helpfuly pointed out) for each deleted file. Note that restore requires git 2.23 or newer, otherwise you will need to use a combination of git reset and git checkout (such as is done in this other answer. For more explanation of git restore, see the git docs or this answer.
git: 'restore' is not a git command.
git-restore was introduced in Git 2.23. See stackoverflow.com/questions/66120447/… and git-scm.com/docs/git-restoreFrom manual page,
git-reset - Reset current HEAD to the specified state git reset [-q] [<tree-ish>] [--] <paths>... In the first and second form, copy entries from <tree-ish> to the index. for example, when we use git reset HEAD~1 it reset our current HEAD to HEAD~1
so when we use git reset 'some-deleted-file-path'
git assume 'some-deleted-file-path' as some commit point and try to reset out current HEAD to there.
And it ends up fail
fatal: ambiguous argument 'some-deleted-file-path': unknown revision or path not in the working tree. 