git推送某些分支名称失败 [英] git push failing for certain branch names

问题描述

在我们公司，使用我们的名字分支功能并不罕见。因此，如果我们在 master 并且想要分支一个新的特性，我们会创建 john / feature-test 或鲍勃/特征-test2的。这很好，直到最近我们的一个队友失去了将任何东西推到我们原点的能力。

她可以创建其他分支，但是如果分支以 mira /...然后它会失败，如下所示：

  $ git push -f 
计数对象：2，完成。 
使用多达4个线程的增量压缩。 
压缩对象：100％（2/2），完成。 
写入对象：100％（2/2），243字节| 0字节/秒，完成。 
 Total 2（delta 1），reused 0（delta 0）
 remote：error：无法更新ref'refs / heads / mira / testing'：无法创建日志目录/ refs / heads / mira / testing：没有这样的文件或目录
到[e-mail]：< team> /< repo> .git 
！ [remote rejected] mira / testing  - > mira / testing（未能更新参考）
错误：无法将某些参考文献推送到'[e-mail]：<团队> /<回购> .git'
  

当我在我的机器上试用此功能时，我会得到同样的结果。所以这个问题似乎与Bitbucket上的远程git服务器有关。我们尝试删除所有以 mira /...开头并且没有帮助的分支。我修剪了远程和本地的，运行了 git gc 等等。没有任何东西可以工作。

Whats有趣的是我们可以进入Bitbucket，创建一个名为 mira / testbranch 的分支，运行 git fetch ，运行 git checkout mira / testbranch ，进行更改，提交，然后推送...但推送仍然会失败并出现同样的问题。

>是在服务器上，并且必须在那里修复（可能通过客户端的操作;见下文）。

服务器将尽可能多的信息客户端，因为它合理可以（但见下文）：

远程：错误：无法更新ref'refs /头/ mira / testing'：无法创建日志目录/ refs / heads / mira / testing：没有该文件或目录

我们可以合作nclude：

• 服务器配置有 core.logAllRefUpdates set（见下文）


• 文件 logs / refs / heads / mira / testing 目前不存在（见下文）
  
• logs / refs / heads / mira 中的某些目录/目录也存在/不存在


