1git-send-pack 2============= 3 4Overall operation 5----------------- 6 7. Connects to the remote side and invokes git-receive-pack. 8 9. Learns what refs the remote has and what commit they point at. 10 Matches them to the refspecs we are pushing. 11 12. Checks if there are non-fast-forwards. Unlike fetch-pack, 13 the repository send-pack runs in is supposed to be a superset 14 of the recipient in fast-forward cases, so there is no need 15 for want/have exchanges, and fast-forward check can be done 16 locally. Tell the result to the other end. 17 18. Calls pack_objects() which generates a packfile and sends it 19 over to the other end. 20 21. If the remote side is new enough (v1.1.0 or later), wait for 22 the unpack and hook status from the other end. 23 24. Exit with appropriate error codes. 25 26 27Pack_objects pipeline 28--------------------- 29 30This function gets one file descriptor (`fd`) which is either a 31socket (over the network) or a pipe (local). What's written to 32this fd goes to git-receive-pack to be unpacked. 33 34 send-pack ---> fd ---> receive-pack 35 36The function pack_objects creates a pipe and then forks. The 37forked child execs pack-objects with --revs to receive revision 38parameters from its standard input. This process will write the 39packfile to the other end. 40 41 send-pack 42 | 43 pack_objects() ---> fd ---> receive-pack 44 | ^ (pipe) 45 v | 46 (child) 47 48The child dup2's to arrange its standard output to go back to 49the other end, and read its standard input to come from the 50pipe. After that it exec's pack-objects. On the other hand, 51the parent process, before starting to feed the child pipeline, 52closes the reading side of the pipe and fd to receive-pack. 53 54 send-pack 55 | 56 pack_objects(parent) 57 | 58 v [0] 59 pack-objects [0] ---> receive-pack 60 61 62[jc: the pipeline was much more complex and needed documentation before 63 I understood an earlier bug, but now it is trivial and straightforward.]