git-从坏树对象中恢复? [英] git - recover from bad tree object?

问题描述

我在本地和远程迁移了一个存储库，现在由于一个坏的树对象，我无法推送(或做很多事情)，

I migrated a repository both locally and the remote, and now I am unable to push (or do much of anything) because of a bad tree object,

> git push
error: Could not read 4218a5a380d8b6cbc7f461c22cb48ed66a92c850
fatal: bad tree object 4218a5a380d8b6cbc7f461c22cb48ed66a92c850
fatal: The remote end hung up unexpectedly

4218a5a380d8b6cbc7f461c22cb48ed66a92c850在我的文件系统上不存在

4218a5a380d8b6cbc7f461c22cb48ed66a92c850 doesn't exist on my filesystem,

> dir 4218a5a380d8b6cbc7f461c22cb48ed66a92c850 /s /p
 Volume in drive C is OS
 Volume Serial Number is xxxxxxxx
File Not Found

我有我所有的源代码文件.我现在是唯一的选择git repo并重新开始历史记录吗?

I have all my source code files. Is my only option now to nuke the git repo and start the history over again?

推荐答案

"nuke and pave"选项不一定是您的 only 选项，但可能是您的最佳 >一. 坏树对象"是一个异常错误，它表明您的存储库的某些部分可能已损坏(由于磁盘故障，恶意程序/恶意软件/覆盖文件的任何原因，试图将Git存储库存储在保管箱文件夹中，或知道什么).如果要对其进行核对，则可能需要先对其进行备份，以防万一.

The "nuke and pave" option is not necessarily your only option, but it may be your best one. A "bad tree object" is an unusual error and suggests that parts of your repository may be corrupted (by disk failure, or rogue process / malware / whatever overwriting your files, or attempting to store a Git repository in a dropbox folder, or who knows what). If you are going to nuke it, you might want to back it up first just in case, though.

如果您正在执行git push，并且没有任何选项，则表明您有一个单独的存储库副本(可能有些过时)，其中包含了大多数代码，可能在另一台机器上.在其他地方单独复制该副本可能仍然很好.您可以进行检查，也许是通过将其克隆到新位置，然后使用从损坏的存储库中可以挽救的所有提交进行的新提交来更新新克隆，并将其推送，以便将新提交添加到服务器上的其他提交中.其他机器.这样一来，您就可以真正适应nuke-and-pave了，因为您有两个很好的副本:一个在您的新克隆中(在这种情况下是第三个Git)，另一个在另一台机器上(这里是第二个Git，第一个是您的Git)存储库已损坏).

If you're doing a git push with no options, that suggests that you have a separate copy of the repository (slightly out of date, perhaps) with most of the code in it, probably on a different machine. That separate copy elsewhere may still be good. You could check that, perhaps by cloning it to a fresh location, and then update the fresh clone with new commits made from whatever you can salvage from the damaged repository, and push those so that the new commits are added to that other repository on the other machine. Then you can really be comfortable with nuke-and-pave since you have two good copies: one in your fresh clone (the third Git in this scenario), and one on the other machine (the second Git here—the first Git is your corrupted repository).

值得一提的是，首先调查存储库损坏的原因，因为这可能仍在继续.

It's also worth doing some background investigation into what corrupted the repository in the first place, since that might still be going on.

顺便说一句，即使树对象4218a5a380d8b6cbc7f461c22cb48ed66a92c850作为松散对象存在，它也不会存在于名为4218a5a380d8b6cbc7f461c22cb48ed66a92c850的文件中.它将位于名为42的目录中，该目录存储为名为18a5a380d8b6cbc7f461c22cb48ed66a92c850的文件.

As an aside, even if the tree object 4218a5a380d8b6cbc7f461c22cb48ed66a92c850 exists as a loose object, it won't be in a file named 4218a5a380d8b6cbc7f461c22cb48ed66a92c850. It will be in a directory named 42 stored as a file named 18a5a380d8b6cbc7f461c22cb48ed66a92c850.

如果对象已被打包，则根本不会作为一个单独的文件出现，而是作为某个打包文件(其名称不可预知)中的打包对象出现.

If the object has been packed, it won't be around as a separate file at all, but rather as a packed object in some pack file (whose name is not predictable).

这篇关于git-从坏树对象中恢复?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！