gitolite conf文件误删gitolite-admin后的恢复经验

提要

前几日在工作中，不慎将gitolite conf文件中的gitolite-admin repo误删掉了，经过一系列研究，最终恢复了conf文件，在恢复的过程中，google没有发现同样的问题，写下这篇文章，算是个记录，如果有人遇到类似的问题，或许可以帮上些忙。

问题是如何出现的

某天来到单位，得知需要调整下某个repo的权限，打开conf文件，配置好，执行git push，等待着出现配置成功的信息，几秒钟后，一片文字飘过，意思是大概是repo权限解析出现问题云云，检查conf文件，发现conf文件的前面几十行不知道去哪里了，这前几十行中包括gitolite-admin repo的配置、用户组的配置，以及许多项目repo的配置，问了下开发人员，果然所有的repo都无法pull和push了…

然后开始了坎坷的恢复工作。

恢复过程

0.首先考虑gitolite-admin也是个repo，如果修改gitolite server上HEAD的commit id到提交之前的一次，是不是就可以恢复了？按照这个思路，修改了gitolite-admin的ref/head/master 中的commit id，测试结果；无效，恩，如果这样就成功了，未免太简单。

1.进一步考虑gitolite-admin是一个比较特殊的repo，很可能提交的时候gitolite server修改了其他的配置文件，于是检索了下/home/git最近被修改的文件，发现被修改的还不少，其中~/.gitolite/conf下的几个文件看上去比较可疑，这个目录下有三个文件，分别是gitolite.conf, gitolite.conf-compiled.pm, rule_info,第一个文件中是，第二个文件，第三个文件的内容比较费解，没有深入研究，修改了前两个文件，测试，依然无效，恩，就算是思路是对的，rule_info这个文件也没有修改，无效是正常的。

2.这个时候开始google，再看了大概前三页的结果后，发现没有任何一个描述的问题和我遇到的一个，这个错误看来是太低级了…

3.既然google都搞不定，开始预感到要备份所有的repo然后重装gitolite了，在备份repo之前，我决定再看看官方的文档，试试运气
于是乎打开官方文档中紧急情况处理的说明：http://gitolite.com/gitolite/emergencies.html，发现了居然有这个问题的一个解决方案:”bypassing gitolite”,马上使用root登录server，按照文档提供的方式：

1 2	git clone home/git/repositories/gitolite-admin.git temp cd temp

回滚到了上一个commit，然后执行了文档上说的那个可以让万物恢复秩序的命令：

/home/git/bin/gitolite push
! [rejected] master -> master (non-fast-forward)
error: failed to push some refs to '/home/git/repositories/gitolite-admin.git'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes before pushing again. See the 'Note about
fast-forwards' section of 'git push --help' for details

额。失败了。。

文档上说了，可以加上 -f试试

/home/git/bin/gitolite push -f
Total 0 (delta 0), reused 0 (delta 0)
remote: FATAL: errors found but logfile could not be created
remote: FATAL: /root/.gitolite/logs/gitolite-2015-12.log: No such file or directory
remote: FATAL: update /home/git/repositories/gitolite-admin.git (root) bypass refs/heads/master ff87eca35fe679f8de3b91d2f9153619f6ab7058 279782d66eb0266371643d94ec3f2af5cebb374f
remote: error: hook declined to update refs/heads/master
To /home/git/repositories/gitolite-admin.git
! [remote rejected] master -> master (hook declined)
error: failed to push some refs to '/home/git/repositories/gitolite-admin.git'

额，又失败了。。。

4.考虑到当初用的git用户安装的gitolite，可能要使用git用户执行这个操作，而不是root，于是乎su git之后使用 ~/bin/gitolite push，这次是文件权限不足，直接find . -exec chmod 777 {} \; 依然报错…
PS，后来恢复正常以后我又试了一次，这个办法又可行了。

5.这一次从头开始，使用git用户执行 git clone /home/git/repositories/gitolite-admin.git temp，进入temp目录，这一次更无语，temp目录下没有任何文件，是的，没有任何文件…难道git用户没有这些文件的权限，导致clone了一个空的repo，检查gitolite-admin，发现这些文件的拥有者确实是git,这个地方始终没有搞明白为什么clone的是一个空的repo，刚看到些希望，貌似又破灭了，干脆把本地gitolite-admin repo上传到服务器试试。上传解压后，执行

~/bin/gitolite push
No refs in common and none specified; doing nothing.
Perhaps you should specify a branch such as 'master'.
fatal: The remote end hung up unexpectedly
error: failed to push some refs to '/home/git/repositories/gitolite-admin.git'
~/bin/gitolite push origin master
Counting objects: 18, done.
Compressing objects: 100% (18/18), done.
Writing objects: 100% (18/18), 5.61 KiB, done.
Total 18 (delta 1), reused 0 (delta 0)
Unpacking objects: 100% (18/18), done.
error: unable to resolve reference refs/heads/master: Permission denied
remote: error: failed to lock refs/heads/master
To /home/git/repositories/gitolite-admin.git
! [remote rejected] master -> master (failed to lock)
error: failed to push some refs to '/home/git/repositories/gitolite-admin.git

果然还是报错。等下，这次的报错和前几次不太一样。refs/heads/master: Permission denied，没有权限。没有权限好说，加上就是了（有点死马当活马医的感觉了）

1	chmod 777 /home/git/repositories/gitolite-admin.git/refs/heads/master

顺便说一下，原来的权限是600，再次执行

~/bin/gitolite push origin master:master -f
Counting objects: 18, done.
Compressing objects: 100% (18/18), done.
Writing objects: 100% (18/18), 5.61 KiB, done.
Total 18 (delta 1), reused 0 (delta 0)
Unpacking objects: 100% (18/18), done.
To /home/git/repositories/gitolite-admin.git
+ 35cafe6...d9dd5b0 master -> master (forced update)

没有思想准备就成功了。

总结下经验吧

配置权限文件的时候不要太随意，一定要多检查几次
遇到问题多看看官方文档