7 . Connects to the remote side and invokes git-receive-pack.
9 . Learns what refs the remote has and what commit they point at.
10 Matches them to the refspecs we are pushing.
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.
18 . Calls pack_objects() which generates a packfile and sends it
19 over to the other end.
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.
24 . Exit with appropriate error codes.
30 This function gets one file descriptor (`out`) which is either a
31 socket (over the network) or a pipe (local). What's written to
32 this fd goes to git-receive-pack to be unpacked.
34 send-pack ---> fd ---> receive-pack
36 It somehow forks once, but does not wait for it. I am not sure
39 The forked child calls rev_list_generate() with that file
40 descriptor (while the parent closes `out` -- the child will be
41 the one that writes the packfile to the other end).
45 rev-list-generate ---> fd ---> receive-pack
48 Then rev-list-generate forks after creates a pipe; the child
49 will become a pipeline "rev-list --stdin | pack-objects", which
50 is the rev_list() function, while the parent feeds that pipeline
55 rev-list-generate ---> fd ---> receive-pack
60 The child process, before calling rev-list, rearranges the file
63 . what it reads from rev-list-generate via pipe becomes the
64 stdin; this is to feed the upstream of the pipeline which will
65 be git-rev-list process.
67 . what it writes to its stdout goes to the fd connected to
70 On the other hand, the parent process, before starting to feed
71 the child pipeline, closes the reading side of the pipe and fd
79 rev-list [1] ---> receive-pack
81 The parent then writes to the pipe and later closes it. There
82 is a commented out waitpid to wait for the rev-list side before
83 it exits, I again do not understand why.
85 The rev-list function further sets up a pipe and forks to run
86 git-rev-list piped to git-pack-objects. The child side, before
87 exec'ing git-pack-objects, rearranges the file descriptors:
89 . what it reads from the pipe becomes the stdin; this gets the
90 list of objects from the git-rev-list process.
92 . its stdout is already connected to receive-pack, so what it
95 The parent process arranges its file descriptors before exec'ing
98 . its stdout is sent to the pipe to feed git-pack-objects.
100 . its stdin is already connected to rev-list-generate and will
101 read the set of refs from it.
109 git-rev-list [1] ---> [0] git-pack-objects [1] ---> receive-pack