萌新笔记——git的问题（error: object file .git/objects/* is empty...）的解决方案及对git版本库文件的了解

Posted 2020-08-22 曾经时光

　　由于操作不当，导致git版本库出了大问题，如下所示：

error: object file .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e is empty
fatal: loose object 8b61d0135d3195966b443f6c73fb68466264c68e (stored in .git/objects/8b/61d0135d3195966b443f6c73fb68466264c68e) is corrupt

 

　　即提示xx文件是空的。在使用git log、git commit、git status等命令都会出此错误（文件名可能不一样）。如果把.git删掉，重新init，那会很轻松地暴力地解决了这个问题。但是，这样的话之前的版本信息就全部丢失了，这并不是想要的结果。于是，我打算修复它。

 

　　首先，贴上找到的正确解决方法的链接：http://stackoverflow.com/questions/11706215/how-to-fix-git-error-object-file-is-empty

　　如果看不懂，最后有简单的版本

 

　　然后是说说我自己瞎捣鼓的过程：

 

　　当时我想，既然它提示那个文件是有问题的，那我把它删了会怎么样呢？结果是提示另一个文件是空白的。也就是说，还得删。我空发奇想，如果我修改了它的日志会怎么样？于是，我查看的它的日志文件：

cd .git
cd logs
vim HEAD

 

　　我发现日志文件前面都是我之前提交的版本信息，唯独最后一行是乱码。于是，我把乱码行删了。同时，cd 进另当前目录下的一个子目录中

cd refs
cd heads
vim master

 

　　把这里最后一行的乱码也删了。

 

　　然后，我发现.git另一个子目录refs里，存着好像是当前版本信息的东西，参考之前的HEAD文件，把它改成了一个正常的版本号。此时，我使用git log，居然可以正常地显示出日志了！然后我尝试add了一下，发现OK，没有提示任何东西。据说，没有提示就是好事。可是，万万没想到的是，在commit的时候，又开始提示xx文件是空的了。

 

　　看来，我是哪里搞错了什么。

　　虽然自己瞎捣鼓没有成功，但是似乎对git版本库的文件结构稍微了解了一些：

[[email protected] ~/miniSearchEngin]$>cd .git/
[[email protected] ~/miniSearchEngin/.git]$>l
branches/  COMMIT_EDITMSG  config  description  HEAD  hooks/  index  info/  logs/  objects/  refs/

 

　　一个一个来看，首先，branches是一个空文件（我的是），“树枝”的意思，大概是与分支有关的文件，我暂时没用到分支，并不是很清楚。

　　COMMIT_EDITMSG，看文件名大概猜到是commit时的编辑信息，结果和猜测的一样：

[[email protected] ~/miniSearchEngin/.git]$>cat COMMIT_EDITMSG 
词典联想功能OK，目测可以多线程服务

　　与日志文件最后一行呼应：

 31 e5085f07d6f8578bad1ae39d85bf88db6886c51d bd9a33f13603ef3b53184e3b9ce9408638b71fb4 ccx19930930 <[e-mail]>
    1480909458 +0800 commit: 词典联想功能OK，目测可以多线程服务

 

　　然后是description文件，好吧我不知道它是干嘛用的（下面省略掉不知道的吧，哪天搞明白了再补）

　　

　　HEAD，里面是一个文件路径：

[[email protected] ~/miniSearchEngin/.git]$>cat HEAD
ref: refs/heads/master

[[email protected] ~/miniSearchEngin/.git]$>cat refs/heads/master
bd9a33f13603ef3b53184e3b9ce9408638b71fb4

　　文件内容与日志文件最后一项的后一个大数字相同。于是我猜测它可能是当前版本信息。

 

　　如果把HEAD删了，或者里面的路径改了，会怎么样呢：

　　删除的情况：

[[email protected] ~/miniSearchEngin/.git]$>mv HEAD HEAD.h
[[email protected] ~/miniSearchEngin/.git]$>cd ..
[[email protected] ~/miniSearchEngin]$>git log
fatal: Not a git repository (or any of the parent directories): .git

　　改了的情况：

[[email protected] ~/miniSearchEngin]$>git log 
fatal: Not a git repository (or any of the parent directories): .git

　　就提示没有git版本库了。

 

　　如果手动把refs/heads/master改成之前的一个版本号，在git log的时候会显示为之前的日志信息。就像是日志回档了，但是文件还是原样。反正我做了这个操作之后使用git status，会提示一堆红色未提交的文件。进行add 和commit也是可以。此时查看日志文件，会发现最后一行新增了新信息。不妨把此操作命名为操作A。

　　这里要说一下日志文件，截取部分如下：

  1 0000000000000000000000000000000000000000 541115f2d1f08d2fe58a768e5a9d3a809bab1131 ccx19930930 <[e-mail]>               1480061835 +0800 commit (initial): build git                                                                               
  2 541115f2d1f08d2fe58a768e5a9d3a809bab1131 31db0463027e42718de8e2bbd826586a89316723 ccx19930930 <[e-mail]>               1480082783 +0800 commit: 中文、英文单词词频统计，不包含全、半角标点符号
  3 31db0463027e42718de8e2bbd826586a89316723 1a5c8107af4852b0d8d36a76d988cb2a0b06cc10 ccx19930930 <[e-mail]>               1480128209 +0800 commit: 去停用词
  4 1a5c8107af4852b0d8d36a76d988cb2a0b06cc10 959fa05c58dbcb6837d7b7a9062bf2f542a15a6b ccx19930930 <[e-mail]>               1480176053 +0800 commit: 分组OK

　　前两个数字就好像是表示从哪个数字开始，到哪个数字，然后下一行的起始就是上一行的结束。由于refs/heads/master中存着当前版本号，于是我很happy地把它看成一个链表，以当前版本为头结点的链表：

+=======+   +=======+         +========+   +=========+
|当前版本|-->|上一版本|-->...-->|第二个版本|-->|第一个版本|
+=======+   +=======+         +========+   +=========+

　　做了操作A之后：

+=======+             +=============+         +===============+         +========+
|当前版本|--+          |操作A之前的版本|-->...+->|操作A中设定的版本|-->...-->|第一个版本|
+=======+  |          +=============+      |  +===============+         +========+
           |                               |
           +-------------------------------+

　　就成这样了。

 

　　objects文件夹里存的应该是不同版本的文件，可能是经过了加密算法还是什么算法，打开看基本是乱七八糟的不知道写的什么。

　　logs文件夹之前提到了，存的是日志文件。

　　refs文件夹存的是当前版本信息，“链表的头结点”。

 

　　好了，装逼（卖弄）了这么久，回归正题。

　　我最后是用一开始的链接里的方法解决了解个问题：

 

　　在最最开始，要先备份一下.git文件夹，万一搞坏了呢

 

　　首先，删除所有的空白文件：

cd .git
find . -type f -empty -delete -print

 

　　然后，打印出日志文件最后两行：

tail -n 2 .git/logs/refs/heads/master

 

　　接着，查看xx版本是否正常，即上一步打印出来的第一条

git show xxxx(版本号)

 

　　之后，回档：

git update-ref HEAD xxxx(版本号)

 

　　检查一下：

git fsck

 

　　我到这一步就已经OK能用了，链接后面还有一些处理我并没有继续做下去（我比较懒，目的就只是修复一下版本库，既然能用了我就不继续搞了，万一又坏了呢）

 

　　链接中剩余的操作：

rm .git/index
git reset
git fsck

　　然而，在写此文的时候我发现，那位大神这样做了之后并没有什么用，他也说了他并不想继续搞了（英语渣，大概应该可能也许是这个意思），将就用吧--!

 

　　最后看了一下修复后的日志信息，发现就是相当于做了“链表删除节点”的操作，那个错误的日志信息还是乱码。我也不想去删了，就怕又删出迷之问题。

 

后记：

　　写此文时，已距离我修复好git版本库一周有余，备份的错误库早已删除（永久删除，前几天刚清了一次回收站--!），有些地方可能描述得不太清楚，忘见谅。