How to reset all files from working directory but not from staging area?

Question

Is there a way to reset all files from the working directory but not those from staging area?

I know that using the following command one can reset any single file:

git checkout thefiletoreset.txt

And also that by using the following command it is possible to reset the entire repository to the last committed state:

git reset --hard

But is there any command that can reset the whole working directory, leaving the staging area untouched?

Campy

Does git checkout **/* work? – Ethno

Not sure what you mean by **/* but gave me an idea and it worked! git checkout folder/ – Campy

With Git 2.23, that is git restore. See my answer below – Redeemer

Answer 1

But is there any command that can reset the whole working directory, leaving the staging area untouched?

With Git 2.23 (Q3 2019), yes there is: git restore.

How to use it (man page)

To answer the OP's question:

# restore working tree from HEAD content, without touching the index/staging area
git restore 

# restore working tree from master content, without touching the index/staging area
git restore -s master

Details from Git sources

See commit 97ed685, commit d16dc42, commit bcba406 (20 Jun 2019), commit 4e43b7f, commit 1235875, commit 80f537f, commit fc991b4, commit 75f4c7c, commit 4df3ec6, commit 2f0896e, commit a5e5f39, commit 3a733ce, commit e3ddd3b, commit 183fb44, commit 4058199, commit a6cfb9b, commit be8ed50, commit c9c935f, commit 46e91b6 (25 Apr 2019), and commit 328c6cb (29 Mar 2019) by Nguyễn Thái Ngọc Duy (pclouds).
^{(Merged by Junio C Hamano -- gitster -- in commit f496b06, 09 Jul 2019)}

checkout: split part of it to new command 'restore'

Previously the switching branch business of 'git checkout' becomes a new command 'switch'. This adds the restore command for the checking out paths path.

Similar to git-switch, a new man page is added to describe what the command will become. The implementation will be updated shortly to match the man page.

A couple main differences from 'git checkout <paths>':

• 'restore' by default will only update worktree.
  This matters more when --source is specified ('checkout <tree> <paths>' updates both worktree and index).

• 'restore --staged' can be used to restore the index.
  This command overlaps with 'git reset <paths>'.

• both worktree and index could also be restored at the same time (from a tree) when both --staged and --worktree are specified. This overlaps with 'git checkout <tree> <paths>'

• default source for restoring worktree and index is the index and HEAD respectively. A different (tree) source could be specified as with --source (*).

• when both index and worktree are restored, --source must be specified since the default source for these two individual targets are different (**)

• --no-overlay is enabled by default, if an entry is missing in the source, restoring means deleting the entry

(*) I originally went with --from instead of --source.
I still think --from is a better name. The short option -f however is already taken by force. And I do think short option is good to have, e.g. to write -s@ or -s@^ instead of --source=HEAD.

(**) If you sit down and think about it, moving worktree's source from the index to HEAD makes sense, but nobody is really thinking it through when they type the commands.

---

Before Git 2.24 (Q3 2019), "git checkout" and "git restore" can re-populate the index from a tree-ish (typically HEAD), but did not work correctly for a path that was removed and then added again with the intent-to-add (ita or i-t-a) bit, when the corresponding working tree file was empty.
This has been corrected.

See commit 620c09e (01 Aug 2019), and commit ecd7204 (02 Aug 2019) by Varun Naik (varunnaik).
Helped-by: Jeff King (peff).
^{(Merged by Junio C Hamano -- gitster -- in commit 072735e, 22 Aug 2019)}

checkout.c: unstage empty deleted ita files

It is possible to delete a committed file from the index and then add it as intent-to-add.
After git checkout HEAD <pathspec>, the file should be identical in the index and HEAD. The command already works correctly if the file has contents in HEAD. This patch provides the desired behavior even when the file is empty in HEAD.

git checkout HEAD <pathspec> calls tree.c:read_tree_1(), with fn pointing to checkout.c:update_some().
update_some() creates a new cache entry but discards it when its mode and oid match those of the old entry. A cache entry for an ita file and a cache entry for an empty file have the same oid. Therefore, an empty deleted ita file previously passed both of these checks, and the new entry was discarded, so the file remained unchanged in the index.
After this fix, if the file is marked as ita in the cache, then we avoid discarding the new entry and add the new entry to the cache instead.

---

With Git 2.25 (Q1 2020), git restore is more robust parsing its options.

See commit 169bed7 (12 Nov 2019) by René Scharfe (``).
^{(Merged by Junio C Hamano -- gitster -- in commit 406ca29, 01 Dec 2019)}

parse-options: avoid arithmetic on pointer that's potentially NULL

^{Signed-off-by: René Scharfe}

parse_options_dup() counts the number of elements in the given array without the end marker, allocates enough memory to hold all of them plus an end marker, then copies them and terminates the new array.

The counting part is done by advancing a pointer through the array, and the original pointer is reconstructed using pointer subtraction before the copy operation.

