Git:无法撤消本地更改(错误:路径...未合并)

发布于 2024-09-04 20:13:58 字数 1057 浏览 5 评论 0原文

我有以下工作树状态

$ git status foo/bar.txt
# On branch master
# Unmerged paths:
#   (use "git reset HEAD <file>..." to unstage)
#   (use "git add/rm <file>..." as appropriate to mark resolution)
#
#       deleted by us:      foo/bar.txt
#
no changes added to commit (use "git add" and/or "git commit -a")

文件 foo/bar.txt 在那里,我想再次将其恢复到“未更改状态”(类似于“svn revert”):

$ git checkout HEAD foo/bar.txt
error: path 'foo/bar.txt' is unmerged
$ git reset HEAD foo/bar.txt
Unstaged changes after reset:
M       foo/bar.txt

变得令人困惑:

$ git status foo/bar.txt
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       new file:   foo/bar.txt
#
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   foo/bar.txt
#

现在它 两个部分中的同一文件,新修改了吗?我应该怎么办?

I have following working tree state

$ git status foo/bar.txt
# On branch master
# Unmerged paths:
#   (use "git reset HEAD <file>..." to unstage)
#   (use "git add/rm <file>..." as appropriate to mark resolution)
#
#       deleted by us:      foo/bar.txt
#
no changes added to commit (use "git add" and/or "git commit -a")

File foo/bar.txt is there and I want to get it to the "unchanged state" again (similar to 'svn revert'):

$ git checkout HEAD foo/bar.txt
error: path 'foo/bar.txt' is unmerged
$ git reset HEAD foo/bar.txt
Unstaged changes after reset:
M       foo/bar.txt

Now it is getting confusing:

$ git status foo/bar.txt
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       new file:   foo/bar.txt
#
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   foo/bar.txt
#

The same file in both sections, new and modified? What should I do?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(8

单身情人 2024-09-11 20:13:58

你做错了方法。您应该首先重置以取消暂存文件,然后签出以恢复本地更改。

试试这个:

$ git reset foo/bar.txt
$ git checkout foo/bar.txt

You did it the wrong way around. You are meant to reset first to unstage the file, then checkout to revert local changes.

Try this:

$ git reset foo/bar.txt
$ git checkout foo/bar.txt
身边 2024-09-11 20:13:58

这对我来说非常有效:

$ git reset -- foo/bar.txt
$ git checkout foo/bar.txt

This worked perfectly for me:

$ git reset -- foo/bar.txt
$ git checkout foo/bar.txt
傲性难收 2024-09-11 20:13:58
git checkout origin/[branch] .
git status

// 注意末尾的点 (.)。一切都会好的

git checkout origin/[branch] .
git status

// Note dot (.) at the end. And all will be good

半夏半凉 2024-09-11 20:13:58

如果上述答案不起作用,请尝试:

git reset --merge

If the above answers didn't work try:

git reset --merge
青衫负雪 2024-09-11 20:13:58

在最近的 git 版本中,git Restore 被认为是比重载的 checkout 恢复不需要的本地更改的“更好”方法。太棒了,这听起来很合理——一个很好的、简单的、专门为常见操作而构建的工具。

但是,这是我新的“最喜欢的” git bug。是的,我知道一些 git-head 会说,“这不是一个错误,这是设计使然的”。但对于这种用户界面,我支持“bug”绰号:(

% git restore LEGAL
error: path 'LEGAL' is unmerged
# okay, fine...
% git restore --ignore-unmerged LEGAL
warning: path 'LEGAL' is unmerged
# Arg, what?!

由 git 2.25.1 提供)

首先是一个小问题:当一个工具由于特定条件而拒绝执行某些操作时,它不仅仅是一个警告。至少应该说操作没有执行。现在我必须去调查该操作是否确实执行了(提示:没有执行)。

当然,第二个问题是显而易见的。现在,让我们看一下手册页条目,看看为什么这个神奇的工具不能执行我告诉它的操作:

   --ignore-unmerged
       When restoring files on the working tree from the index, do not
       abort the operation if there are unmerged entries and neither
       --ours, --theirs, --merge or --conflict is specified. Unmerged
       paths on the working tree are left alone.

天哪!我想这里针对用户界面问题的 git-ish 修复是将选项从 --ignore-unmerged 重命名为 --ignore-unmerged- except-in-cases-where-我们不想允许这样——先咨询文档,然后查看源代码,然后在您无法弄清楚时再咨询专家团队——然后等待-其中一半人争论为什么它是正确的,而另一半人则主张添加四个以上选项作为解决方案.

然后去社区寻找解决方案。我赌你。

显然,我的参考文献没有处于可以通过从工作文件到暂存区域的提交来解决树形斑点的状态...错误索引?

In recent git versions, git restore is supposed to be a "better" way to revert undesired local changes than the overloaded checkout. Great, that sounds reasonable - a nice simple purpose-built tool for a common operation.

But, here's my new "favorite" git bug. Yes, I know some git-head is going to say, "It's not a bug, it's by design". But with this kind of user interface, I stand by the "bug" moniker:

% git restore LEGAL
error: path 'LEGAL' is unmerged
# okay, fine...
% git restore --ignore-unmerged LEGAL
warning: path 'LEGAL' is unmerged
# Arg, what?!

(brought to you by git 2.25.1)

First the minor issue: when a tool refuses to do something because of a particular condition, it's not just a warning. At least it should say the operation was not performed. Now I have to go investigate whether the operation was actually performed or not (hint: it wasn't).

The second issue, of course, is obvious. Now, let's look at the man page entry to see why this fantastic tool won't do what I am telling it to do:

   --ignore-unmerged
       When restoring files on the working tree from the index, do not
       abort the operation if there are unmerged entries and neither
       --ours, --theirs, --merge or --conflict is specified. Unmerged
       paths on the working tree are left alone.

Holy smokes! I guess the git-ish fix for the user interface problem here will be to rename the option from --ignore-unmerged to --ignore-unmerged-except-in-cases-where-we-do-not-want-to-allow-that--consult-documentation-then-source-code-then-team-of-gurus-when-you-cannot-figure-it-out---and-wait-while-half-of-them-argue-about-why-it-is-right-as-is-while-the-other-half-advocate-adding-four-more-options-as-the-fix.

Then go to the community to find out a fix. I dare you.

Obviously, I didn't have my refs in a state where the tree-ish blobs could be resolved with the commit-ishes from working file to staging area... err index?

清晨说晚安 2024-09-11 20:13:58

修复未合并路径错误的“现代”方法,当您使用 restore 命令弹出存储时可能会发生这种情况(自 git v2.23,2019 年 8 月起):

# unstage the file
git restore --staged myfile

# restore the file (lose your working dir changes)
git restore myfile

The "modern" way to fix the unmerged path error, which can happen when you pop your stash, using the restore command (since git v2.23, Aug 2019):

# unstage the file
git restore --staged myfile

# restore the file (lose your working dir changes)
git restore myfile
吲‖鸣 2024-09-11 20:13:58
git checkout foo/bar.txt

你试过吗? (没有 HEAD 关键字)

我通常以这种方式恢复我的更改。

git checkout foo/bar.txt

did you tried that? (without a HEAD keyword)

I usually revert my changes this way.

濫情▎り 2024-09-11 20:13:58

我发现 git stash 对于所有“脏”状态的临时处理非常有用。

I find git stash very useful for temporal handling of all 'dirty' states.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文