• 也没有创建该目录，因为一些前辈目录不存在（这是一个神秘的部分，因为git会根据需要在路径中创建每个目录）。
  
  
  

  进一步的调查应该可能发生在服务器上，但最可能的问题是 logs / refs / heads / mira 已经作为普通文件存在，而不是一个目录，并且git在生成目录序列期间使用 ENOENT 错误修改了文件路径的 EEXIST 错误。 （这是git中的一个小错误：它必须失败，但可能会说无法创建日志/ refs / heads / mira / testing，因为logs / refs / heads / mira是常规文件。而且，如果有一个未删除的分支（见下文），它应该提供更清晰的错误消息;这将是git中的一个更大的错误。）

  
  
  

  假设我的猜测（有这样一个文件）首先是正确的，那么该文件如何留下是一个谜。可能有一个名为 mira 的分支，它必须创建一个名为 logs / refs / heads / mira 的reflog文件，但当它被删除时 - 为了创建一个名为 mira / testing 的分支，如果已经有一个分支 X ，那么你不能有一个分支 X / Y - 也应该删除reflog 。但是如果这个是这个问题，那么修复就是如果您希望恢复其内容，则可以将该文件移开，或者如果没有，则将其全部删除。如果有一个未删除的分支（在分支问题之前显示reflog问题），您可以简单地删除该分支，这也将删除reflog文件。

  
  
  

  您也可以禁用 core.logAllRefUpdates 。通常它会被禁用，因为它应该是一个 - 裸存储库。

  
  
  

  关于 core.logAllRefUpdates

  
  
  

  这在 git config 文档：
  
  

  
  

  core.logAllRefUpdates

  
  
  

  启用引用日志。更新ref< ref>通过追加新的和旧的SHA-1，日期/时间和更新的原因，但只有当文件存在时才记录到文件$ GIT_DIR / logs / 。如果此配置变量设置为true，则缺少$ GIT_DIR / logs /< ref>文件是为分支头（即在refs / heads /下），远程ref（即在refs / remotes /下），注释ref（即在refs / notes /下）和符号ref HEAD自动创建的。
  $ b

  此信息可用于确定2天前分支的提示是什么。

  
  
  

  此值为true默认情况下，存储库中有一个与其关联的工作目录，默认情况下在裸存储库中为false。

  
  

  
  

  In our company, it is not uncommon to branch features out using our names. So if we are on master and want to branch a new feature, we would create john/feature-test or bob/feature-test2. This has worked great until recently one of our teammates lost the ability to push anything onto our origin.

  She can create other branches just fine, but if the branch starts with mira/... then it fails like this:

  $ git push -f
  Counting objects: 2, done.
  Delta compression using up to 4 threads.
  Compressing objects: 100% (2/2), done.
  Writing objects: 100% (2/2), 243 bytes | 0 bytes/s, done.
  Total 2 (delta 1), reused 0 (delta 0)
  remote: error: Cannot update the ref 'refs/heads/mira/testing': unable to create directory for logs/refs/heads/mira/testing: No such file or directory
  To [e-mail]:<team>/<repo>.git
   ! [remote rejected] mira/testing -> mira/testing (failed to update ref)
  error: failed to push some refs to '[e-mail]:<team>/<repo>.git'
  

  I get the same thing when I try this on my machine. So the problem appears to be with the remote git server on Bitbucket. We have tried deleting all branches that start with mira/... and that didn't help. I have pruned the remote and local, ran a git gc, etc.. nothing seems to work.

  Whats interesting is we can go into Bitbucket, create a branch called mira/testbranch, run git fetch, run git checkout mira/testbranch, make a change, commit, then push... but the push will still fail with the same problem.

  Does anyone have any idea how this could occur and what we can do to fix it?

  解决方案

  The problem is on the server and must be fixed there (perhaps by action on a client; see below).

  The server is giving as much information to the client as it reasonably can (but see below):

  remote: error: Cannot update the ref 'refs/heads/mira/testing': unable to create directory for logs/refs/heads/mira/testing: No such file or directory

  from which we can conclude:

  • the server config has core.logAllRefUpdates set (see below)
  • file logs/refs/heads/mira/testing does not currently exist (see below)
  • some directory/directories in logs/refs/heads/mira also does/do not exist
  • the process doing the push is also failing to create that directory because some predecessor directory does not exist (this is the mysterious part, since git will create every directory in the path as needed).

  Further investigation should probably happen on the server, but the most likely problem is that logs/refs/heads/mira already exists as a plain file rather than a directory, and git is clobbering the EEXIST error for the file path with an ENOENT error during the make-directories sequence. (This would be a minor bug in git: either way it must fail, but it could say "unable to create logs/refs/heads/mira/testing because logs/refs/heads/mira is a regular file", for instance. Moreover, if there is an un-deleted branch in the way—see below—it should give a much clearer error message; this would be a bigger bug in git.)

  How that file got left behind is a mystery, assuming my guess (that there is such a file) is correct in the first place. Probably there was a branch named mira, which necessitated creating a reflog file named logs/refs/heads/mira, but when it was deleted—which it must have been at some point in order to create a branch named mira/testing; you cannot have a branch X/Y if there is already a branch X—that should have deleted the reflog as well. But if this is the problem, the fix is to move the file out of the way if you want its contents back, or just remove it entirely if not. If there is an un-deleted branch in the way (with the reflog problem showing up before the branch problem), you can simply delete the branch, which will also delete the reflog file.

  You can also disable core.logAllRefUpdates. Normally it would be disabled anyway since this should be a --bare repository.

  About core.logAllRefUpdates

  This is described reasonably well in the git config documentation:

  core.logAllRefUpdates

  Enable the reflog. Updates to a ref <ref> is logged to the file "$GIT_DIR/logs/<ref>", by appending the new and old SHA-1, the date/time and the reason of the update, but only when the file exists. If this configuration variable is set to true, missing "$GIT_DIR/logs/<ref>" file is automatically created for branch heads (i.e. under refs/heads/), remote refs (i.e. under refs/remotes/), note refs (i.e. under refs/notes/), and the symbolic ref HEAD.

  This information can be used to determine what commit was the tip of a branch "2 days ago".

  This value is true by default in a repository that has a working directory associated with it, and false by default in a bare repository.

  这篇关于git推送某些分支名称失败的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！