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

问题描述

有没有办法重置工作目录中的所有文件而不是暂存区中的所有文件?

我知道使用以下命令可以重置任何单个文件:

git checkout thefiletoreset.txt

此外，通过使用以下命令，可以将整个存储库重置为上次提交的状态:

git reset --hard

但是有没有什么命令可以重置整个工作目录，而保持暂存区不变?

解决方案

但是有没有什么命令可以重置整个工作目录，而保持暂存区不变?

使用 Git 2.23(2019 年第三季度)，是的，有:git恢复.

如何使用(手册页)

回答 OP 的问题:

# 从 HEAD 内容恢复工作树，不触及索引/暂存区git恢复# 从主内容恢复工作树，不触及索引/暂存区git restore -s master

来自 Git 来源的详细信息

参见 commit 97ed685、commit d16dc42, commit bcba406(2019 年 6 月 20 日)，commit 4e>3a href="https://github.com/git/git/commit/12358755949084392b1112cfb5cb4feb9935331f" rel="nofollow noreferrer">commit 1235875, 提交80f537f ，提交fc991b4 , commit 75f4c7c，提交 2f0896e, 提交 a5e5f39, commit/3a737ce54262brefrn09700700000000000000000000013a733ce、提交 e3ddd3b、commit 183fb44, commit 4058199, commit a6cfb9b, commit be8ed50, commit c9c, commit c9c,3a href="https://github.com/git/git/commit/46e91b663badd99b3807ab34decfd32f3cbf15e7" rel="nofollow noreferrer">commit 46e91b6(2019 年 4 月 25 日)和 commit 328c6cb(2019 年 3 月 29 日)由 Nguyễn Thái Ngọc Duy (pclouds).
^{(由 Junio C Hamano 合并 -- gitster -- 在 commit f496b06，2019 年 7 月 9 日)}

<块引用>

checkout:将它的一部分拆分为新命令 'restore'

<块引用>

以前'git checkout'的切换分支业务变成了一个新的命令'切换'.这为检出路径添加了 restore 命令.

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

与git checkout "的几个主要区别:

• 'restore' 默认只会更新工作树.
  这在指定 --source 时更重要('checkout <tree> <paths>' 更新工作树和索引).

• 'restore --staged' 可以用来恢复索引.
  此命令与 'git reset ' 重叠.

• 当 --staged 和 --worktree 都被指定时，也可以同时(从树中)恢复工作树和索引.这与 'git checkout <tree> 重叠.<路径>'

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

• 当索引和工作树都恢复时，必须指定--source，因为这两个单独目标的默认源不同(**)

• --no-overlay 默认开启，如果源中缺少某个条目，则恢复意味着删除该条目

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

(**) 如果你坐下来考虑一下，将工作树的源从索引移到 HEAD 是有道理的，但是当他们输入命令时，没有人真正考虑过.

---

在 Git 2.24(2019 年第三季度)之前，git checkout"和git restore"；可以从树形(通常是 HEAD)重新填充索引，但对于已删除然后使用 intent-to-add (ita) 再次添加的路径无法正常工作或 ita) 位，当对应的工作树文件为空时.
这已得到纠正.

参见 commit 620c09e(2019 年 8 月 1 日)，以及 commit ecd7204(2019 年 8 月 2 日)来自 Varun Naik (varunnaik).
帮助者:Jeff King (peff).
^{(由 Junio C Hamano 合并 -- gitster -- 在 commit 072735e，2019 年 8 月 22 日)}

<块引用>

checkout.c:取消暂存空的已删除 ita 文件

<块引用>

可以从索引中删除一个提交的文件然后添加它作为意图添加.
在 git checkout HEAD 之后，文件的索引和 HEAD 应该相同.如果文件在 HEAD 中有内容，则该命令已经正常工作.即使文件在 HEAD 中为空，此补丁也能提供所需的行为.

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

---

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

