Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
李少辉-开发者
git
提交
5071877d
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,发现更多精彩内容 >>
提交
5071877d
编写于
8月 26, 2007
作者:
J
J. Bruce Fields
浏览文件
操作
浏览文件
下载
差异文件
Merge branch 'maint'
Conflicts: Documentation/user-manual.txt
上级
6e30fb0c
a115daff
变更
1
隐藏空白更改
内联
并排
Showing
1 changed file
with
48 addition
and
84 deletion
+48
-84
Documentation/user-manual.txt
Documentation/user-manual.txt
+48
-84
未找到文件。
Documentation/user-manual.txt
浏览文件 @
5071877d
...
...
@@ -42,10 +42,9 @@ How to get a git repository
It will be useful to have a git repository to experiment with as you
read this manual.
The best way to get one is by using the gitlink:git-clone[1] command
to download a copy of an existing repository for a project that you
are interested in. If you don't already have a project in mind, here
are some interesting examples:
The best way to get one is by using the gitlink:git-clone[1] command to
download a copy of an existing repository. If you don't already have a
project in mind, here are some interesting examples:
------------------------------------------------
# git itself (approx. 10MB download):
...
...
@@ -63,21 +62,18 @@ directory, you will see that it contains a copy of the project files,
together with a special top-level directory named ".git", which
contains all the information about the history of the project.
In most of the following, examples will be taken from one of the two
repositories above.
[[how-to-check-out]]
How to check out a different version of a project
-------------------------------------------------
Git is best thought of as a tool for storing the history of a
collection of files. It stores the history as a compressed
collection of interrelated snapshots (versions) of the project's
contents
.
Git is best thought of as a tool for storing the history of a
collection
of files. It stores the history as a compressed collection of
interrelated snapshots of the project's contents. In git each such
version is called a <<def_commit,commit>>
.
A single git repository may contain multiple branches. It keeps track
of them by keeping a list of <<def_head,heads>> which reference the
latest
version
on each branch; the gitlink:git-branch[1] command shows
latest
commit
on each branch; the gitlink:git-branch[1] command shows
you the list of branch heads:
------------------------------------------------
...
...
@@ -149,32 +145,27 @@ current branch:
------------------------------------------------
$ git show
commit 2b5f6dcce5bf94b9b119e9ed8d537098ec61c3d2
Author: Jamal Hadi Salim <hadi@cyberus.ca>
Date: Sat Dec 2 22:22:25 2006 -0800
[XFRM]: Fix aevent structuring to be more complete.
aevents can not uniquely identify an SA. We break the ABI with this
patch, but consensus is that since it is not yet utilized by any
(known) application then it is fine (better do it now than later).
Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
Signed-off-by: David S. Miller <davem@davemloft.net>
diff --git a/Documentation/networking/xfrm_sync.txt b/Documentation/networking/xfrm_sync.txt
index 8be626f..d7aac9d 100644
--- a/Documentation/networking/xfrm_sync.txt
+++ b/Documentation/networking/xfrm_sync.txt
@@ -47,10 +47,13 @@ aevent_id structure looks like:
struct xfrm_aevent_id {
struct xfrm_usersa_id sa_id;
+ xfrm_address_t saddr;
__u32 flags;
+ __u32 reqid;
};
...
commit 17cf781661e6d38f737f15f53ab552f1e95960d7
Author: Linus Torvalds <torvalds@ppc970.osdl.org.(none)>
Date: Tue Apr 19 14:11:06 2005 -0700
Remove duplicate getenv(DB_ENVIRONMENT) call
Noted by Tony Luck.
diff --git a/init-db.c b/init-db.c
index 65898fa..b002dc6 100644
--- a/init-db.c
+++ b/init-db.c
@@ -7,7 +7,7 @@
int main(int argc, char **argv)
{
- char *sha1_dir = getenv(DB_ENVIRONMENT), *path;
+ char *sha1_dir, *path;
int len, i;
if (mkdir(".git", 0755) < 0) {
------------------------------------------------
As you can see, a commit shows who made the latest change, what they
...
...
@@ -923,7 +914,7 @@ they look OK.
[[Finding-comments-with-given-content]]
Finding commits referencing a file with given content
-----------------------------------------------------
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Somebody hands you a copy of a file, and asks which commits modified a
file such that it contained the given content either before or after the
...
...
@@ -1105,20 +1096,14 @@ backup files made by your editor. Of course, 'not' tracking files with git
is just a matter of 'not' calling "`git add`" on them. But it quickly becomes
annoying to have these untracked files lying around; e.g. they make
"`git add .`" and "`git commit -a`" practically useless, and they keep
showing up in the output of "`git status`"
, etc
.
showing up in the output of "`git status`".
Git therefore provides "exclude patterns" for telling git which files to
actively ignore. Exclude patterns are thoroughly explained in the
gitlink:gitignore[5] manual page, but the heart of the concept is simply
a list of files which git should ignore. Entries in the list may contain
globs to specify multiple files, or may be prefixed by "`!`" to
explicitly include (un-ignore) a previously excluded (ignored) file
(i.e. later exclude patterns override earlier ones). The following
example should illustrate such patterns:
You can tell git to ignore certain files by creating a file called .gitignore
in the top level of your working directory, with contents such as:
-------------------------------------------------
# Lines starting with '#' are considered comments.
# Ignore foo.txt.
# Ignore
any file named
foo.txt.
foo.txt
# Ignore (generated) html files,
*.html
...
...
@@ -1128,41 +1113,20 @@ foo.txt
*.[oa]
-------------------------------------------------
The next question is where to put these exclude patterns so that git can
find them. Git looks for exclude patterns in the following files:
`.gitignore` files in your working tree:::
You may store multiple `.gitignore` files at various locations in your
working tree. Each `.gitignore` file is applied to the directory where
it's located, including its subdirectories. Furthermore, the
`.gitignore` files can be tracked like any other files in your working
tree; just do a "`git add .gitignore`" and commit. `.gitignore` is
therefore the right place to put exclude patterns that are meant to
be shared between all project participants, such as build output files
(e.g. `\*.o`), etc.
`.git/info/exclude` in your repo:::
Exclude patterns in this file are applied to the working tree as a
whole. Since the file is not located in your working tree, it does
not follow push/pull/clone like `.gitignore` can do. This is therefore
the place to put exclude patterns that are local to your copy of the
repo (i.e. 'not' shared between project participants), such as
temporary backup files made by your editor (e.g. `\*~`), etc.
The file specified by the `core.excludesfile` config directive:::
By setting the `core.excludesfile` config directive you can tell git
where to find more exclude patterns (see gitlink:git-config[1] for
more information on configuration options). This config directive
can be set in the per-repo `.git/config` file, in which case the
exclude patterns will apply to that repo only. Alternatively, you
can set the directive in the global `~/.gitconfig` file to apply
the exclude pattern to all your git repos. As with the above
`.git/info/exclude` (and, indeed, with git config directives in
general), this directive does not follow push/pull/clone, but remain
local to your repo(s).
[NOTE]
In addition to the above alternatives, there are git commands that can take
exclude patterns directly on the command line. See gitlink:git-ls-files[1]
for an example of this.
See gitlink:gitignore[5] for a detailed explanation of the syntax. You can
also place .gitignore files in other directories in your working tree, and they
will apply to those directories and their subdirectories. The `.gitignore`
files can be added to your repository like any other files (just run `git add
.gitignore` and `git commit`, as usual), which is convenient when the exclude
patterns (such as patterns matching build output files) would also make sense
for other users who clone your repository.
If you wish the exclude patterns to affect only certain repositories
(instead of every repository for a given project), you may instead put
them in a file in your repository named .git/info/exclude, or in any file
specified by the `core.excludesfile` configuration variable. Some git
commands can also take exclude patterns directly on the command line.
See gitlink:gitignore[5] for the details.
[[how-to-merge]]
How to merge
...
...
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录