为什么git-upload-pack（git clone期间）挂起？ [英] Why would git-upload-pack (during git clone) hang?

问题描述

我读过其他几个'git挂在克隆'问题上，但没有一个匹配我的环境和细节。我使用cygwin（msys git不是一个选项）构建的git，通过SSH克隆Linux主机的repo。

  git clone user @ host：repo 
  

我针对其他平台上的同一主机进行了测试，它工作正常，但在这台Windows机器上，克隆无限期地挂起。我设置了 GIT_TRACE = 1 ，看起来问题出在这个命令上：

 'ssh''user @ host''git-upload-pack'\''repo'\'''
  

我的SSH密钥设置正确： ssh user @ host 工作正常。当我运行这个命令时，我得到了一堆输出结果如下： / tags / start
0000

然后它会挂起20分钟以上，这是最长的我已经等了，然后再杀了它。

服务器的Git 1.7.11.7和OpenSSH 5.9p1，而客户端的Git 1.7.9和OpenSSH 6.1p1。 p>

这应该是git-upload-pack输出的结尾吗？这是一个在Git或我的配置中的错误？

解决方案

即将推出的git1.8.5（2013年第四季度）协议。

通过提交4c6fffe2ae3642fa4576c704e2eb443de1d0f8a1 ：//github.com/spearcerel =nofollow> Shawn O. Pearce 。

通过详细的文档，这个想法可以监控在你的git客户端和服务器之间完成的web请求，看看它们是否符合以下文档。

这可以帮助确定服务挂起的位置。

---

档案 Documentation / technical / http-protocol.txt 坚持：

• 智能服务git-upload-pack

  
  
  
  
  

  • 客户端必须首先执行ref查找，并使用' $ GIT_URL / info / refs？service = git-upload

      C：POST $ GIT_URL / git-upload-pack HTTP / 1.0 
     S：200 OK 
     S：Content-Type：application / x-git-upload-pack-result 
     S：Cache-Control：no-cache 
     S：
     S：.... ACK％s，继续
     S：.... NAK 
      

  
  

  • 客户端不得重用或重新验证缓存的响应。
    

  • 服务器必须包含足够的缓存控制标头
    以防止缓存响应。 / li>
    
  • 服务器应该支持这里定义的所有功能。
    
  • 客户端必须在请求主体中至少发送一个'want'命令。
  
  
  • 客户端不能在'want'命令中引用没有出现的id通过ref发现获得的响应，除非服务器通告能力allow-tip-sha1-in-want。
    
  
  

  • negociation算法 （c）发送一个$ GIT_URL / git-upload-pack请求：
C（code code $ c $ ：0032want< WANT＃1> ...............................


  
  
  
  

  I've read several other 'git hangs on clone' questions, but none match my environment and details. I'm using git built under cygwin (msys git is not an option) to clone a repo from a Linux host over SSH.

  git clone user@host:repo
  

  I've tested against the same host on other platforms, and it works fine, but on this Windows machine the clone hangs indefinitely. I set GIT_TRACE=1 and it looks like the problem is with this command:

  'ssh' 'user@host' 'git-upload-pack '\''repo'\'''
  

  My SSH keys are set up correctly: ssh user@host works fine. When I run the command, I get a bunch of output that ends like this:

  ...
  003dbbd3db63763922ad75bbeefa3811dce001576851 refs/tags/start
  0000
  

  Then it hangs for 20+ minutes, which is the longest I've waited before killing it.

  The server has Git 1.7.11.7 with OpenSSH 5.9p1, while the client has Git 1.7.9 with OpenSSH 6.1p1.

  Is that supposed to be the end of the git-upload-pack output? Is this a bug in Git or my configuration?

  解决方案

  The upcoming git1.8.5 (Q4 2013) will document more the smart http protocol.
  See commit 4c6fffe2ae3642fa4576c704e2eb443de1d0f8a1 by Shawn O. Pearce.

  With that detailed documentation, the idea would be to monitor the web requests done between your git client and the server, and see if those conforms to what is documented below.

  That could help in pinpointing where the service "hangs".

  ---

  The file Documentation/technical/http-protocol.txt insists on:

  • the "Smart Service git-upload-pack"

    • Clients MUST first perform ref discovery with '$GIT_URL/info/refs?service=git-upload-pack'.

      C: POST $GIT_URL/git-upload-pack HTTP/1.0
      S: 200 OK
      S: Content-Type: application/x-git-upload-pack-result
      S: Cache-Control: no-cache
      S:
      S: ....ACK %s, continue
      S: ....NAK
      

    • Clients MUST NOT reuse or revalidate a cached reponse.

    • Servers MUST include sufficient Cache-Control headers to prevent caching of the response.
    • Servers SHOULD support all capabilities defined here.
    • Clients MUST send at least one 'want' command in the request body.
    • Clients MUST NOT reference an id in a 'want' command which did not appear in the response obtained through ref discovery unless the server advertises capability "allow-tip-sha1-in-want".

  • The "negociation" algorithm

    (c) Send one $GIT_URL/git-upload-pack request:
    C: 0032want <WANT #1>...............................
    

  这篇关于为什么git-upload-pack（git clone期间）挂起？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！