From: Junio C Hamano Date: Sun, 10 Aug 2008 03:55:58 +0000 (+0000) Subject: Autogenerated HTML docs for v1.6.0-rc2-22-g71b9 X-Git-Url: http://git.tremily.us/?a=commitdiff_plain;h=faa1e50737bfc349e8315c99a2ed59182fd557b1;p=git.git Autogenerated HTML docs for v1.6.0-rc2-22-g71b9 --- diff --git a/RelNotes-1.6.0.txt b/RelNotes-1.6.0.txt index e524d80fb..8afb5b253 100644 --- a/RelNotes-1.6.0.txt +++ b/RelNotes-1.6.0.txt @@ -5,7 +5,7 @@ User visible changes -------------------- With the default Makefile settings, most of the programs are now -installed outside your $PATH, except for "git", "gitk", "git-gui" and +installed outside your $PATH, except for "git", "gitk" and some server side programs that need to be accessible for technical reasons. Invoking a git subcommand as "git-xyzzy" from the command line has been deprecated since early 2006 (and officially announced in @@ -186,7 +186,7 @@ Updates since v1.5.6 * fast-import and fast-export learned to export and import gitlinks. -* "gitk" left background process behind after begin asked to dig very deep +* "gitk" left background process behind after being asked to dig very deep history and the user killed the UI; the process is killed when the UI goes away now. @@ -248,6 +248,6 @@ this release, unless otherwise noted. --- exec >/var/tmp/1 -O=v1.6.0-rc1-113-gf44bc33 +O=v1.6.0-rc2-21-g0bb3a0b echo O=$(git describe refs/heads/master) git shortlog --no-merges $O..refs/heads/master ^refs/heads/maint diff --git a/git-commit-tree.html b/git-commit-tree.html index 1f832dfb7..da3e1fd5d 100644 --- a/git-commit-tree.html +++ b/git-commit-tree.html @@ -327,11 +327,11 @@ git-commit-tree(1) Manual Page

This is usually not what an end user wants to run directly. See git-commit(1) instead.

Creates a new commit object based on the provided tree object and -emits the new commit object id on stdout. If no parent is given then -it is considered to be an initial tree.

-

A commit object usually has 1 parent (a commit after a change) or up -to 16 parents. More than one parent represents a merge of branches -that led to them.

+emits the new commit object id on stdout.

+

A commit object may have any number of parents. With exactly one +parent, it is an ordinary commit. Having more than one parent makes +the commit a merge between several lines of history. Initial (root) +commits have no parents.

While a tree represents a particular directory state of a working directory, a commit represents that state in "time", and explains how to get there.

@@ -525,7 +525,7 @@ reversible operation.

diff --git a/git-commit-tree.txt b/git-commit-tree.txt index feec58400..92ab3ab4a 100644 --- a/git-commit-tree.txt +++ b/git-commit-tree.txt @@ -16,12 +16,12 @@ This is usually not what an end user wants to run directly. See linkgit:git-commit[1] instead. Creates a new commit object based on the provided tree object and -emits the new commit object id on stdout. If no parent is given then -it is considered to be an initial tree. +emits the new commit object id on stdout. -A commit object usually has 1 parent (a commit after a change) or up -to 16 parents. More than one parent represents a merge of branches -that led to them. +A commit object may have any number of parents. With exactly one +parent, it is an ordinary commit. Having more than one parent makes +the commit a merge between several lines of history. Initial (root) +commits have no parents. While a tree represents a particular directory state of a working directory, a commit represents that state in "time", and explains how diff --git a/git-fetch.html b/git-fetch.html index 4cd3ad6c4..10a5b6a0a 100644 --- a/git-fetch.html +++ b/git-fetch.html @@ -485,7 +485,7 @@ branches you are not interested in, you will not get them.

The canonical format of a <refspec> parameter is - ?<src>:<dst>; that is, an optional plus , followed + +?<src>:<dst>; that is, an optional plus +, followed by the source ref, followed by a colon :, followed by the destination ref.

@@ -781,7 +781,7 @@ Junio C Hamano <gitster@pobox.com>

