未分類
18 4 月 2021

git 仓库同步到坚果云上后损坏了

git 仓库同步到坚果云上后损坏了

資深大佬 : EscYezi 4

前两天在家里的 windows 笔记本上git init --bare新建了一个仓库，然后把这个文件夹同步到了坚果云上，并且向这个仓库里 push 了一些代码。 昨天在公司的 mac 上用坚果云把这个文件夹同步下来然后git clone到本地，并向仓库 push 了一些代码，看坚果云同步结束合上电脑下班了。到这里为止都没发现什么异常。 今天在家用坚果云把仓库同步下来，本地 pull 发现报错了，具体错误信息没有记录下来，换了一个目录 clone 报错

D:projects>git clone file:///D:/nutstore-sync/git/algorithm al2 -b main Cloning into 'al2'... remote: errorerror: git upload-pack: git-pack-objects died with error. fatal: git upload-pack: aborting due to possible repository corruption on the remote side. : Could not read 757adde25527ab466f2d48f3ae71ca1464b6df1ffatal: early EOF  remote: fatal: Failed to traverse parents of commit d26c516d98ef670e228eae36363bd015056b1283 remote: aborting due to possible repository corruption on the remote side. fatal: fetch-pack: invalid index-pack output

进到仓库里fsck了一下

D:nutstore-syncgitalgorithm>git fsck --name-object Checking object directories: 100% (256/256), done. broken link from  commit d26c516d98ef670e228eae36363bd015056b1283 (refs/heads/main)               to  commit 757adde25527ab466f2d48f3ae71ca1464b6df1f (refs/heads/main^) broken link from    tree 07e1bf67bee247eb4db40fa135f705dd05fa8972 (refs/heads/main:src/xxx/xxxxx/algorithm/)               to    tree 8e30aad2ed2800aeed6c801b4b94d8847deb323a (refs/heads/main:src/xxx/xxxxx/algorithm/foroffer/) missing tree 8e30aad2ed2800aeed6c801b4b94d8847deb323a (refs/heads/main:src/xxx/xxxxx/algorithm/foroffer/) dangling tree 0f705bbff03e60514e46a060c4d61684582a55db dangling blob 39408c376bd54f576a653b79fd899f37452fe4af dangling tree cf04f6b34931f215f460332cbd0029669b9c60da dangling tree e3170836338f688d7bd1d12f85cde4ec7705cf6d dangling commit f1180ef1b7f4e924ecfbfd71bf05f0cea5c53367 missing commit 757adde25527ab466f2d48f3ae71ca1464b6df1f (refs/heads/main^)

搜了半天，找到的恢复方法都是先要有一个完整的仓库，在此基础上对损坏的仓库进行修复。但是现在的情况相当于远程仓库损坏了，有最新提交的本地仓库又在公司的电脑上，想着也没多少修改，干脆把代码提到了 GitHub 上，以后直接从 GitHub 拉代码总不会出问题了吧。

有趣的是在搜索解决方案的时候发现了一段话:

This isn’t much help but: do not store Git repos in Dropbox or any other sync services. Git isn’t built to handle another program randomly locking and rewriting files while it’s doing something else.

之前也有过把 git 仓库放在 OneDrive 上，不过只是 push，没有从上面 clone 过，也没有同步到多端 push 和 clone 过，现在看似乎要重新考虑一下这种方案的可行性了。不知道大家有没有出现过类似的问题？

大佬有話說 (15)

  • 資深大佬 : codehz

    建议用 git bundle 功能打包成单文件然后上传云存储

  • 資深大佬 : nightwitch

    即使同步算法做的最好(个人认为)的 dropbox 也特意指出，在同步盘里放 git 仓库可能导致文件损坏。dropbox 的解决方案是用一个中间件 git-remote-dropbox 来链接 git 和 dropbox 。
    git 仓库同步到坚果云上后损坏了

  • 主 資深大佬 : EscYezi

    @codehz #1 学到了

  • 資深大佬 : dingwen07

    https://blog.jianguoyun.com/?p=2839

  • 資深大佬 : omph

    具体是哪里不兼容的？

  • 資深大佬 : nieyujiang

    所以为什么不直接一开始就用 github 之类的东西呢.

  • 主 資深大佬 : EscYezi

    @nieyujiang #6 公司网络访问 GitHub 不太稳定，gitee 用来做 GitHub 的国内镜像，其他平台暂不考虑。如果 GitHub 可以正常访问一开始就不会考虑这个方案了

  • 資深大佬 : gxy2825

    试试 Coding

  • 資深大佬 : secretman

    云存储一般不能存 git 项目啊，奇奇怪怪的问题老多了

  • 資深大佬 : secretman

    当你有多个分支不断来回切换时，大量文件不一致时，你会发现云同步大概率就卡死了

  • 資深大佬 : guochao

    git 会快速操作大量文件，并且涉及到 filemode 一类的文件属性的操作，同步盘本质是把文件内容修改排队上传，定期 squash，有意外情况的时候（比如说在很短时间内增减同一个路径上的文件）很容易破坏 git 树，而且无法保留 filemode 也会丢失非常多信息。类似的是 vim，也会快速的增删文件

    直接提交到 git{hub,lab,ee}吧，gitlab 在国内也建了团队，gitee 和 gitlab 在国内的可用性应该都会相对越来越好

  • 資深大佬 : fengjianxinghun

    @guochao github 不可能好，gitlab 国区特供才可能好。

  • 資深大佬 : FrankHB

    公司穷到连自建 GitLab 实例都负担不起的话直接 Gitee 吧。

  • 主 資深大佬 : EscYezi

    @FrankHB 倒不是公司没有自建仓库，自己的一些东西没法传到公司仓库里

  • 資深大佬 : tomkliyes

    @EscYezi 自己在 gitee 上建个私有仓库吧……人生苦短，不要花太多时间在这种事情上面……当然如果你本身就是做云存储相关的工作就当我没说