推送时Git无法解析引用 [英] Git unable to resolve references when pushing

问题描述

我遇到Git问题。由于不明原因，我的主分支不知何故被损坏。我有一个本地的提交，我想推高，但是当我推，我得到这个：

pre $ g $ git push origin master
错误：无法解析参考文献/遥控器/原点/主控制器：没有这样的文件或目录
错误：无法锁定参考文献/遥控器/原点/主控制器。
一切都是最新的

我在其他板子上看到过这个问题，但通常指的是拉动而不是推动。尽管如此，我已经尝试了他们的解决方案，但无济于事：

1. 尝试修改我当前的提交并推送
   
2. 使用 git gc --prune = now
清理了我的git存储库

3. 尝试了 rm .git / refs / removing / origin / master

没有解决过我的问题。任何想法或想法？

解决方案

（来自@NeTeInStEiN的值得tl;博士：

核选项是 rm -rf .git / refs / remotes / origin ，这就是它在这里所做的）

编辑：我已经在我自己的回购站中运行了这种行为的一部分，我可以让git在没有 rm的情况下重现发生故障。 git / refs / remotes / origin / master hack：

• 克隆回购


• 删除原始的主分支（它的 HEAD 附加到的分支）


• 运行克隆中的git fetch --prune
  
  $ b

  获取将产生dangling-ref警告，并且 git for-each-ref 会失败并显示一条熟悉的消息：
  
  

   〜 / sandbox / 20 / buddy $ git fetch --prune 
  从/ home / jthill / sandbox / 20 / source /。 
   x [已删除]（无） - >起源/主
  （refs / remotes / origin / HEAD已成为悬挂）
  〜/ sandbox / 20 / buddy $ git fer 
  致命：缺少对象000000000000000000000000000000000000对于裁判/远程/原点/ HEAD 
    

  但是这并没有打破推送，我尝试过使用 push.default ，也不会中断 git update-ref -d 。
  
  <但是，使用Google搜索推送消息的确给了我这个： ？p = 1441>我刚刚从BSOD重启，然后git push。那是当我收到有关无法解析参考文献/遥控器/原点/主...的投诉时。 [...]所以，我打开了主文件，它充满了空间！那么，这是不好的。为了解决它，我做了这个：[你的 rm ，然后 git fetch ]

  
  

  
  
  

  ---

  
  
  

  请参阅上面的注释，tl; dr是因为这些是远程引用，其中 git fetch 完全刷新，并且因为破坏是这样的： for-each-ref 和 git update-ref 根本无法使用，核选项 rm -rf refs / remotes / origin;

  



  在其他情况下，如果没有简单的方法来恢复受损的refs，或者使用git fetch 为了好奇，找到.git / refs / remotes / origin -type f 来检查锁或使用reflogs（这些文件位于 .git / logs ）恢复内容会有所帮助，但在这里没有必要。我认为我错过了一个赌注，不是先从 *。lock 文件执行 find > kill -9 ed早先的命令看起来很可能在这里，但我怀疑是一个模棱两可的ref和fer是我的第一步。
  
  

  ---

  
  

  I am having an issue with Git. For unknown reasons, my master branch has somehow gotten corrupted. I have a local commit that I want to push up, but when I push, I get this:

  git push origin master
  error: unable to resolve reference refs/remotes/origin/master: No such file or directory
  error: cannot lock the ref 'refs/remotes/origin/master'.
  Everything up-to-date
  

  I have seen the issue on other boards, but usually referring to pulls and not pushes. Nevertheless, I have tried their solutions, but to no avail:

  1. Tried amending to my current commit and pushing
  2. cleaned my git repository with git gc --prune=now
  3. Tried rm .git/refs/removes/origin/master

  None have solved my issues. Any thoughts or ideas?

  解决方案

  (a worthwhile tl;dr from @NeTeInStEiN:

  The nuclear option is rm -rf .git/refs/remotes/origin, and that's what it took here)

  edit: I've run across part of this behavior in one of my own repos, I can get git to reproduce the f-e-r failure without the rm .git/refs/remotes/origin/master hack:

  • clone a repo
  • delete the origin's primary branch (the one its HEAD's attached to)
  • run git fetch --prune in the clone

  The fetch will produce a dangling-ref warning, and git for-each-ref will fail with a familiar message:

  ~/sandbox/20/buddy$ git fetch --prune
  From /home/jthill/sandbox/20/source/.
   x [deleted]         (none)     -> origin/master
     (refs/remotes/origin/HEAD has become dangling)
  ~/sandbox/20/buddy$ git f-e-r
  fatal: missing object 0000000000000000000000000000000000000000 for refs/remotes/origin/HEAD
  

  but that doesn't break the push, I've tried with every setting of push.default, nor does it break git update-ref -d.

  However, googling the push message did get me this:

  I had just rebooted from a BSOD the other day [...] then git push. And that’s when I got a complaint about "Unable to resolve reference refs/remotes/origin/master…". [...] So, I opened up the master file and it was full of spaces! Well, that’s no good. In order to fix it, I did this: [your rm, and then git fetch]

  ---

  See comments above for the blow-by-blow, tl;dr is, because these were remote refs, which git fetch completely refreshes, and because the damage was such that for-each-ref and git update-ref failed to work at all, the nuclear option rm -rf refs/remotes/origin; git fetch was guaranteed to restore the remote properly.

  In other circumstances, if there'd been no easy way to restore the damaged refs or for curiosity, find .git/refs/remotes/origin -type f to check for locks or using reflogs (those files are in .git/logs) to recover content would have helped but it wasn't necessary here. I think I missed a bet by not doing the find first, *.lock files from a kill -9ed earlier command look likely here, but I suspected an ambiguous ref and f-e-r is my first step for those.

  ---

  这篇关于推送时Git无法解析引用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！