Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
李少辉-开发者
git
提交
b5ffa5ce
G
git
项目概览
李少辉-开发者
/
git
与 Fork 源项目一致
从无法访问的项目Fork
通知
2
Star
1
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
G
git
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
提交
Issue看板
体验新版 GitCode,发现更多精彩内容 >>
提交
b5ffa5ce
编写于
12月 29, 2006
作者:
J
Junio C Hamano
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
Documentation: illustrate send-pack pipeline.
Signed-off-by:
N
Junio C Hamano
<
junkio@cox.net
>
上级
e40a9e2c
变更
1
隐藏空白更改
内联
并排
Showing
1 changed file
with
112 addition
and
0 deletion
+112
-0
Documentation/technical/send-pack-pipeline.txt
Documentation/technical/send-pack-pipeline.txt
+112
-0
未找到文件。
Documentation/technical/send-pack-pipeline.txt
0 → 100644
浏览文件 @
b5ffa5ce
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
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录