undef/git-commit-vandalism
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Update send-pack pipeline documentation.

Browse Source 
The pipeline was much more complex and needed documentation, but
now it is trivial and straightforward.

Signed-off-by: Junio C Hamano <junkio@cox.net>
This commit is contained in:
Junio C Hamano 2007-01-01 12:07:26 -08:00
parent 4385355454
commit 9d0524d42f
1 changed files with 16 additions and 65 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

81
Documentation/technical/send-pack-pipeline.txt
View File

@ -27,86 +27,37 @@ Overall operation
Pack_objects pipeline 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 socket (over the network) or a pipe (local). What's written to
this fd goes to git-receive-pack to be unpacked. this fd goes to git-receive-pack to be unpacked.
send-pack ---> fd ---> receive-pack send-pack ---> fd ---> receive-pack
It somehow forks once, but does not wait for it. I am not sure The function pack_objects creates a pipe and then forks. The
why. forked child execs pack-objects with --revs to receive revision
parameters from its standard input. This process will write the
The forked child calls rev_list_generate() with that file packfile to the other end.
descriptor (while the parent closes `out` -- the child will be
the one that writes the packfile to the other end).
send-pack send-pack
| |
rev-list-generate ---> fd ---> receive-pack pack_objects() ---> 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.
send-pack
|
rev-list-generate ---> fd ---> receive-pack
| ^ (pipe) | ^ (pipe)
v | v |
rev-list (child)
The child process, before calling rev-list, rearranges the file The child dup2's to arrange its standard output to go back to
descriptors: the other end, and read its standard input to come from the
pipe. After that it exec's pack-objects. On the other hand,
. what it reads from rev-list-generate via pipe becomes the the parent process, before starting to feed the child pipeline,
stdin; this is to feed the upstream of the pipeline which will closes the reading side of the pipe and fd to receive-pack.
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.
send-pack send-pack
| |
rev-list-generate pack_objects(parent)
| |
v [0] v [0]
rev-list [1] ---> receive-pack pack-objects [0] ---> 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
[jc: the pipeline was much more complex and needed documentation before
I understood an earlier bug, but now it is trivial and straightforward.]