projects / thirdparty / git.git / blame
| Commit | Line | Data |
|---|---|---|
| 368dc5d6 TA |
1 | Git-send-pack internals |
| 2 | ======================= | |
| b5ffa5ce JH |
3 | |
| 4 | Overall 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 | ||
| 27 | Pack_objects pipeline | |
| 28 | --------------------- | |
| 29 | ||
| 9d0524d4 | 30 | This function gets one file descriptor (`fd`) which is either a |
| b5ffa5ce JH |
31 | socket (over the network) or a pipe (local). What's written to |
| 32 | this fd goes to git-receive-pack to be unpacked. | |
| 33 | ||
| 34 | send-pack ---> fd ---> receive-pack | |
| 35 | ||
| 9d0524d4 JH |
36 | The function pack_objects creates a pipe and then forks. The |
| 37 | forked child execs pack-objects with --revs to receive revision | |
| 38 | parameters from its standard input. This process will write the | |
| 39 | packfile to the other end. | |
| b5ffa5ce JH |
40 | |
| 41 | send-pack | |
| 42 | | | |
| 9d0524d4 | 43 | pack_objects() ---> fd ---> receive-pack |
| b5ffa5ce JH |
44 | | ^ (pipe) |
| 45 | v | | |
| 9d0524d4 | 46 | (child) |
| b5ffa5ce | 47 | |
| 9d0524d4 JH |
48 | The child dup2's to arrange its standard output to go back to |
| 49 | the other end, and read its standard input to come from the | |
| 50 | pipe. After that it exec's pack-objects. On the other hand, | |
| 51 | the parent process, before starting to feed the child pipeline, | |
| 52 | closes the reading side of the pipe and fd to receive-pack. | |
| b5ffa5ce JH |
53 | |
| 54 | send-pack | |
| 55 | | | |
| 9d0524d4 | 56 | pack_objects(parent) |
| b5ffa5ce JH |
57 | | |
| 58 | v [0] | |
| 9d0524d4 | 59 | pack-objects [0] ---> receive-pack |
| b5ffa5ce JH |
60 | |
| 61 | ||
| 9d0524d4 JH |
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.] |