diff --git a/git-filter-branch.html b/git-filter-branch.html index 799e37052..1ef716e92 100644 --- a/git-filter-branch.html +++ b/git-filter-branch.html @@ -326,7 +326,7 @@ git-filter-branch(1) Manual Page [--msg-filter <command>] [--commit-filter <command>] [--tag-name-filter <command>] [--subdirectory-filter <directory>] [--original <namespace>] [-d <directory>] [-f | --force] - [<rev-list options>…] + [--] [<rev-list options>…]

DESCRIPTION

@@ -528,10 +528,10 @@ to other tags will be rewritten to point to the underlying commit.

- When options are given after the new branch name, they will - be passed to git-rev-list. Only commits in the resulting - output will be filtered, although the filtered commits can still - reference parents which are outside of that set. + Arguments for git-rev-list. All positive refs included by + these options are rewritten. You may also specify options + such as --all, but you must use -- to separate them from + the git-filter-branch options.

@@ -553,6 +553,15 @@ Thus you may instead want to use rm -f filename as the script.

git filter-branch --index-filter 'git rm --cached filename' HEAD

Now, you will get the rewritten history saved in HEAD.

+

To rewrite the repository to look as if foodir/ had been its project +root, and discard all other history:

+
+
+
git filter-branch --subdirectory-filter foodir -- --all
+
+

Thus you can, e.g., turn a library subdirectory into a repository of +its own. Note the -- that separates filter-branch options from +revision options, and the --all to rewrite all branches and tags.

To set a commit (which typically is at the tip of another history) to be the parent of the current initial commit, in order to paste the other history behind the current history:

@@ -665,7 +674,7 @@ and the git list <git@vger.kernel.org>

diff --git a/git-filter-branch.txt b/git-filter-branch.txt index a518ba607..b0e710d5f 100644 --- a/git-filter-branch.txt +++ b/git-filter-branch.txt @@ -13,7 +13,7 @@ SYNOPSIS [--msg-filter ] [--commit-filter ] [--tag-name-filter ] [--subdirectory-filter ] [--original ] [-d ] [-f | --force] - [...] + [--] [...] DESCRIPTION ----------- @@ -168,10 +168,10 @@ to other tags will be rewritten to point to the underlying commit. 'refs/original/', unless forced. ...:: - When options are given after the new branch name, they will - be passed to 'git-rev-list'. Only commits in the resulting - output will be filtered, although the filtered commits can still - reference parents which are outside of that set. + Arguments for 'git-rev-list'. All positive refs included by + these options are rewritten. You may also specify options + such as '--all', but you must use '--' to separate them from + the 'git-filter-branch' options. Examples @@ -196,6 +196,17 @@ git filter-branch --index-filter 'git rm --cached filename' HEAD Now, you will get the rewritten history saved in HEAD. +To rewrite the repository to look as if `foodir/` had been its project +root, and discard all other history: + +------------------------------------------------------- +git filter-branch --subdirectory-filter foodir -- --all +------------------------------------------------------- + +Thus you can, e.g., turn a library subdirectory into a repository of +its own. Note the `\--` that separates 'filter-branch' options from +revision options, and the `\--all` to rewrite all branches and tags. + To set a commit (which typically is at the tip of another history) to be the parent of the current initial commit, in order to paste the other history behind the current history: diff --git a/git-pull.html b/git-pull.html index c9c3fb5dc..c5f610578 100644 --- a/git-pull.html +++ b/git-pull.html @@ -639,7 +639,7 @@ unless you have read git-rebase(1) carefully.

The canonical format of a <refspec> parameter is - ?<src>:<dst>; that is, an optional plus , followed + +?<src>:<dst>; that is, an optional plus +, followed by the source ref, followed by a colon :, followed by the destination ref.

@@ -1149,7 +1149,7 @@ Junio C Hamano and the git-list <git@vger.kernel.org>.

diff --git a/git-push.html b/git-push.html index 844940f32..c4caddd09 100644 --- a/git-push.html +++ b/git-push.html @@ -350,8 +350,8 @@ documentation for git-receive-pack(1).

- The canonical format of each <refspec> parameter is - ?<src>:<dst>; that is, an optional plus , followed + The canonical format of a <refspec> parameter is + +?<src>:<dst>; that is, an optional plus +, followed by the source ref, followed by a colon :, followed by the destination ref.

