Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
李少辉-开发者
git
提交
45d2b286
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,发现更多精彩内容 >>
提交
45d2b286
编写于
2月 17, 2006
作者:
J
Junio C Hamano
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
SubmittingPatches: note on whitespaces
Signed-off-by:
N
Junio C Hamano
<
junkio@cox.net
>
上级
020e3c1e
变更
1
隐藏空白更改
内联
并排
Showing
1 changed file
with
19 addition
and
11 deletion
+19
-11
Documentation/SubmittingPatches
Documentation/SubmittingPatches
+19
-11
未找到文件。
Documentation/SubmittingPatches
浏览文件 @
45d2b286
...
...
@@ -4,8 +4,8 @@ it for the core GIT to make sure people understand what they are
doing when they write "Signed-off-by" line.
But the patch submission requirements are a lot more relaxed
here
, because the core GIT is thousand times smaller ;-). So
here is only the relevant bits.
here
on the technical/contents front, because the core GIT is
thousand times smaller ;-). So
here is only the relevant bits.
(1)
Make separate commits for logically separate changes.
...
...
@@ -18,13 +18,19 @@ repository. It is a good discipline.
Describe the technical detail of the change(s).
If your description starts to get long, that's a sign that you
If your description starts to get
too
long, that's a sign that you
probably need to split up your commit to finer grained pieces.
Oh, another thing. I am picky about whitespaces. Make sure your
changes do not trigger errors with the sample pre-commit hook shipped
in templates/hooks--pre-commit.
(2)
Generate your patch using git/cogito out of your commits.
git diff tools generate unidiff which is the preferred format.
(2)
Generate your patch using git tools out of your commits.
git based diff tools (git, Cogito, and StGIT included) generate
unidiff which is the preferred format.
You do not have to be afraid to use -M option to "git diff" or
"git
format-patch", if your patch involves file renames. The
receiving end can handle them just fine.
...
...
@@ -33,20 +39,22 @@ Please make sure your patch does not include any extra files
which do not belong in a patch submission. Make sure to review
your patch after generating it, to ensure accuracy. Before
sending out, please make sure it cleanly applies to the "master"
branch head.
branch head. If you are preparing a work based on "next" branch,
that is fine, but please mark it as such.
(3)
Sending your patches.
People on the git mailing list need
s
to be able to read and
People on the git mailing list need to be able to read and
comment on the changes you are submitting. It is important for
a developer to be able to "quote" your changes, using standard
e-mail tools, so that they may comment on specific portions of
your code. For this reason, all patches should be submitting
e-mail "inline". WARNING: Be wary of your MUAs word-wrap
corrupting your patch. Do not cut-n-paste your patch.
your code. For this reason, all patches should be submited
"inline".
WARNING: Be wary of your MUAs word-wrap
corrupting your patch. Do not cut-n-paste your patch; you can
lose tabs that way if you are not careful.
It is common convention to prefix your subject line with
It is
a
common convention to prefix your subject line with
[PATCH].
This lets people easily distinguish patches from other
e-mail discussions.
...
...
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录