如何处理git gc致命：错误的对象ref / remotes / origin / HEAD错误？

131

我今天在尝试运行Git 垃圾收集时随机打了这个：

$ git gc
fatal: bad object refs/remotes/origin/HEAD
error: failed to run repack

我该如何处理？

— 瑞安
source

161

我不明白这个问题的后果，但是正如该主题所建议，当我遇到这个问题时，我只是做了

$ mv .git/refs/remotes/origin/HEAD /tmp

（以防万一），然后

$ git gc

工作没有抱怨；我还没有遇到任何问题。

— Petrelharp
source

6

它对我有用，我认为我遇到了这个问题，因为我将默认分支从更改master为另一个分支develop。前几天我改回来自develop于master和我删除了旧的默认分支develop，但在我的工作目录下，文件.git/refs/remotes/origin/HEAD仍然指向refs/remotes/origin/develop不再存在。在这种情况下，删除文件确实可行。

— Stavarengo

4

git prune为我工作，这是一种删除已在Git中积累但未被任何有用信息引用的数据的方法。

— 斯文·马尔维克

执行它们解决了我的问题：$ mv .git/refs/remotes/origin/HEAD /tmp $ git gc git prune

— David Rauca '18

2

我怀疑最好的方法是@WilQu的答案（stackoverflow.com/a/49944297/660339）。有人可以确认吗？

— 伊万·佩雷斯

从.git文件夹中删除这些文件，git gc对我来说

— 不起作用

68

我遇到的问题（与上面的评论中提到的@Stavarengo相同）是默认远程分支（develop在我的情况下）已被删除，但仍在中引用.git/refs/remotes/origin/HEAD。

.git/refs/remotes/origin/HEAD在我的编辑器中打开显示以下内容：

ref: refs/remotes/origin/develop

我仔细编辑了它，以指向新的默认分支，一切都很好：

ref: refs/remotes/origin/master

提示我的线索是跑步git prune显示了此错误：

> git prune
warning: symbolic ref is dangling: refs/remotes/origin/HEAD

— 特伦顿
source

1

那也是我的解决方法

— Dan Carlstedt

1

这是我的确切解决方案。我们的团队最近从使用默认分支开发也改为掌握

— jmancherje

40

看到特伦顿的回答后，我看了.git/refs/remotes/origin/HEAD看，还发现它也指向一个已删除的旧分支。

但是，我没有亲自编辑文件，而是尝试了Ryan的解决方案：

git remote set-head origin --auto

它会自动将文件设置为新分支，然后git gc运行良好。

— 威尔曲
source

是的，这对我有用-与我在完全相同的情况下一样。git remote set-head $REMOTE --auto在我的情况下，$ REMOTE是远程别名，而不是默认的“源”，因为我有多个远程设置。

— Devy

29

我认为解决方案如下，因为这似乎可行，但事实证明并没有真正解决问题。

git remote set-head origin --auto

— 瑞安
source

1

看来此命令帮助我摆脱了同样的麻烦。但是，在执行此命令后，我也使用了git prune（如第一个命令输出中所建议的那样），因此我无法确切地说出是什么对我有所帮助-第一，第二或两者。

— Borys Pylhun '17

1

git remote set-head origin --auto修复了我的refs / remotes / origin / HEAD文件，而无需使用git prune

— danio

我遇到了此错误：error: Multiple remote HEAD branches. Please choose one explicitly，并且不得不使用git remote set-head origin mybranch（当'mybranch'分支被检出时）才能使错误消失。

— derekmx271

3

拒绝投票，因为这不是一个完整的答案，可能会产生误导。

— Christian Vielma

9

看起来您的symbol-refs可能已损坏...尝试用默认分支替换它，例如：例如，我的默认分支是master

$ git symbolic-ref refs/remotes/origin/HEAD refs/remotes/origin/master
$ git fetch --prune
$ git gc

那应该解决它。

— 锥形三硝基甲苯Da Costa
source

0

如果您使用的是git工作树，请确保您正在执行

git worktree prune

跑步前

git gc

我的工作树已损坏，这在删除损坏的工作树后似乎可以解决问题。git prune本身似乎不起作用。

— 杰夫
source

0

对我来说，这是在Windows中的压缩文件夹中工作的原因。文件夹解压缩后，它破坏了打包文件，并引发了其他奇怪的问题，例如无法修剪不存在的分支。

唯一的解决方法是清除工作目录，然后再次克隆远程仓库。幸运的是，我仍然可以推送和拉取更新以确保没有丢失任何内容。现在一切都好。

— 威尔·斯特罗尔
source