@@ -818,7 +818,7 @@ by Linus Torvalds <torvalds@osdl.org>

diff --git a/git-push.txt b/git-push.txt index 050c3ddae..45c96435f 100644 --- a/git-push.txt +++ b/git-push.txt @@ -31,8 +31,8 @@ OPTIONS operation. See the section <> below. ...:: - The canonical format of each parameter is - `+?:`; that is, an optional plus `+`, followed + The canonical format of a parameter is + `+?:`; that is, an optional plus `{plus}`, followed by the source ref, followed by a colon `:`, followed by the destination ref. + diff --git a/git-rerere.html b/git-rerere.html index 95331b9ac..acbd5d8a5 100644 --- a/git-rerere.html +++ b/git-rerere.html @@ -418,14 +418,14 @@ One way to do it is to pull master into the topic branch:

The commits marked with * touch the same area in the same file; you need to resolve the conflicts when creating the commit -marked with +. Then you can test the result to make sure your +marked with +. Then you can test the result to make sure your work-in-progress still works with what is in the latest master.

After this test merge, there are two ways to continue your work on the topic. The easiest is to build on top of the test merge -commit , and when your work in the topic branch is finally +commit +, and when your work in the topic branch is finally ready, pull the topic branch into master, and/or ask the upstream to pull from you. By that time, however, the master or -the upstream might have been advanced since the test merge , +the upstream might have been advanced since the test merge +, in which case the final commit graph would look like this:

@@ -529,7 +529,7 @@ conflict.

diff --git a/git-rerere.txt b/git-rerere.txt index 89f321b41..64715c17d 100644 --- a/git-rerere.txt +++ b/git-rerere.txt @@ -90,15 +90,15 @@ One way to do it is to pull master into the topic branch: The commits marked with `*` touch the same area in the same file; you need to resolve the conflicts when creating the commit -marked with `+`. Then you can test the result to make sure your +marked with `{plus}`. Then you can test the result to make sure your work-in-progress still works with what is in the latest master. After this test merge, there are two ways to continue your work on the topic. The easiest is to build on top of the test merge -commit `+`, and when your work in the topic branch is finally +commit `{plus}`, and when your work in the topic branch is finally ready, pull the topic branch into master, and/or ask the upstream to pull from you. By that time, however, the master or -the upstream might have been advanced since the test merge `+`, +the upstream might have been advanced since the test merge `{plus}`, in which case the final commit graph would look like this: ------------ diff --git a/git-rm.html b/git-rm.html index 657ccfe49..44232cc58 100644 --- a/git-rm.html +++ b/git-rm.html @@ -320,7 +320,7 @@ git-rm(1) Manual Page

SYNOPSIS

-

git rm [-f] [-n] [-r] [--cached] [--ignore-unmatch] [--quiet] [--] <file>…

+

git rm [-f | --force] [-n] [-r] [--cached] [--ignore-unmatch] [--quiet] [--] <file>…

DESCRIPTION

@@ -356,6 +356,9 @@ allowing the file to be removed from just the index.

-f
+
+--force +

Override the up-to-date check. @@ -481,7 +484,7 @@ git rm -f git-*.sh

diff --git a/git-rm.txt b/git-rm.txt index 4d0c495bc..5afb1e742 100644 --- a/git-rm.txt +++ b/git-rm.txt @@ -7,7 +7,7 @@ git-rm - Remove files from the working tree and from the index SYNOPSIS -------- -'git rm' [-f] [-n] [-r] [--cached] [--ignore-unmatch] [--quiet] [--] ... +'git rm' [-f | --force] [-n] [-r] [--cached] [--ignore-unmatch] [--quiet] [--] ... DESCRIPTION ----------- @@ -36,6 +36,7 @@ OPTIONS but this requires the `-r` option to be explicitly given. -f:: +--force:: Override the up-to-date check. -n:: diff --git a/git-svn.html b/git-svn.html index 6c5212261..4fd22cc95 100644 --- a/git-svn.html +++ b/git-svn.html @@ -554,6 +554,23 @@ and have no uncommitted changes.

After committing, do not rebase or reset.

+
+--commit-url <URL> +
+
+

