mirror of
https://github.com/git/git.git
synced 2024-12-13 03:44:17 +08:00
113 lines
3.1 KiB
Plaintext
113 lines
3.1 KiB
Plaintext
git-send-pack
|
|
=============
|
|
|
|
Overall operation
|
|
-----------------
|
|
|
|
. Connects to the remote side and invokes git-receive-pack.
|
|
|
|
. Learns what refs the remote has and what commit they point at.
|
|
Matches them to the refspecs we are pushing.
|
|
|
|
. Checks if there are non-fast-forwards. Unlike fetch-pack,
|
|
the repository send-pack runs in is supposed to be a superset
|
|
of the recipient in fast-forward cases, so there is no need
|
|
for want/have exchanges, and fast-forward check can be done
|
|
locally. Tell the result to the other end.
|
|
|
|
. Calls pack_objects() which generates a packfile and sends it
|
|
over to the other end.
|
|
|
|
. If the remote side is new enough (v1.1.0 or later), wait for
|
|
the unpack and hook status from the other end.
|
|
|
|
. Exit with appropriate error codes.
|
|
|
|
|
|
Pack_objects pipeline
|
|
---------------------
|
|
|
|
This function gets one file descriptor (`out`) 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.
|
|
|
|
send-pack
|
|
|
|
|
rev-list-generate ---> fd ---> receive-pack
|
|
| ^ (pipe)
|
|
v |
|
|
rev-list
|
|
|
|
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.
|
|
|
|
send-pack
|
|
|
|
|
rev-list-generate
|
|
|
|
|
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
|
|
|
|
|
|
|