参见 commit 169bed7(2019 年 11 月 12 日)René Scharfe (``).
^{(由 Junio C Hamano 合并 -- gitster -- 在 commit 406ca29，2019 年 12 月 1 日)}

<块引用>

parse-options:避免对指针进行算术运算这可能是 NULL

^{签字人:René Scharfe}

<块引用>

parse_options_dup() 计算给定数组中没有结束标记的元素的数量，分配足够的内存来保存所有元素加上结束标记，然后复制它们并终止新数组.

计数部分是通过在数组中前进一个指针来完成的，并且在复制操作之前使用指针减法重建原始指针.

该函数还准备处理传递给它的 NULL 指针.目前没有一个调用者这样做，但是这个功能被 46e91b663b ("checkout:将它的一部分拆分为新命令restore""，2019-04-25，Git v2.23.0-rc0 -- 合并 列在 merge#4);似乎值得保留.

当它尝试计算NULL - 0"时，它最终会对该 NULL 指针进行算术运算，而标准 C 中未定义该指针.>

最好通过记住最初给定的指针值来避免这样做.

不过，还有一个问题.

memcpy(3) 不支持 NULL 指针，即使对于空数组也是如此.

改用COPY_ARRAY，它确实支持这样的空数组.

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

Coccinelle 和 contrib/coccinelle/array.cocci 没有建议使用 COPY_ARRAY 因为指针减法和源是 const -- 语义补丁谨慎只考虑相同类型的指针和数组引用..

---

在 Git 2.25.1(2020 年 2 月)中，git restore --staged"没有正确更新cache-tree结构，导致后面写了假树，已更正.

参见讨论

请参阅 commit e701bab(2020 年 1 月 8 日)https://杰夫·金 (peff).
^{(由 Junio C Hamano 合并 -- gitster -- 在 commit 09e393d，2020 年 1 月 22 日)}

<块引用>

restore:删除时缓存树无效带有 --staged

的条目

^{报告人:Torsten Krah
签字人:Jeff King}

<块引用>

当 "git恢复 --staged "删除索引中的路径，它用 CE_REMOVE, 标记条目，但我们不会做任何使缓存树无效的事情.
在非暂存情况下，我们最终进入 checkout_worktree()，它调用 remove_marked_cache_entries().这实际上会从索引中删除条目，并使缓存树和未跟踪缓存无效.

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

我们可以通过在写出索引之前自己调用 remove_marked_cache_entries() 来解决这个问题.请注意，我们不能只是将它从 checkout_worktree() 中提升出来；该函数需要在删除它们之前迭代 CE_REMOVE 条目(以删除它们匹配的工作树文件).

对测试的一个好奇:如果没有这个补丁，它在运行 git-restore 时实际上会触发一个 BUG():

BUG: cache-tree.c:810: new1 with flags 0x4420000 不应该在缓存树中

但在原始问题报告中，使用了类似的配方，git restore 实际上创建了虚假索引(并且提交是用错误的树创建的).我不确定为什么这里的测试与我的套件外复制的行为不同，但是这里的内容应该可以捕捉到任何一种症状(并且修复可以纠正这两种情况).

---

在 Git 2.26(2020 年第一季度)中，清理了 parse_option_dup(由 git restore 使用).

参见 提交 7a9f8ca、commit c840785, 提交 f904f90、提交 a277d0a(09 年 2 月 20 日之前)a href="https://github.com/rscharfe" rel="nofollow noreferrer">René Scharfe (rscharfe).
^{(由 Junio C Hamano 合并 -- gitster -- 在 提交 cbecc16，2020 年 2 月 17 日)}

<块引用>

parse-options:简化parse_options_dup()

^{签字人:René Scharfe}

<块引用>

简化 parse_options_dup() 使其成为 parse_options_concat() 的简单包装，利用后者也复制其输入并附加一个空的事实set 是空操作.

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?

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.

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