git - 如何从工作目录而不是从暂存区重置所有文件？

Question

有没有办法重置工作目录中的所有文件而不是临时区域中的文件？

我知道使用以下命令可以重置任何单个文件:
git checkout thefiletoreset.txt
此外，通过使用以下命令，可以将整个存储库重置为上次提交的状态:
git reset --hard
但是是否有任何命令可以重置整个工作目录，而保持暂存区不变？

Answer 1

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

使用 Git 2.23(2019 年第三季度)，是的: git restore .
使用方法 ( man page )
要回答 OP 的问题:

# 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

来自 Git 源的详细信息
见 commit 97ed685 , commit d16dc42 , commit bcba406 (2019 年 6 月 20 日)， 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 (2019 年 4 月 25 日)和 commit 328c6cb (2019 年 3 月 29 日) 来自 Nguyễn Thái Ngọc Duy ( pclouds ) .
(由 Junio C Hamano -- gitster -- merge 于 commit f496b06 ，2019 年 7 月 9 日)

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.

在 Git 2.24(2019 年第 3 季度)之前，“ git checkout”和“ git restore”可以从树形(通常是 HEAD)重新填充索引，但对于删除然后再次添加的路径无法正常工作与 意图添加( ita 或 i-t-a )位，当相应的工作树文件为空时。
这已得到纠正。
见 commit 620c09e (2019 年 8 月 1 日)和 commit ecd7204 (2019 年 8 月 2 日) 来自 Varun Naik ( varunnaik ) .
求助者: Jeff King ( peff ) .
(由 Junio C Hamano -- gitster -- merge 于 commit 072735e ，2019 年 8 月 22 日)

checkout.c: unstage empty deleted ita files

It is possible to delete a committed file from the index and then add itas 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 fnpointing 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 previouslypassed both of these checks, and the new entry was discarded, so thefile 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.

使用 Git 2.25(2020 年第一季度)， git restore更健壮地解析它的选项。
见 commit 169bed7 (2019 年 11 月 12 日)来自 René Scharfe (``) .
(由 Junio C Hamano -- gitster -- merge 于 commit 406ca29 ，2019 年 12 月 1 日)

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..

在 Git 2.25.1(2020 年 2 月)中，“ git restore --staged”没有正确更新缓存树结构，导致之后写入假树，这已得到纠正。
见 discussion
见 commit e701bab (2020 年 1 月 8 日) 来自 Jeff King ( peff ) .
(由 Junio C Hamano -- gitster -- merge 于 commit 09e393d ，2020 年 1 月 22 日)

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).

使用 Git 2.26(2020 年第一季度)， parse_option_dup (由 git restore 使用)被清理。
见 commit 7a9f8ca , commit c840785 , commit f904f90 , commit a277d0a (2020 年 2 月 9 日) 来自 René Scharfe ( rscharfe ) .
(由 Junio C Hamano -- gitster -- merge 于 commit cbecc16 ，2020 年 2 月 17 日)

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.