+ Commit to this SVN URL (the full path). This is intended to + allow existing git-svn repositories created with one transport + method (e.g. svn:// or http:// for anonymous read) to be + reused if a user is later given access to an alternate transport + method (e.g. svn+ssh:// or https://) for commit. +

+
+
+
Using this option for any other purpose (don't ask)
+is very strongly discouraged.
+
+
@@ -1219,7 +1236,7 @@ should be manually entered with a text-editor or using git-config.

< diff --git a/git-svn.txt b/git-svn.txt index 773ae9654..1e644ca6d 100644 --- a/git-svn.txt +++ b/git-svn.txt @@ -138,6 +138,15 @@ and have no uncommitted changes. + --no-rebase;; After committing, do not rebase or reset. +--commit-url ;; + Commit to this SVN URL (the full path). This is intended to + allow existing git-svn repositories created with one transport + method (e.g. `svn://` or `http://` for anonymous read) to be + reused if a user is later given access to an alternate transport + method (e.g. `svn+ssh://` or `https://`) for commit. + + Using this option for any other purpose (don't ask) + is very strongly discouraged. -- 'log':: diff --git a/pull-fetch-param.txt b/pull-fetch-param.txt index 00a8d2104..ebdd948cd 100644 --- a/pull-fetch-param.txt +++ b/pull-fetch-param.txt @@ -6,7 +6,7 @@ :: The canonical format of a parameter is - `+?:`; that is, an optional plus `+`, followed + `+?:`; that is, an optional plus `{plus}`, followed by the source ref, followed by a colon `:`, followed by the destination ref. + diff --git a/user-manual.html b/user-manual.html index b33e2e8a4..415e24281 100644 --- a/user-manual.html +++ b/user-manual.html @@ -1,4 +1,4 @@ -Git User's Manual (for version 1.5.3 or newer)

Git User's Manual (for version 1.5.3 or newer)

Table of Contents

Preface
1. Repositories and Branches
How to get a git repository
How to check out a different version of a project
Understanding History: Commits
Understanding history: commits, parents, and reachability
Understanding history: History diagrams
Understanding history: What is a branch?
Manipulating branches
Examining an old version without creating a new branch
Examining branches from a remote repository
Naming branches, tags, and other references
Updating a repository with git-fetch
Fetching branches from other repositories
2. Exploring git history
How to use bisect to find a regression
Naming commits
Creating tags
Browsing revisions
Generating diffs
Viewing old file versions
Examples
Counting the number of commits on a branch
Check whether two branches point at the same history
Find first tagged version including a given fix
Showing commits unique to a given branch
Creating a changelog and tarball for a software release
Finding commits referencing a file with given content
3. Developing with git
Telling git your name
Creating a new repository
How to make a commit
Creating good commit messages
Ignoring files
How to merge
Resolving a merge
Getting conflict-resolution help during a merge
Undoing a merge
Fast-forward merges
Fixing mistakes
Fixing a mistake with a new commit
Fixing a mistake by rewriting history
Checking out an old version of a file
Temporarily setting aside work in progress
Ensuring good performance
Ensuring reliability
Checking the repository for corruption
Recovering lost changes
4. Sharing development with others
Getting updates with git-pull
Submitting patches to a project
Importing patches to a project
Public git repositories
Setting up a public repository
Exporting a git repository via the git protocol
Exporting a git repository via http
Pushing changes to a public repository
What to do when a push fails
Setting up a shared repository
Allowing web browsing of a repository
Examples
Maintaining topic branches for a Linux subsystem maintainer
5. Rewriting history and maintaining patch series
Creating the perfect patch series
Keeping a patch series up to date using git-rebase
Rewriting a single commit
Reordering or selecting from a patch series
Other tools
Problems with rewriting history
Why bisecting merge commits can be harder than bisecting linear history
6. Advanced branch management
Fetching individual branches
git fetch and fast-forwards
Forcing git-fetch to do non-fast-forward updates
Configuring remote branches
7. Git concepts
The Object Database
Commit Object
Tree Object
Blob Object
Trust
Tag Object
How git stores objects efficiently: pack files
Dangling objects
Recovering from repository corruption
The index
8. Submodules
Pitfalls with submodules
9. Low-level git operations
Object access and manipulation
The Workflow
working directory -> index
index -> object database
object database -> index
index -> working directory
Tying it all together
Examining the data
Merging multiple trees
Merging multiple trees, continued
10. Hacking git
Object storage format
A birds-eye view of Git's source code
11. GIT Glossary
A. Git Quick Reference
Creating a new repository
Managing branches
Exploring history
Making changes
Merging
Sharing your changes
Repository maintenance
B. Notes and todo list for this manual

Preface

Git is a fast distributed revision control system.

This manual is designed to be readable by someone with basic UNIX +Git User's Manual (for version 1.5.3 or newer)

Git User's Manual (for version 1.5.3 or newer)

Table of Contents

Preface
1. Repositories and Branches
How to get a git repository
How to check out a different version of a project
Understanding History: Commits
Understanding history: commits, parents, and reachability
Understanding history: History diagrams
Understanding history: What is a branch?
Manipulating branches
Examining an old version without creating a new branch
Examining branches from a remote repository
Naming branches, tags, and other references
Updating a repository with git-fetch
Fetching branches from other repositories
2. Exploring git history
How to use bisect to find a regression
Naming commits
Creating tags
Browsing revisions
Generating diffs
Viewing old file versions
Examples
Counting the number of commits on a branch
Check whether two branches point at the same history
Find first tagged version including a given fix
Showing commits unique to a given branch
Creating a changelog and tarball for a software release
Finding commits referencing a file with given content
3. Developing with git
Telling git your name
Creating a new repository
How to make a commit
Creating good commit messages
Ignoring files
How to merge
Resolving a merge
Getting conflict-resolution help during a merge
Undoing a merge
Fast-forward merges
Fixing mistakes
Fixing a mistake with a new commit
Fixing a mistake by rewriting history
Checking out an old version of a file
Temporarily setting aside work in progress
Ensuring good performance
Ensuring reliability
Checking the repository for corruption
Recovering lost changes
4. Sharing development with others
Getting updates with git-pull
Submitting patches to a project
Importing patches to a project
Public git repositories
Setting up a public repository
Exporting a git repository via the git protocol
Exporting a git repository via http
Pushing changes to a public repository
What to do when a push fails
Setting up a shared repository
Allowing web browsing of a repository
Examples
Maintaining topic branches for a Linux subsystem maintainer
5. Rewriting history and maintaining patch series
Creating the perfect patch series
Keeping a patch series up to date using git-rebase
Rewriting a single commit
Reordering or selecting from a patch series
Other tools
Problems with rewriting history
Why bisecting merge commits can be harder than bisecting linear history
6. Advanced branch management
Fetching individual branches
git fetch and fast-forwards
Forcing git-fetch to do non-fast-forward updates
Configuring remote branches
7. Git concepts
The Object Database
Commit Object
Tree Object
Blob Object
Trust
Tag Object
How git stores objects efficiently: pack files
Dangling objects
Recovering from repository corruption
The index
8. Submodules
Pitfalls with submodules
9. Low-level git operations
Object access and manipulation
The Workflow
working directory -> index
index -> object database
object database -> index
index -> working directory
Tying it all together
Examining the data
Merging multiple trees
Merging multiple trees, continued
10. Hacking git
Object storage format
A birds-eye view of Git's source code
11. GIT Glossary
A. Git Quick Reference
Creating a new repository
Managing branches
Exploring history
Making changes
Merging
Sharing your changes
Repository maintenance
B. Notes and todo list for this manual

Preface

Git is a fast distributed revision control system.

This manual is designed to be readable by someone with basic UNIX command-line skills, but no previous knowledge of git.

Chapter 1, Repositories and Branches and Chapter 2, Exploring git history explain how to fetch and study a project using git—read these chapters to learn how to build and test a particular version of a software project, search for @@ -447,8 +447,8 @@ This typically includes files generated by a build process or temporary 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".

You can tell git to ignore certain files by creating a file called .gitignore +"git add ." practically useless, and they keep showing up in the output of +"git status".

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 any file named foo.txt.
foo.txt
diff --git a/user-manual.txt b/user-manual.txt index 43f4e392f..f42168994 100644 --- a/user-manual.txt +++ b/user-manual.txt @@ -1128,8 +1128,8 @@ This typically includes files generated by a build process or temporary 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`". +"`git add .`" practically useless, and they keep showing up in the output of +"`git status`". 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: