git的问题(error: object file .git/objects/* is empty...)的解决方案及对git版本库文件的了解

  由于操作不当,导致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版本库的文件结构稍微了解了一些:

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

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

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

[ccx@ubuntu ~/miniSearchEngin/.git]$>cat COMMIT_EDITMSG 
词典联想功能OK,目测可以多线程服务

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

 31 e5085f07d6f8578bad1ae39d85bf88db6886c51d bd9a33f13603ef3b53184e3b9ce9408638b71fb4 ccx19930930 <461661280@qq.com>
1480909458 +0800 commit: 词典联想功能OK,目测可以多线程服务

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

  

  HEAD,里面是一个文件路径:

[ccx@ubuntu ~/miniSearchEngin/.git]$>cat HEAD
ref: refs/heads/master
[ccx@ubuntu ~/miniSearchEngin/.git]$>cat refs/heads/master
bd9a33f13603ef3b53184e3b9ce9408638b71fb4

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

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

  删除的情况:

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

  改了的情况:

[ccx@ubuntu ~/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 <461661280@qq.com>               1480061835 +0800 commit (initial): build git                                                                               
  2 541115f2d1f08d2fe58a768e5a9d3a809bab1131 31db0463027e42718de8e2bbd826586a89316723 ccx19930930 <461661280@qq.com>               1480082783 +0800 commit: 中文、英文单词词频统计,不包含全、半角标点符号
  3 31db0463027e42718de8e2bbd826586a89316723 1a5c8107af4852b0d8d36a76d988cb2a0b06cc10 ccx19930930 <461661280@qq.com>               1480128209 +0800 commit: 去停用词
  4 1a5c8107af4852b0d8d36a76d988cb2a0b06cc10 959fa05c58dbcb6837d7b7a9062bf2f542a15a6b ccx19930930 <461661280@qq.com>               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版本库一周有余,备份的错误库早已删除(永久删除,前几天刚清了一次回收站--!),有些地方可能描述得不太清楚,忘见谅。

原文地址:https://www.cnblogs.com/chinxi/p/6139469.html