git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Clone hangs when done over http with --reference

From
Jeff King <peff@peff.net>
Date
May 14, 2015, 19:52 UTC
Message-ID
<20150514195226.GA10205@peff.net>
In-Reply-To
<5554D69E.20307@linuxfoundation.org>
On Thu, May 14, 2015 at 01:08:46PM -0400, Konstantin Ryabitsev wrote:
Show 6 quoted lines
> Two questions:
> 
> 1. Does this mean there are potential problems with other git operations
> that involve ref negotiation, not just when doing git clone --reference?
> Is there a chance to run in to this deadlock by doing an operation like
> "git remote update"?

Yes. From the server's perspective, a "clone --reference" is really no different than a fetch in which the client happened to have all of those refs already. I didn't try it, but you should be able to reproduce the problem with:

  cd first-repo.git
  git fetch https://.../second-repo.git refs/*:refs/remotes/foo/*

which should have to do the exact same ref negotiation ("I have these commits, I want these other commits").

Show 9 quoted lines
> 2. If we configure the webserver to serve some files directly, without
> passing them to http-backend, e.g. doing the recommended apache magic:
> 
> > AliasMatch ^/git/(.*/objects/[0-9a-f]{2}/[0-9a-f]{38})$          /var/lib/git/$1
> > AliasMatch ^/git/(.*/objects/pack/pack-[0-9a-f]{40}.(pack|idx))$ /var/lib/git/$1
> > AliasMatch ^/git/(.*/refs/heads/.*)$                             /var/lib/git/$1
> 
> Will that make the spooling less of a problem, since it won't involve
> the super-huge files?

No, that won't help. Once git is doing the smart protocol, it will never ask for arbitrary files. So you would have to disable smart-http entirely, which I don't recommend.

Besides which, it's not the size of the objects or packs that is an issue here. It's the relationship of the tips in the second repo to the tips in the first. That is, the "big" data here is the client and server finding the common commits between the two (and it's not even _that_ big; it's just big by "stuffing into a pipe buffer" standards; as you noticed, the git protocol handles it just fine).

-Peff
Previous: Konstantin RyabitsevNext: Jeff King
Message 6 of 24 in “Clone hangs when done over http with --reference”
  1. Konstantin RyabitsevMay 13, 2015
  2. Jeff KingMay 14, 2015
  3. http-backend: fix die recursion with custom handlerJeff King, May 14, 2015
  4. Jeff KingMay 15, 2015
  5. Konstantin RyabitsevMay 14, 2015
  6. Jeff KingMay 14, 2015
  7. 0/2 fix http deadlock on giant ref negotiationsJeff King, May 15, 2015
  8. 1/2 http-backend: fix die recursion with custom handlerJeff King, May 15, 2015
  9. 2/2 http-backend: spool ref negotiation requests to bufferJeff King, May 15, 2015
  10. Junio C HamanoMay 15, 2015
  11. Konstantin RyabitsevMay 15, 2015
  12. 0/3 fix http deadlock on giant ref negotiationsJeff King, May 20, 2015
  13. 1/3 http-backend: fix die recursion with custom handlerJeff King, May 20, 2015
  14. 2/3 t5551: factor out tag creationJeff King, May 20, 2015
  15. 3/3 http-backend: spool ref negotiation requests to bufferJeff King, May 20, 2015
  16. Konstantin RyabitsevMay 26, 2015
  17. Jeff KingMay 26, 2015
  18. Junio C HamanoMay 26, 2015
  19. Jeff KingMay 15, 2015
  20. Dennis KaarsemakerMay 15, 2015
  21. Jeff KingMay 15, 2015
  22. Dennis KaarsemakerMay 15, 2015
  23. Jeff KingMay 15, 2015
  24. Dennis KaarsemakerMay 15, 2015

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.