git rebase:“错误:无法统计‘文件’:权限被拒绝”

发布于 2024-11-07 07:34:30 字数 492 浏览 0 评论 0原文

我正在使用 git,先进行了一次小的提交,然后进行了一次大的提交。我决定使用 git rebase 将两个提交压缩在一起,然后再推送它们。 (我以前从未这样做过。)

所以我这样做了:

git rebase -i HEAD~2

这给了我我的编辑器,我选择选择较早的提交并压缩较晚的提交。当我保存时,git 说:

错误:无法统计“文件名”:权限被拒绝

无法将 sha1 应用到稍后的提交...该提交的初始文本行

现在:

  • 当我执行 git log 时,这两个提交都没有出现。
  • git status 告诉我“当前不在任何分支上”。
  • 一个文件列为已修改且位于索引中,两个文件列为未跟踪。我的第一次提交只有一个文件(我认为),而我的第二次提交有十几个文件。

发生了什么!?我该如何修复它?

I'm using git, and made a small commit followed by a large one. I decided to use git rebase to squash the two commits together before pushing them. (I've never done this before.)

So I did:

git rebase -i HEAD~2

This gave me my editor, where I chose to pick the earlier commit and squash the later one. When I saved, git said:

error: cannot stat 'filename': Permission denied

Could not apply sha1 for later commit... initial line of text for that commit

Now:

  • Neither commit appears when I do git log.
  • git status tells me I'm "Not currently on any branch."
  • One file is listed as modified and in the index, and two files are listed as untracked. My first commit had just one file (I think), and my second commit had a good dozen.

What happened!? How do I fix it?

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

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

发布评论

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

