如何重设工作目录中的所有文件，而不是暂存区中的所有文件? [英] How to reset all files from working directory but not from staging area?

问题描述

是否可以重设工作目录中的所有文件，而不能重设暂存区中的文件?

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?

推荐答案

但是是否有任何命令可以重置整个工作目录，而保留暂存区域不变?

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

使用Git 2.23(2019年第三季度)时，可以使用: git restore .

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

要回答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来源的详细信息

请参见提交97ed685 ，提交bcba406 (2019年6月20日)，提交4e43b7f ，提交1235875 ，，提交4df3 ，提交2f0896e ，，提交e3ddd3b ，提交4058199 ，提交be8ed50 ，提交c9c935f ，提交46e91b6 (2019年4月25日)和 Junio C Hamano-gitster-在

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:将其一部分拆分为新命令'restore'

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

以前，"git checkout"的交换分支业务变为 新命令"switch" .这会添加restore命令来检出路径path.

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

类似于git-switch，添加了一个新的手册页来描述该命令将成为什么.该实现将很快更新以匹配手册页.

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.

与'git checkout <paths>'的几个主要区别:

• 'restore'默认情况下只会更新工作树.
  当指定--source时，这更重要('checkout <tree> <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'可用于还原索引.
  此命令与"git reset <paths>"重叠.

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

当同时指定了--staged和--worktree时，也可​​以同时从树中恢复
• 工作树和索引.这与'git checkout <tree> <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>'

恢复工作树和索引的
• 默认来源分别是索引和HEAD.可以使用--source(*)指定不同的(树)源.

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

• 同时还原索引和工作树时，必须指定--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默认情况下处于启用状态，如果源中缺少条目，则还原意味着删除该条目

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

(*)我最初使用的是--from而不是--source.
我仍然认为--from是一个更好的名称.短选项-f已被force所采用.我确实认为短期选择是很好的选择，例如写-s@或-s@^而不是--source=HEAD.

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

(**)如果您坐下来考虑一下，将工作树的源从索引移动到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年第三季度)之前，"git checkout"和"git restore"可以从树状结构(通常为HEAD)重新填充索引，但对于已删除并随后使用意图添加(ita或i-t-a)再次添加的路径无法正常工作位，当相应的工作树文件为空时.
此问题已得到纠正.

---

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.

请参见提交620c09e (2019年8月1日)和瓦伦·奈克(varunnaik).
帮助:杰夫·金(peff).
^{(由 Junio C Hamano-gitster-在}

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:取消暂存空的已删除ita文件

checkout.c: unstage empty deleted ita files

可以从索引中删除已提交的文件，然后添加它 作为要添加的意图.
在git checkout HEAD <pathspec>之后，文件的索引和HEAD应该相同.如果该文件在HEAD中包含内容，则该命令已正确运行.即使文件在HEAD中为空，此修补程序也可以提供所需的行为.

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>用fn调用tree.c:read_tree_1() 指向checkout.c:update_some().
update_some()创建一个新的缓存条目，但是当其模式和oid与旧条目的模式和oid匹配时将其丢弃. ita文件的缓存条目和空文件的缓存条目具有相同的oid.因此，以前有一个空的已删除ita文件 通过了这两项检查，并且新条目被丢弃，因此 文件在索引中保持不变.
修复之后，如果文件在缓存中标记为ita，那么我们避免丢弃新条目，而是将新条目添加到缓存中.

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.

---

在Git 2.25(2020年第一季度)中，git restore解析其选项的功能更强大.

---

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

请参见提交169bed7 (2019年11月12日)通过.
^(由 Junio C Hamano-gitster-在

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

parse-options :避免对可能为NULL的指针进行算术

^{签名人:RenéScharfe}

parse_options_dup()计算不包含结束标记的给定数组中的元素数，分配足够的内存以容纳所有元素以及结束标记，然后复制它们并终止新数组.

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.

该函数还准备处理传递给它的NULL指针.它的调用方目前都没有这样做，但是 46e91b663b ("checkout:将其一部分拆分为新命令'restore''，2019-04-25，Git v2.23.0-rc0-

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.

但是，当它尝试计算"NULL-0&"时，最终在该NULL指针上进行了算术运算，这在标准C中是未定义的.

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)不支持NULL指针，即使对于空数组也是如此.

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

请改用COPY_ARRAY，它确实支持这种空数组.

Use COPY_ARRAY instead, which does support such empty arrays.

通过自动推断元素类型，它的调用也更短，更安全.

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

Coccinelle和contrib/coccinelle/array.cocci不建议使用COPY_ARRAY，因为指针相减并且由于源是const，因此语义补丁谨慎地仅考虑相同类型的指针和数组引用.

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"没有正确更新缓存树结构，导致伪树随后被写入，已得到纠正.

---

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.

请参见讨论

请参见提交e701bab (2020年1月8日)通过 Junio C Hamano-gitster-在

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

restore :使用--staged删除条目时会使缓存树无效

^{举报人:Torsten Krah
签名人:杰夫·金}

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

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

当" git restore --staged "删除索引中的路径，并用CE_REMOVE,标记该条目，但我们不会做任何使缓存树无效的操作.
在非暂存的情况下，我们以checkout_worktree()结尾，该调用称为remove_marked_cache_entries().实际上，这会删除索引中的条目，并使缓存树和未跟踪的缓存无效.

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.

但是对于--staged，我们从不调用checkout_worktree()，并且保留CE_REMOVE条目.有趣的是，当我们写出索引时，它们将被删除，但这意味着结果索引是不一致的:其缓存树将与实际条目不匹配，并在运行"git commit"紧接着将创建错误的树.

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.

我们可以通过在编写索引之前自行调用remove_marked_cache_entries()来解决此问题.请注意，我们不能仅仅将其从checkout_worktree()吊起；该功能需要在CE_REMOVE条目上进行迭代(以删除其匹配的工作树文件)，然后再将其删除.

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.

关于测试的好奇心:没有此补丁，它实际上在运行git-restore时会触发一个BUG():

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

但是在原始问题报告中，该报告使用了类似的配方， git restore 实际上创建了伪索引(并且使用错误的树创建了提交).我不确定为什么这里的测试与我的非常规复制品表现不同，但是这里的内容应该可以捕获任何一种症状(并且此修复程序可以纠正这两种情况).

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(由使用).

---

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

请参见提交7a9f8ca ，提交f904f90 ，提交a277d0a (2020年2月9日)，通过RenéScharfe(rscharfe).
^{(由 Junio C Hamano-gitster-在}

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 :简化parse_options_dup()

^{签名人:RenéScharfe}

通过利用以下事实将其简化为parse_options_concat()的包装，从而简化parse_options_dup():后者也复制其输入，并且附加空集是无操作的事实.

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.

这篇关于如何重设工作目录中的所有文件，而不是暂存区中的所有文件?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！