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.
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 <a href="https