The function is also prepared to handle a NULL pointer passed to it. None of its callers do that currently, but this feature was used by 46e91b663b ("checkout: split part of it to new command 'restore'", 2019-04-25, Git v2.23.0-rc0 -- merge listed in batch #4); it seems worth keeping.

It ends up doing arithmetic on that NULL pointer, though, which is undefined in standard C, when it tries to calculate "NULL - 0".

Better avoid doing that by remembering the originally given pointer value.

There is another issue, though.

memcpy(3) does not support NULL pointers, even for empty arrays.

Use COPY_ARRAY instead, which does support such empty arrays.

Its call is also shorter and safer by inferring the element type automatically.

Coccinelle and contrib/coccinelle/array.cocci did not propose to use COPY_ARRAY because of the pointer subtraction and because the source is const -- the semantic patch cautiously only considers pointers and array references of the same type. .

---

With Git 2.25.1 (Feb. 2020), "git restore --staged" did not correctly update the cache-tree structure, resulting in bogus trees to be written afterwards, which has been corrected.

See discussion

See commit e701bab (08 Jan 2020) by Jeff King (peff).
^{(Merged by Junio C Hamano -- gitster -- in commit 09e393d, 22 Jan 2020)}

restore: invalidate cache-tree when removing entries with --staged

^{Reported-by: Torsten Krah
Signed-off-by: Jeff King}

When "git restore --staged " removes a path that's in the index, it marks the entry with CE_REMOVE, but we don't do anything to invalidate the cache-tree.
In the non-staged case, we end up in checkout_worktree(), which calls remove_marked_cache_entries(). That actually drops the entries from the index, as well as invalidating the cache-tree and untracked-cache.

But with --staged, we never call checkout_worktree(), and the CE_REMOVE entries remain. Interestingly, they are dropped when we write out the index, but that means the resulting index is inconsistent: its cache-tree will not match the actual entries, and running "git commit" immediately after will create the wrong tree.

We can solve this by calling remove_marked_cache_entries() ourselves before writing out the index. Note that we can't just hoist it out of checkout_worktree(); that function needs to iterate over the CE_REMOVE entries (to drop their matching worktree files) before removing them.

One curiosity about the test: without this patch, it actually triggers a BUG() when running git-restore:

BUG: cache-tree.c:810: new1 with flags 0x4420000 should not be in cache-tree

But in the original problem report, which used a similar recipe, git restore actually creates the bogus index (and the commit is created with the wrong tree). I'm not sure why the test here behaves differently than my out-of-suite reproduction, but what's here should catch either symptom (and the fix corrects both cases).

---

With Git 2.26 (Q1 2020), parse_option_dup (used by git restore) is cleaned-up.

See commit 7a9f8ca, commit c840785, commit f904f90, commit a277d0a (09 Feb 2020) by René Scharfe (rscharfe).
^{(Merged by Junio C Hamano -- gitster -- in commit cbecc16, 17 Feb 2020)}

parse-options: simplify parse_options_dup()

^{Signed-off-by: René Scharfe}

Simplify parse_options_dup() by making it a trivial wrapper of parse_options_concat() by making use of the facts that the latter duplicates its input as well and that appending an empty set is a no-op.

Redeemer

Between the forest I'm missing the tree that says how to use it. – Rework

@HenkPoley Good point. I have added an "How to use" section at the beginning of the answer. – Redeemer

Does git restore also work on a subdirectory? I tried and it probably does something else than I was expecting. – Rework

@HenkPoley Sure, like git checkout was before that new command: git restore -- aSubfolder (note the space dash-dash space separator). Without any source/destination parameter, it restores the working tree with HEAD content. – Redeemer

Answer 2

Your original question was not entirely clear to me, but your comments suggest that what you mean is:

How do I copy files from the staging area back to the work-tree?

for which the answer is indeed git checkout. You can give git checkout various options, but the default is to read the current index / staging-area:

git checkout -- file

extracts the version of file from the staging area, to the work-tree, whether or not the staging-area version of file matches the HEAD commit version of file.

As you've seen:

git checkout -- directory

extracts all files whose path name begins with directory/. Since . names the current directory:

git checkout -- .

extracts all files that exist in the index, if you are at the top level of your work-tree.

(The -- here is needed if the file name you want resembles a git checkout option or branch name. For instance, if you want the file named master or -b, git checkout master or git checkout -b will confuse git checkout, but git checkout -- -b master will tell git checkout that -b and master are the names of the two files, not the -b master option. It's good to get into the habit of just using -- automatically here.)

Peroration

Your explanation is good and conclusive, but are not the files copied from the git directory and not from the staging area? Or is the staging area by default a copy of the git directory and thus we copy from it? – Campy

There are three (!) active copies of every file at all times: one in the commit (Git name HEAD:path), one in the index (Git name :0:path), and one in the work-tree (no special Git name since it's just an ordinary file). The HEAD commit copy of every file is read-only but both of the other two are read/write. The checkout verb can copy from HEAD to index and then to work-tree, or from index to work-tree. The add verb copies from work-tree to index (only). The status verb does two diffs: HEAD vs index (anything different is "staged for commit") and then index vs work-tree. – Peroration

So, in short (if it's not too late :-) ), the answer is both no and yes: git checkout copies from commit, or from staging area, depending on how you invoke it. git checkout HEAD -- path means copy HEAD:path to :0:path, then copy :0:path to work-tree. Meanwhile git checkout -- path means copy from :0:path to work-tree. – Peroration