From: Junio C Hamano Date: Mon, 1 Jan 2007 20:07:26 +0000 (-0800) Subject: Update send-pack pipeline documentation. X-Git-Tag: v1.5.0-rc1~119 X-Git-Url: https://git.tokkee.org/?a=commitdiff_plain;h=9d0524d42f340fc49f9e175d966afb7dce3854bb;p=git.git Update send-pack pipeline documentation. The pipeline was much more complex and needed documentation, but now it is trivial and straightforward. Signed-off-by: Junio C Hamano --- diff --git a/Documentation/technical/send-pack-pipeline.txt b/Documentation/technical/send-pack-pipeline.txt index bd32aff00..681efe421 100644 --- a/Documentation/technical/send-pack-pipeline.txt +++ b/Documentation/technical/send-pack-pipeline.txt @@ -27,86 +27,37 @@ Overall operation Pack_objects pipeline --------------------- -This function gets one file descriptor (`out`) which is either a +This function gets one file descriptor (`fd`) which is either a socket (over the network) or a pipe (local). What's written to this fd goes to git-receive-pack to be unpacked. send-pack ---> fd ---> receive-pack -It somehow forks once, but does not wait for it. I am not sure -why. - -The forked child calls rev_list_generate() with that file -descriptor (while the parent closes `out` -- the child will be -the one that writes the packfile to the other end). - - send-pack - | - rev-list-generate ---> fd ---> receive-pack - - -Then rev-list-generate forks after creates a pipe; the child -will become a pipeline "rev-list --stdin | pack-objects", which -is the rev_list() function, while the parent feeds that pipeline -the list of refs. +The function pack_objects creates a pipe and then forks. The +forked child execs pack-objects with --revs to receive revision +parameters from its standard input. This process will write the +packfile to the other end. send-pack | - rev-list-generate ---> fd ---> receive-pack + pack_objects() ---> fd ---> receive-pack | ^ (pipe) v | - rev-list + (child) -The child process, before calling rev-list, rearranges the file -descriptors: - -. what it reads from rev-list-generate via pipe becomes the - stdin; this is to feed the upstream of the pipeline which will - be git-rev-list process. - -. what it writes to its stdout goes to the fd connected to - receive-pack. - -On the other hand, the parent process, before starting to feed -the child pipeline, closes the reading side of the pipe and fd -to receive-pack. +The child dup2's to arrange its standard output to go back to +the other end, and read its standard input to come from the +pipe. After that it exec's pack-objects. On the other hand, +the parent process, before starting to feed the child pipeline, +closes the reading side of the pipe and fd to receive-pack. send-pack | - rev-list-generate + pack_objects(parent) | v [0] - rev-list [1] ---> receive-pack - -The parent then writes to the pipe and later closes it. There -is a commented out waitpid to wait for the rev-list side before -it exits, I again do not understand why. - -The rev-list function further sets up a pipe and forks to run -git-rev-list piped to git-pack-objects. The child side, before -exec'ing git-pack-objects, rearranges the file descriptors: - -. what it reads from the pipe becomes the stdin; this gets the - list of objects from the git-rev-list process. - -. its stdout is already connected to receive-pack, so what it - generates goes there. - -The parent process arranges its file descriptors before exec'ing -git-rev-list: - -. its stdout is sent to the pipe to feed git-pack-objects. - -. its stdin is already connected to rev-list-generate and will - read the set of refs from it. - - - send-pack - | - rev-list-generate - | - v [0] - git-rev-list [1] ---> [0] git-pack-objects [1] ---> receive-pack - + pack-objects [0] ---> receive-pack +[jc: the pipeline was much more complex and needed documentation before + I understood an earlier bug, but now it is trivial and straightforward.]