4

When performing a git clone, git goes through the stages

  • Receiving objects
  • Resolving deltas
  • Checking out files

I would expect all of the network activity to be during Receiving objects, then Resolving deltas to be entirely local (as explained here What is git actually doing when it says it is "resolving deltas"?) but actually there is still a connection open.

I can tell this in two ways:

  1. Wireshark shows no activity during Resolving deltas then there are a few packets exchanged after along with closing the connection.
  2. Sometimes I see a connection closed by remote host during a long Resolving deltas step.

So what I'm interested in knowing is why git needs this connection to stay open during Resolving deltas? Is it needed after that for some reason (e.g. a hook)?

(note: this may depend on whether you are using https or ssh)

Russell Gallop
  • 1,631
  • 2
  • 17
  • 34
  • https://stackoverflow.com/questions/4689844/what-is-git-actually-doing-when-it-says-it-is-resolving-deltas? – evolutionxbox Nov 09 '18 at 10:14
  • Possible duplicate of [What is git actually doing when it says it is "resolving deltas"?](https://stackoverflow.com/questions/4689844/what-is-git-actually-doing-when-it-says-it-is-resolving-deltas) – Mureinik Nov 09 '18 at 10:15
  • That question explains what git IS doing during "resolving deltas", and that is entirely local, hence I see no reason for a remote connection to remain. I have edited the question to clarify the relationship. – Russell Gallop Nov 09 '18 at 10:24
  • My guess is that git *might* need more files from the remote host. From the linked question: "In the case of a subsequent fetch, the received pack file may contain references to other objects that the receiving git **is expected to** already have." I suspect the connection is held open in case a base is found which is not in the same pack, but not yet cached locally either. – IMSoP Nov 09 '18 at 12:20

1 Answers1

2

Given that this direction does not have anything left to do at this phase, it's not clear why Git keeps the transport protocol open until the resolving is done. In the other direction—if you're pushing—your Git has to keep the connection open during the receiver's resolution of the delivered thin pack, as the server-side reference updates have not yet occurred, while your own Git needs to know whether they are successful. So for push, your Git must hold the connection open, wait for the resolution to finish, and wait to see what their Git reports for the reference update phase.

For clone, however, their Git does not care whether your Git is able to update your references. It should be possible to close the transport earlier. There are probably some unfortunate code constructs that make this too difficult right now, that cause Git to keep the connection open instead.

torek
  • 448,244
  • 59
  • 642
  • 775