评论(30

ㄟ。诗瑗 2024-11-14 07:34:30

尝试关闭所有打开该文件夹的程序,例如编辑器、资源管理器窗口、命令提示符和 FTP 程序。这总能解决我在 Windows 上的问题。

Try closing any programs that have the folder open, such as editors, explorer windows, command prompts, and FTP programs. This always fixes the issue for me on Windows.

时光礼记 2024-11-14 07:34:30

只需关闭您的 IDE(VISUAL STUDIO/ATOM 等)即可。它可能会起作用

Just close your IDE (VISUAL STUDIO/ATOM etc). It might work

洛阳烟雨空心柳 2024-11-14 07:34:30

我只在 Windows 上见过这个错误,它的意思似乎是当 git 尝试应用补丁时,有东西阻止了它修改文件。

Windows 倾向于在不必要的情况下授予进程对文件的独占访问权限,过去病毒检查程序一直是怀疑的来源之一,但我从未最终证明这一点。

也许最简单的事情就是中止并重试,希望下次不会发生这种情况。

git rebase --abort

您可以尝试使用 git apply 并了解提交 git 在执行 git rebase --Continue 之前实际尝试执行的操作,但老实说我不建议这样做。大多数时候,我见过这种尝试,但意外遗漏或弄乱某些东西的可能性比平常更大。

I've only ever seen this error on Windows and what it seems to mean is that something blocked git from modifying a file at the moment when it tried to a apply a patch.

Windows tends to give processes exclusive access to files when it shouldn't really be necessary, in the past virus checkers have been one source of suspicion but I've never proved this conclusively.

Probably the easiest thing to do is to abort and try again, hoping that it doesn't happen the next time.

git rebase --abort

You can attempt to use git apply and knowledge of what commit git was actually trying to do before doing a git rebase --continue but in all honesty I wouldn't recommend this. Most of the times I've seen this tried there's been a better than evens chance that something gets accidentally missed or messed up.

摘星┃星的人 2024-11-14 07:34:30

当我在我的机器上看到这个时,它比“某个进程打开了文件”更糟糕。该文件的实际所有权被提升到我(以管理员身份运行)只能在重新启动后才能访问它的程度。

据我所知,IIS 是问题的一部分。如果我在需要修改大量文件的两个主要分支之间切换,git 将删除一个文件或目录(通常是 DLL),而 IIS 会尝试对其执行某些操作。此时,IIS 进程会自动用锁定且似乎不属于任何人的版本覆盖磁盘上的文件。

此时停止 IIS 并不会起到作用。我发现最好的办法就是重新启动,并记住在将来跨主要分支进行更改之前停止 IIS。

我知道这并不能真正回答问题,但可能对其他人有帮助。

When I see this on my machine, it's worse than just a "some process has the file open". The actual ownership of the file gets jacked up to the point where I (running as administrator) can only access it after rebooting.

Nearest I can tell, IIS is part of the problem. If I switch between two major branches that require a lot of files to modify, git will delete a file or directory (usually DLLs) while IIS is trying to do something or another with it. At this point, the IIS process automatically overwrites the file on disk with a version that's locked and appears to be owned by nobody.

Stopping IIS at this point doesn't do it. Best I've found out to do is to reboot, and remember to stop IIS before changing across major branches in the future.

I know that doesn't really answer the question, but might be helpful to others.

携君以终年 2024-11-14 07:34:30

如果使用 vscode,请终止终端并打开新终端。
否则也可能关闭终端

if using vscode, kill terminal and open new one.
else maybe close terminal too

陈年往事 2024-11-14 07:34:30

在 Windows 上,它可能是阻止这些文件的 TortoiseGIT 进程。
打开任务管理器并结束进程TGitCache.exe

On Windows, it can be a TortoiseGIT process that blocks those files.
Open task manager and end process TGitCache.exe.

生生不灭 2024-11-14 07:34:30

我刚刚偶然发现了这个答案 - 这个错误是一个虚假错误。#
错误:无法统计“reddit/app/views/links”:权限被拒绝

这就是我在尝试合并时得到的全部。
我读了一些答案,然后意识到——我所要做的就是关闭我的代码编辑器,它恰好是 Atom。

关闭编辑器后 - 我再次运行“git merge”,然后繁荣,它起作用了。

多么无意义的错误:(

I just stumbled upon this thread of answers - this error is such a Bogus error.#
error: cannot stat 'reddit/app/views/links': Permission denied

That's all I got - when trying to merge.
I read a few of the answers and then came to the realization - all I had to do was close my code editor which happens to be Atom.

Once closing the editor - I ran "git merge" again and boom , it worked.

What a pointless error:(

不醒的梦 2024-11-14 07:34:30

如果您使用的 IDE(如果您使用一个)也可能会妨碍您。这就是我使用 QtCreator 时发生的事情。

If the IDE you use(in case you use one) might have been getting in the way as well. That's what happened to me when using QtCreator.

戴着白色围巾的女孩 2024-11-14 07:34:30

我在 Windows 中偶尔会发生这种情况

错误:无法统计“文件名”:权限被拒绝

绝大多数情况下,我打开了多个bit bash实例,并且其中一个git bash实例位于我从中提取的远程分支中不存在的目录中。

关闭除一个 git bash 实例之外的所有实例可以解决我的问题。

This happens to me in Windows occasionally

error: cannot stat 'filename': Permission denied

Most often I have multiple instance of bit bash open, and one of the git bash instances is in a directory that doesn't exist in the remote branch I'm pulling from.

Closing all but one instance of git bash solves the issue for me.

一向肩并 2024-11-14 07:34:30

如果您正在运行 webpack,请将其关闭。同时关闭您的 IDE。做完这些事情后应该可以正常工作。

If you're running webpack shut it down. Shut down your IDE as well. Should work fine after doing those things.

绝對不後悔。 2024-11-14 07:34:30

当您使用 SublimeText 并且要求您购买该程序的弹出窗口未关闭时,也可能会发生这种情况。

This can also happen when you're using SublimeText and the popup window asking you to buy the program is not closed.

久伴你 2024-11-14 07:34:30

在Win 10中使用SourceTree,通过关闭Atom编辑器解决了该问题。

错误重现:

  1. 在分支B中,创建一个md文件,使用Atom编辑它,保存并提交。
  2. 切换到分支 A,从服务器拉取新的提交。
  3. 尝试切换回来,Opps,它显示“错误:无法统计'文件':权限被拒绝”。

Using SourceTree in Win 10, fixed the problem by closing Atom editor.

Error reproduce:

  1. In branch B, create a md file, using Atom edit it, save and commit.
  2. Switch to branch A, pull down new commits from server.
  3. Try Switch back, Opps, it says “error: cannot stat 'file': Permission denied”.
她如夕阳 2024-11-14 07:34:30

当您使用预处理软件/应用程序(例如 Prepros 或 Codekit)监视项目时,通常会发生这种情况。此外,如果当前正在编辑项目中的文件,Atom 和 Sublime(甚至 Notepad++)也可能导致这种情况发生。

解决此问题的最简单方法是关闭项目文件打开的所有内容,合并分支,然后重新打开它们以刷新它。这也将避免程序不再意识到已发生的任何更改而迫使您手动刷新项目的任何问题。

This often happens when you have preprocessing software/applications watching the project, such as Prepros or Codekit. Also, Atom and Sublime (and even Notepad++) can cause this to happen if a file in the project is currently being edited.

The easiest way around the issue is to close whatever has the project files open, merge your branches, and then re-open them to refresh it. This will also avoid any problems where the program is no longer aware of any changes that have happened, forcing you to refresh the project(s) by hand.

别靠近我心 2024-11-14 07:34:30

我在 Windows 上在 IntelliJ 集成终端 内进行变基时发生了这种情况。
我注意到我有并行运行的 Git bash 客户端实例。

关闭 Git bash 解决了问题。

Happened to me on Windows while rebasing inside IntelliJ integrated terminal.
I noticed that I had Git bash client instance running in parallel.

Closing Git bash solved the problem.

初与友歌 2024-11-14 07:34:30

尝试关闭 IDE(例如 Sublime、VS Code、Webstorm...)并关闭打开该文件夹的程序(例如 CMD、Powershell、CMDer、Terminal...)将解决该问题。

Trying to close IDE such as Sublime, VS Code, Webstorm,... and close your programs that have the folder open such as CMD, Powershell, CMDer, Terminal,... will fix the issue.

尽揽少女心 2024-11-14 07:34:30

我有类似的问题。但解决起来非常简单。
在一台 Windows 计算机上,我的文件资源管理器打开了一个文件夹,该文件夹存在于一个分支中,但不存在于我签出的另一个分支中。
关闭文件资源管理器解决了该问题。

I had a similar problem. But it was very simple to resolve.
On a Windows machine, my file explorer had a folder open that existed in one branch but not in the other I checked out.
Closing the File explorer resolved the problem.

草莓酥 2024-11-14 07:34:30

我刚刚在 Win 7 下得到了这个。

$ git stash pop
错误:无法统计“父文件夹/子文件夹”:权限被拒绝
错误:无法统计“父文件夹/子文件夹”:权限被拒绝

诊断:

1>我转到子文件夹,它就在那里,但我无法删除它!

2>使用“进程浏览器”->查找->查找句柄和 Dll ->将“子文件夹”名称放在那里并搜索。

结果:事实证明,XMLSpy 已经打开了其中的一个 xml,关闭 XML Spy 并再次尝试 stash pop,现在可以正常工作了。

I have just had this under Win 7.

$ git stash pop
error: cannot stat 'parentFolder/subfolder': Permission denied
error: cannot stat 'parentFolder/subfolder': Permission denied

Diagnosis:

1>I went to the subfolder and it's there and I couldn't delete it !

2>Use "process explorer" -> Find -> Find handles and Dlls -> put the "subfolder" name there and search.

Result: It turns out it's XMLSpy has opened one of the xml there, close XML Spy and try stash pop again, it's working now.

爱给你人给你 2024-11-14 07:34:30

另一种解决方案不是像其他答案所说的那样关闭所有可能锁定目录的应用程序,而是使用一个实用程序来解锁文件/目录而不关闭所有内容。 (我讨厌需要重新启动 Visual Studio)

LockHunter 是我使用的:https://lockhunter.com/可能还有其他人,但这个对我来说效果很好。

An alternate solution rather than closing all apps that might be locking the directory as just about every other answer says to do, would be to use a utility that will unlock the files/directory without closing everything. (I hate needing to restart Visual Studio)

LockHunter is the one that I use: https://lockhunter.com/ There are likely others out there as well, but this one has worked great for me.

眉目亦如画i 2024-11-14 07:34:30

我遇到这个问题是由我的编辑器 Intellij 引起的。作为其内部版本控制的一部分,它已经检查并锁定了所有隐藏的 git 文件。 (由于各种原因,我没有使用Intellij附带的git插件...)

所以我以管理员身份打开了一个普通的dos窗口,更改为目录,并执行了

attrib -R /S

这删除了文件上的锁定,之后一切正常了我可以使用 GitHub Windows 客户端同步我的更改。

My encounter with this problem was caused by my editor, Intellij. As part of its internal version controls, it had gone through and locked all hidden git files. (For various reasons, I was not using the git plugin that comes with Intellij...)

So I opened a normal dos window as Administrator, changed to the directory, and executed

attrib -R /S

That removed the lock on the files and everything worked after that and I could sync my changes using the GitHub windows client.

や三分注定 2024-11-14 07:34:30

我同意上面的“关闭 Visual Studio”答案。

然而,即使在关闭 Visual Studio 后,我还必须执行一个额外步骤,即在任务资源管理器中手动终止“devenv.exe” Visual Studio 进程。
完成此操作后,我能够再次在 gitbash 中运行:

git 拉取

和“cannot stat filename”错误消失了。这可能是由于 Visual Studio 扩展使进程即使在关闭后仍保持打开状态更长的时间。

I agree with the above "Close Visual Studio" answers.

However, an additional step I had to do even after I'd closed Visual Studio was to manually kill the "devenv.exe" Visual Studio process in Task Explorer.
After I had done this I was able to again run in gitbash:

git pull

and the "cannot stat filename" error disappeared. It is perhaps due to a Visual Studio extension keeping the process open for longer even after closing.

杯别 2024-11-14 07:34:30

我刚刚遇到这个问题。问题是 - 如果你打开了文件,该文件在变基后被删除\替换(你有一个分支不再有这个文件),git 系统就会损坏。所以我关闭了所有打开的文件,然后尝试在其他分支上结账

I've just had this problem. The thing is - if you had opened file, that was removed\replaced after rebase (you had a branch which doesn't have a this file anymore), the git-system corrupts. So i closed all opened files and then tryied to checkout on some other branch

断爱 2024-11-14 07:34:30

Windows 10 64 位上运行 Git Bash 版本 2.9.0.windows1 时出现同样的问题
使用 Atom 作为我的编辑器。

这对我有用:我将 Git 软件文件夹(对我来说是 C:\Program Files\Git)添加到 Windows Defender 的排除项中。

添加排除后,git checkout 'file' 工作正常。

Same issue on Windows 10 64 Bit, running Git Bash version 2.9.0.windows1
Using Atom as my editor.

This worked for me: I added the Git software folder (for me, this was C:\Program Files\Git) to the exclusions for Windows Defender.

After the exclusion was added, git checkout 'file' worked fine.

厌味 2024-11-14 07:34:30

此错误也可能是由于之前的 git 操作导致文件仍然“锁定”的事实造成的。它与 Windows 文件系统层的工作方式有关。我曾经读过一篇关于此的很好的解释,但我不记得在哪里了。

然而,在这种情况下,由于它基本上是一个竞争条件,因此您所要做的就是继续中断的变基过程。不幸的是,这种情况经常发生在我身上,所以我写了这个危险小助手来让我的变基继续进行:

#!/bin/sh

set -e

git checkout .
git clean -df
git rebase --continue

如果你想更加确定,你可以使用git rebase --edit-todo 检查下一个要应用的提交是否确实是之前应用失败的提交。使用 git clean -dn 来确保您没有删除任何重要文件。

This error can also be caused by the fact that files are still "locked" because of prior git actions. It has to do with how the Windows filesystem layer works. I once read a nice explanation on this, but I can't remember where.

In that case however, since it is basically a race condition, all you have to do is continue your interrupted rebase process. Unfortunately this happens to me all the time, so I wrote this little dangerous helper to keep my rebases going:

#!/bin/sh

set -e

git checkout .
git clean -df
git rebase --continue

If you want to be extra sure, you can use git rebase --edit-todo to check if the next commit to be applied is really the one that failed to be applied before. Use git clean -dn to make sure you do not delete any important files.

囚我心虐我身 2024-11-14 07:34:30

我在 Windows 中使用 Photoshop 时发生过:
当我保存图像然后切换到分支(使 Photoshop 保持图像打开状态)时,我收到了 git 错误。关闭 Photoshop 中的图像并重试

Happened to me when in windows, when using photoshop:
When I saved an image and then switched to a branch (leaving photoshop with the image opened) i got the git error. Close the image in photoshop and retry

笙痞 2024-11-14 07:34:30

如果您打开了 Meld 合并工具,请将其关闭。它阻止文件覆盖。

If you have the Meld merge tool open, close that. It blocks the file overwriting.

没企图 2024-11-14 07:34:30

杀死与存储库相关的 w3wp.exe 进程为我解决了这个问题。

Killing the w3wp.exe process related to the repository fixed this for me.

来日方长 2024-11-14 07:34:30

就我而言,我有一个 webpack 开发服务器在后面运行。

In my case, I had a webpack dev server running behind.

顾北清歌寒 2024-11-14 07:34:30

当我的 VS1013 位于目标为 8.1 的分支上并且我试图签出 8.0 分支时,我收到此错误。我需要返回 VS 并允许它 UpdateAll。然后我就可以检查 8.0 分支而不会出现错误。

I got this error when my VS1013 was on a branch targeting 8.1 and I was trying to checkout a 8.0 branch. I needed to tab back to VS and allow it to UpdateAll. Then I could checkout the 8.0 branch without error.

老子叫无熙 2024-11-14 07:34:30

当我遇到同样的错误时,我也在使用 Git Shell 的 Windows 机器上。

然而,当时我打开了多个 Git 终端。

第一个终端收到您在上面发布的错误,另一个终端之前已运行来自 yeoman 的 gruntserve 终端命令(链接如下)。第二个终端需要保持打开状态以托管本地服务器实例。

关闭所有正在运行的进程的终端窗口可能会导致错误消失。

至少这对我有用。关闭第二个终端窗口后,我可以轻松查看不同的分支并操作文件。

Grunt 服务命令 - Yeoman.I/O
http://yeoman.io/learning/

I was also on a Windows machine using Git Shell when I encountered the same error.

However, at the time I had multiple Git terminals open.

The first terminal received the error you posted about above and the other terminal had previously ran the grunt serve terminal command from yeoman (linked below). The second terminal needed to remain open to host a local server instance.

Shutting down all terminal windows running ongoing processes can cause the error to go away.

At least that's what worked for me. After I shut down the second terminal window, I could easily checkout different branches and manipulate files.

Grunt Serve Command - Yeoman.I/O
http://yeoman.io/learning/

残月升风 2024-11-14 07:34:30

我刚刚遇到这个问题。这里的答案都没有为我解决这个问题。

最终成为我在分支上添加的 nuget 包,一旦切换回 master 分支,它似乎不存在。一旦我进行了合并,它会说 newtonsoft...xml 无法统计。我会转到有问题的文件并打开它,但 Windows 抛出一个错误,说它找不到该文件(即使我正在看它)

我解决这个问题的方法是右键单击删除该文件(这有效,但我无法打开它,因为 Windows 找不到它???)并尝试再次合并,它解决了问题。

很奇怪。

希望这对以后的人有帮助。

I just ran into this issue. Non of the answers here happened to solve this for me.

Ended up being nuget packages I added on a branch that, once switched back to master branch, seemed to not exist. Once I did a merge it would say newtonsoft...xml could not stat. I would go to the file in question and open it but Windows threw an error back saying it can't find the file (even though I was looking right at it)

How I solved this was right click delete the file (which worked but I couldnt open it because windows couldnt find it???) and try to merge again and it solved the problem.

Very strange.

Hope this helps someone later.

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