From: Junio C Hamano Date: Sat, 25 Aug 2007 03:54:27 +0000 (+0000) Subject: Autogenerated HTML docs for v1.5.3-rc6-23-g0058 X-Git-Url: http://git.tremily.us/?a=commitdiff_plain;h=a63874253759767733cadcdda3933ad2475e905a;p=git.git Autogenerated HTML docs for v1.5.3-rc6-23-g0058 --- diff --git a/config.txt b/config.txt index 462595cf8..903610fec 100644 --- a/config.txt +++ b/config.txt @@ -283,7 +283,7 @@ core.excludesfile:: core.editor:: Commands such as `commit` and `tag` that lets you edit - messages by lauching an editor uses the value of this + messages by launching an editor uses the value of this variable when it is set, and the environment variable `GIT_EDITOR` is not set. The order of preference is `GIT_EDITOR` environment, `core.editor`, `VISUAL` and @@ -465,11 +465,11 @@ rerere.enabled:: be encountered again. See gitlink:git-rerere[1]. gitcvs.enabled:: - Whether the cvs server interface is enabled for this repository. + Whether the CVS server interface is enabled for this repository. See gitlink:git-cvsserver[1]. gitcvs.logfile:: - Path to a log file where the cvs server interface well... logs + Path to a log file where the CVS server interface well... logs various stuff. See gitlink:git-cvsserver[1]. gitcvs.allbinary:: @@ -500,10 +500,10 @@ gitcvs.dbuser, gitcvs.dbpass:: 'gitcvs.dbuser' supports variable substitution (see gitlink:git-cvsserver[1] for details). -All gitcvs variables except for 'gitcvs.allbinary' can also specifed -as 'gitcvs..' (where 'access_method' is one -of "ext" and "pserver") to make them apply only for the given access -method. +All gitcvs variables except for 'gitcvs.allbinary' can also be +specified as 'gitcvs..' (where 'access_method' +is one of "ext" and "pserver") to make them apply only for the given +access method. http.sslVerify:: Whether to verify the SSL certificate when fetching or pushing @@ -615,7 +615,7 @@ pack.compression:: not set, defaults to -1. pack.deltaCacheSize:: - The maxium memory in bytes used for caching deltas in + The maximum memory in bytes used for caching deltas in gitlink:git-pack-objects[1]. A value of 0 means no limit. Defaults to 0. diff --git a/git-commit-tree.html b/git-commit-tree.html index 9ac457dc8..b00a54311 100644 --- a/git-commit-tree.html +++ b/git-commit-tree.html @@ -335,7 +335,7 @@ committer name and email and the commit time.

While parent object ids are provided on the command line, author and -commiter information is taken from the following environment variables, +committer information is taken from the following environment variables, if set:

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

diff --git a/git-commit-tree.txt b/git-commit-tree.txt index 6a328f497..a2537e179 100644 --- a/git-commit-tree.txt +++ b/git-commit-tree.txt @@ -52,7 +52,7 @@ A commit encapsulates: - committer name and email and the commit time. While parent object ids are provided on the command line, author and -commiter information is taken from the following environment variables, +committer information is taken from the following environment variables, if set: GIT_AUTHOR_NAME diff --git a/git-config.html b/git-config.html index a820b02d2..971299afe 100644 --- a/git-config.html +++ b/git-config.html @@ -502,7 +502,7 @@ rather than from all available files.

FILES

-

If not set explicitely with --file, there are three files where +

If not set explicitly with --file, there are three files where git-config will search for configuration options:

git/config::
@@ -1028,7 +1028,7 @@ core.editor

Commands such as commit and tag that lets you edit - messages by lauching an editor uses the value of this + messages by launching an editor uses the value of this variable when it is set, and the environment variable GIT_EDITOR is not set. The order of preference is GIT_EDITOR environment, core.editor, VISUAL and @@ -1351,7 +1351,7 @@ gitcvs.enabled

- Whether the cvs server interface is enabled for this repository. + Whether the CVS server interface is enabled for this repository. See git-cvsserver(1).

@@ -1360,7 +1360,7 @@ gitcvs.logfile

- Path to a log file where the cvs server interface well… logs + Path to a log file where the CVS server interface well… logs various stuff. See git-cvsserver(1).

@@ -1413,10 +1413,10 @@ gitcvs.dbuser, gitcvs.dbpass

-

All gitcvs variables except for gitcvs.allbinary can also specifed -as gitcvs.<access_method>.<varname> (where access_method is one -of "ext" and "pserver") to make them apply only for the given access -method.

+

All gitcvs variables except for gitcvs.allbinary can also be +specified as gitcvs.<access_method>.<varname> (where access_method +is one of "ext" and "pserver") to make them apply only for the given +access method.

http.sslVerify @@ -1637,7 +1637,7 @@ pack.deltaCacheSize

- The maxium memory in bytes used for caching deltas in + The maximum memory in bytes used for caching deltas in git-pack-objects(1). A value of 0 means no limit. Defaults to 0.

@@ -1879,7 +1879,7 @@ transfer.unpackLimit
diff --git a/git-config.txt b/git-config.txt index c3dffffe3..5b794f439 100644 --- a/git-config.txt +++ b/git-config.txt @@ -139,7 +139,7 @@ See also <>. FILES ----- -If not set explicitely with '--file', there are three files where +If not set explicitly with '--file', there are three files where git-config will search for configuration options: .git/config:: diff --git a/git-cvsexportcommit.html b/git-cvsexportcommit.html index 2a49bfd27..7efb4aca1 100644 --- a/git-cvsexportcommit.html +++ b/git-cvsexportcommit.html @@ -357,7 +357,7 @@ should the changeset be done against.

- Update affected files from cvs repository before attempting export. + Update affected files from CVS repository before attempting export.

@@ -412,7 +412,7 @@ $ git-cherry cvshead myhead | sed -n 's/^+ //p' | xargs -l1 git-cvsexportcommit
diff --git a/git-cvsexportcommit.txt b/git-cvsexportcommit.txt index 6c423e3a2..4c8d1e638 100644 --- a/git-cvsexportcommit.txt +++ b/git-cvsexportcommit.txt @@ -59,7 +59,7 @@ OPTIONS Useful for patch series and the like. -u:: - Update affected files from cvs repository before attempting export. + Update affected files from CVS repository before attempting export. -v:: Verbose. diff --git a/git-cvsserver.html b/git-cvsserver.html index 173f008c9..360cb34d2 100644 --- a/git-cvsserver.html +++ b/git-cvsserver.html @@ -386,7 +386,7 @@ looks like

No special setup is needed for SSH access, other than having GIT tools in the PATH. If you have clients that do not accept the CVS_SERVER environment variable, you can rename git-cvsserver to cvs.

-

Note: Newer cvs versions (>= 1.12.11) also support specifying +

Note: Newer CVS versions (>= 1.12.11) also support specifying CVS_SERVER directly in CVSROOT like

@@ -691,7 +691,7 @@ Martin Langhoff <martin@catalyst.net.nz>
diff --git a/git-cvsserver.txt b/git-cvsserver.txt index 60d0bcf0f..258a62f7e 100644 --- a/git-cvsserver.txt +++ b/git-cvsserver.txt @@ -102,7 +102,7 @@ No special setup is needed for SSH access, other than having GIT tools in the PATH. If you have clients that do not accept the CVS_SERVER environment variable, you can rename git-cvsserver to cvs. -Note: Newer cvs versions (>= 1.12.11) also support specifying +Note: Newer CVS versions (>= 1.12.11) also support specifying CVS_SERVER directly in CVSROOT like ------ diff --git a/git-fast-import.html b/git-fast-import.html index 8e50ca467..22f72bd5c 100644 --- a/git-fast-import.html +++ b/git-fast-import.html @@ -543,7 +543,7 @@ the frontend should let fast-import handle the parsing and conversion been well tested in the wild.

Frontends should prefer the raw format if the source material already uses UNIX-epoch format, can be coaxed to give dates in that -format, or its format is easiliy convertible to it, as there is no +format, or its format is easily convertible to it, as there is no ambiguity in parsing.

@@ -673,7 +673,7 @@ UTF-8, as fast-import does not permit other encodings to be specified.

and filedeleteall commands may be included to update the contents of the branch prior to creating the commit. These commands may be supplied in any order. -However it is recommended that a filedeleteall command preceed +However it is recommended that a filedeleteall command precede all filemodify, filecopy and filerename commands in the same commit, as filedeleteall wipes the branch clean (see below).

@@ -725,7 +725,7 @@ A mark reference, :<idnum>, where <idnum> is the m

The reason fast-import uses : to denote a mark reference is this character is not legal in a Git branch name. The leading : makes it easy -to distingush between the mark 42 (:42) and the branch 42 (42 +to distinguish between the mark 42 (:42) and the branch 42 (42 or refs/heads/42), or an abbreviated SHA-1 which happened to consist only of base-10 digits.

Marks must be declared (via mark) before they can be used.

@@ -830,7 +830,7 @@ slash /), may contain any byte other than LF, and must not start with double quote (").

If an LF or double quote must be encoded into <path> shell-style quoting should be used, e.g. "path/with\n and \" in it".

-

The value of <path> must be in canoncial form. That is it must not:

+

The value of <path> must be in canonical form. That is it must not:

  • @@ -1061,7 +1061,7 @@ Delimited format

    A delimiter string is used to mark the end of the data. fast-import will compute the length by searching for the delimiter. - This format is primarly useful for testing and is not + This format is primarily useful for testing and is not recommended for real data.

    @@ -1179,7 +1179,7 @@ files.

    to remove the dummy branch.

    Import Now, Repack Later

    As soon as fast-import completes the Git repository is completely valid -and ready for use. Typicallly this takes only a very short time, +and ready for use. Typically this takes only a very short time, even for considerably large projects (100,000+ commits).

    However repacking the repository is necessary to improve data locality and access performance. It can also take hours on extremely @@ -1237,8 +1237,8 @@ final packfile size (30-50% smaller can be quite typical).

    There are a number of factors which affect how much memory fast-import requires to perform an import. Like critical sections of core -Git, fast-import uses its own memory allocators to ammortize any overheads -associated with malloc. In practice fast-import tends to ammoritize any +Git, fast-import uses its own memory allocators to amortize any overheads +associated with malloc. In practice fast-import tends to amortize any malloc overheads to 0, due to its use of large block allocations.

    per object

    fast-import maintains an in-memory structure for every object written in @@ -1282,7 +1282,7 @@ increased or decreased on the command line with --active-branches=.

    per active tree

    Trees (aka directories) use just 12 bytes of memory on top of the memory required for their entries (see “per active file” below). -The cost of a tree is virtually 0, as its overhead ammortizes out +The cost of a tree is virtually 0, as its overhead amortizes out over the individual file entries.

    per active file entry

    Files (and pointers to subtrees) within active trees require 52 or 64 @@ -1309,7 +1309,7 @@ memory footprint (less than 2.7 MiB per active branch).

    diff --git a/git-fast-import.txt b/git-fast-import.txt index 0a019dd2e..d5119678b 100644 --- a/git-fast-import.txt +++ b/git-fast-import.txt @@ -241,7 +241,7 @@ been well tested in the wild. + Frontends should prefer the `raw` format if the source material already uses UNIX-epoch format, can be coaxed to give dates in that -format, or its format is easiliy convertible to it, as there is no +format, or its format is easily convertible to it, as there is no ambiguity in parsing. `now`:: @@ -343,7 +343,7 @@ Zero or more `filemodify`, `filedelete`, `filecopy`, `filerename` and `filedeleteall` commands may be included to update the contents of the branch prior to creating the commit. These commands may be supplied in any order. -However it is recommended that a `filedeleteall` command preceed +However it is recommended that a `filedeleteall` command precede all `filemodify`, `filecopy` and `filerename` commands in the same commit, as `filedeleteall` wipes the branch clean (see below). @@ -402,7 +402,7 @@ Here `` is any of the following: + The reason fast-import uses `:` to denote a mark reference is this character is not legal in a Git branch name. The leading `:` makes it easy -to distingush between the mark 42 (`:42`) and the branch 42 (`42` +to distinguish between the mark 42 (`:42`) and the branch 42 (`42` or `refs/heads/42`), or an abbreviated SHA-1 which happened to consist only of base-10 digits. + @@ -487,7 +487,7 @@ start with double quote (`"`). If an `LF` or double quote must be encoded into `` shell-style quoting should be used, e.g. `"path/with\n and \" in it"`. -The value of `` must be in canoncial form. That is it must not: +The value of `` must be in canonical form. That is it must not: * contain an empty directory component (e.g. `foo//bar` is invalid), * end with a directory separator (e.g. `foo/` is invalid), @@ -733,7 +733,7 @@ of the next line, even if `` did not end with an `LF`. Delimited format:: A delimiter string is used to mark the end of the data. fast-import will compute the length by searching for the delimiter. - This format is primarly useful for testing and is not + This format is primarily useful for testing and is not recommended for real data. + .... @@ -873,7 +873,7 @@ to remove the dummy branch. Import Now, Repack Later ~~~~~~~~~~~~~~~~~~~~~~~~ As soon as fast-import completes the Git repository is completely valid -and ready for use. Typicallly this takes only a very short time, +and ready for use. Typically this takes only a very short time, even for considerably large projects (100,000+ commits). However repacking the repository is necessary to improve data @@ -942,8 +942,8 @@ Memory Utilization ------------------ There are a number of factors which affect how much memory fast-import requires to perform an import. Like critical sections of core -Git, fast-import uses its own memory allocators to ammortize any overheads -associated with malloc. In practice fast-import tends to ammoritize any +Git, fast-import uses its own memory allocators to amortize any overheads +associated with malloc. In practice fast-import tends to amortize any malloc overheads to 0, due to its use of large block allocations. per object @@ -1000,7 +1000,7 @@ per active tree ~~~~~~~~~~~~~~~ Trees (aka directories) use just 12 bytes of memory on top of the memory required for their entries (see ``per active file'' below). -The cost of a tree is virtually 0, as its overhead ammortizes out +The cost of a tree is virtually 0, as its overhead amortizes out over the individual file entries. per active file entry diff --git a/git-fmt-merge-msg.html b/git-fmt-merge-msg.html index b84c86a15..e79841904 100644 --- a/git-fmt-merge-msg.html +++ b/git-fmt-merge-msg.html @@ -274,7 +274,7 @@ git-fmt-merge-msg(1) Manual Page
    git-fmt-merge-msg [--summary | --no-summary] <$GIT_DIR/FETCH_HEAD -git-fmt-merge-msg [--summary | --no-summray] -F <file>
    +git-fmt-merge-msg [--summary | --no-summary] -F <file>

DESCRIPTION

@@ -349,7 +349,7 @@ merge.summary
diff --git a/git-fmt-merge-msg.txt b/git-fmt-merge-msg.txt index 6affc5bb4..7088ed409 100644 --- a/git-fmt-merge-msg.txt +++ b/git-fmt-merge-msg.txt @@ -10,7 +10,7 @@ SYNOPSIS -------- [verse] git-fmt-merge-msg [--summary | --no-summary] <$GIT_DIR/FETCH_HEAD -git-fmt-merge-msg [--summary | --no-summray] -F +git-fmt-merge-msg [--summary | --no-summary] -F DESCRIPTION ----------- diff --git a/git-format-patch.html b/git-format-patch.html index eb04f9013..08b446c15 100644 --- a/git-format-patch.html +++ b/git-format-patch.html @@ -860,7 +860,7 @@ reference.

Instead of using .patch as the suffix for generated - filenames, use specifed suffix. A common alternative is + filenames, use specified suffix. A common alternative is --suffix=.txt.

Note that you would need to include the leading dot . if you @@ -949,7 +949,7 @@ git-format-patch -3

diff --git a/git-format-patch.txt b/git-format-patch.txt index 6cbcf937b..c514fdd93 100644 --- a/git-format-patch.txt +++ b/git-format-patch.txt @@ -118,7 +118,7 @@ include::diff-options.txt[] --suffix=.:: Instead of using `.patch` as the suffix for generated - filenames, use specifed suffix. A common alternative is + filenames, use specified suffix. A common alternative is `--suffix=.txt`. + Note that you would need to include the leading dot `.` if you diff --git a/git-gui.html b/git-gui.html index 5e768b1b4..56998f7f8 100644 --- a/git-gui.html +++ b/git-gui.html @@ -405,7 +405,7 @@ git gui browser maint

Other

git-gui is actually maintained as an independent project, but stable -versions are distributed as part of the Git suite for the convience +versions are distributed as part of the Git suite for the convenience of end users.

A git-gui development repository can be obtained from:

@@ -433,7 +433,7 @@ of end users.

diff --git a/git-gui.txt b/git-gui.txt index bd613b2fc..13252a1aa 100644 --- a/git-gui.txt +++ b/git-gui.txt @@ -89,7 +89,7 @@ See Also Other ----- git-gui is actually maintained as an independent project, but stable -versions are distributed as part of the Git suite for the convience +versions are distributed as part of the Git suite for the convenience of end users. A git-gui development repository can be obtained from: diff --git a/git-http-fetch.html b/git-http-fetch.html index 013c85ad8..2e69f7229 100644 --- a/git-http-fetch.html +++ b/git-http-fetch.html @@ -336,7 +336,7 @@ commit-id

- Instead of a commit id on the commandline (which is not expected in this + Instead of a commit id on the command line (which is not expected in this case), git-http-fetch expects lines on stdin in the format

@@ -369,7 +369,7 @@ commit-id
diff --git a/git-http-fetch.txt b/git-http-fetch.txt index 45e48453a..389c6edfb 100644 --- a/git-http-fetch.txt +++ b/git-http-fetch.txt @@ -34,7 +34,7 @@ commit-id:: the local end after the transfer is complete. --stdin:: - Instead of a commit id on the commandline (which is not expected in this + Instead of a commit id on the command line (which is not expected in this case), 'git-http-fetch' expects lines on stdin in the format ['\t'] diff --git a/git-local-fetch.html b/git-local-fetch.html index f8aef5a4a..741459caa 100644 --- a/git-local-fetch.html +++ b/git-local-fetch.html @@ -358,7 +358,7 @@ git-local-fetch(1) Manual Page

- Instead of a commit id on the commandline (which is not expected in this + Instead of a commit id on the command line (which is not expected in this case), git-local-fetch expects lines on stdin in the format

@@ -391,7 +391,7 @@ git-local-fetch(1) Manual Page
diff --git a/git-local-fetch.txt b/git-local-fetch.txt index 141b76768..e830deeff 100644 --- a/git-local-fetch.txt +++ b/git-local-fetch.txt @@ -44,7 +44,7 @@ OPTIONS the local end after the transfer is complete. --stdin:: - Instead of a commit id on the commandline (which is not expected in this + Instead of a commit id on the command line (which is not expected in this case), 'git-local-fetch' expects lines on stdin in the format ['\t'] diff --git a/git-name-rev.html b/git-name-rev.html index 948cb702a..b99606164 100644 --- a/git-name-rev.html +++ b/git-name-rev.html @@ -324,7 +324,7 @@ format parsable by git-rev-parse.

Instead of printing both the SHA-1 and the name, print only the name. If given with --tags the usual tag prefix of - "tags/" is also ommitted from the name, matching the output + "tags/" is also omitted from the name, matching the output of :git-describe(1) more closely. This option cannot be combined with --stdin.

@@ -364,7 +364,7 @@ not the context.

diff --git a/git-name-rev.txt b/git-name-rev.txt index 91eede120..306e1a495 100644 --- a/git-name-rev.txt +++ b/git-name-rev.txt @@ -37,7 +37,7 @@ OPTIONS --name-only:: Instead of printing both the SHA-1 and the name, print only the name. If given with --tags the usual tag prefix of - "tags/" is also ommitted from the name, matching the output + "tags/" is also omitted from the name, matching the output of gitlink::git-describe[1] more closely. This option cannot be combined with --stdin. diff --git a/git-receive-pack.html b/git-receive-pack.html index 1053aabf2..7cc334516 100644 --- a/git-receive-pack.html +++ b/git-receive-pack.html @@ -344,7 +344,7 @@ or it should match what is recorded in refname.

The hook should exit with non-zero status if it wants to disallow updating the named ref. Otherwise it should exit with zero.

Successful execution (a zero exit status) of this hook does not -ensure the ref will actully be updated, it is only a prerequisite. +ensure the ref will actually be updated, it is only a prerequisite. As such it is not a good idea to send notices (e.g. email) from this hook. Consider using the post-receive hook instead.

@@ -430,7 +430,7 @@ exec git-update-server-info diff --git a/git-receive-pack.txt b/git-receive-pack.txt index 4ef184047..2633d94c5 100644 --- a/git-receive-pack.txt +++ b/git-receive-pack.txt @@ -78,7 +78,7 @@ The hook should exit with non-zero status if it wants to disallow updating the named ref. Otherwise it should exit with zero. Successful execution (a zero exit status) of this hook does not -ensure the ref will actully be updated, it is only a prerequisite. +ensure the ref will actually be updated, it is only a prerequisite. As such it is not a good idea to send notices (e.g. email) from this hook. Consider using the post-receive hook instead. diff --git a/git-reflog.html b/git-reflog.html index 0cfdab8dd..aae9ca781 100644 --- a/git-reflog.html +++ b/git-reflog.html @@ -289,7 +289,7 @@ Entries older than expire time, or entries older than expire-unreachable time and are not reachable from the current tip, are removed from the reflog. This is typically not used directly by the end users — instead, see git-gc(1).

-

The subcommand "show" (which is also the default, in the absense of any +

The subcommand "show" (which is also the default, in the absence of any subcommands) will take all the normal log options, and show the log of HEAD, which will cover all recent actions, including branch switches. It is basically an alias for git log -g --abbrev-commit @@ -361,7 +361,7 @@ them.

diff --git a/git-reflog.txt b/git-reflog.txt index 29b7d9f5f..5180f6810 100644 --- a/git-reflog.txt +++ b/git-reflog.txt @@ -30,7 +30,7 @@ Entries older than `expire` time, or entries older than tip, are removed from the reflog. This is typically not used directly by the end users -- instead, see gitlink:git-gc[1]. -The subcommand "show" (which is also the default, in the absense of any +The subcommand "show" (which is also the default, in the absence of any subcommands) will take all the normal log options, and show the log of `HEAD`, which will cover all recent actions, including branch switches. It is basically an alias for 'git log -g --abbrev-commit diff --git a/git-repack.html b/git-repack.html index 11c606dc0..e5cbebf7d 100644 --- a/git-repack.html +++ b/git-repack.html @@ -277,7 +277,7 @@ git-repack(1) Manual Page

DESCRIPTION

This script is used to combine all objects that do not currently -reside in a "pack", into a pack. It can also be used to re-organise +reside in a "pack", into a pack. It can also be used to re-organize existing packs into a single, more efficient pack.

A pack is a collection of objects, individually compressed, with delta compression applied, stored in a single file, with an @@ -423,7 +423,7 @@ that way can try to use older git with it).

diff --git a/git-repack.txt b/git-repack.txt index 5283ef84a..12e2079a7 100644 --- a/git-repack.txt +++ b/git-repack.txt @@ -14,7 +14,7 @@ DESCRIPTION ----------- This script is used to combine all objects that do not currently -reside in a "pack", into a pack. It can also be used to re-organise +reside in a "pack", into a pack. It can also be used to re-organize existing packs into a single, more efficient pack. A pack is a collection of objects, individually compressed, with diff --git a/git-rev-list.html b/git-rev-list.html index d474c77c3..46863a4d3 100644 --- a/git-rev-list.html +++ b/git-rev-list.html @@ -405,7 +405,7 @@ e.g. "2 hours ago".

--date=iso (or --date=iso8601) shows timestamps in ISO 8601 format.

--date=rfc (or --date=rfc2822) shows timestamps in RFC 2822 format, often found in E-mail messages.

-

--date=short shows only date but not time, in YYYY-MM-DD fomat.

+

--date=short shows only date but not time, in YYYY-MM-DD format.

--date=default shows timestamps in the original timezone (either committer's or author's).

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

diff --git a/git-rev-list.txt b/git-rev-list.txt index a0c611e74..7cd0e8913 100644 --- a/git-rev-list.txt +++ b/git-rev-list.txt @@ -113,7 +113,7 @@ e.g. "2 hours ago". `--date=rfc` (or `--date=rfc2822`) shows timestamps in RFC 2822 format, often found in E-mail messages. + -`--date=short` shows only date but not time, in `YYYY-MM-DD` fomat. +`--date=short` shows only date but not time, in `YYYY-MM-DD` format. + `--date=default` shows timestamps in the original timezone (either committer's or author's). diff --git a/git-svn.html b/git-svn.html index 290eacd2d..84d13d8db 100644 --- a/git-svn.html +++ b/git-svn.html @@ -437,7 +437,7 @@ branches, tags directories).

This works similarly to svn update or git-pull except that it preserves linear history with git-rebase instead of -git-merge for ease of dcommit-ing with git-svn.

+git-merge for ease of dcommiting with git-svn.

This accepts all options that git-svn fetch and git-rebase accepts. However --fetch-all only fetches from the current [svn-remote], and not all [svn-remote] definitions.

@@ -1040,7 +1040,7 @@ listed below are allowed:

Keep in mind that the (asterisk) wildcard of the local ref (left of the :) *must be the farthest right path component; however the remote wildcard may be anywhere as long as it's own -independent path componet (surrounded by / or EOL). This +independent path component (surrounded by / or EOL). This type of configuration is not automatically created by init and should be manually entered with a text-editor or using git-config(1)

@@ -1059,7 +1059,7 @@ should be manually entered with a text-editor or using diff --git a/git-svn.txt b/git-svn.txt index 3e2a63b74..3420c5c95 100644 --- a/git-svn.txt +++ b/git-svn.txt @@ -99,7 +99,7 @@ COMMANDS This works similarly to 'svn update' or 'git-pull' except that it preserves linear history with 'git-rebase' instead of -'git-merge' for ease of dcommit-ing with git-svn. +'git-merge' for ease of dcommiting with git-svn. This accepts all options that 'git-svn fetch' and 'git-rebase' accepts. However '--fetch-all' only fetches from the current @@ -551,7 +551,7 @@ listed below are allowed: Keep in mind that the '*' (asterisk) wildcard of the local ref (left of the ':') *must* be the farthest right path component; however the remote wildcard may be anywhere as long as it's own -independent path componet (surrounded by '/' or EOL). This +independent path component (surrounded by '/' or EOL). This type of configuration is not automatically created by 'init' and should be manually entered with a text-editor or using gitlink:git-config[1] diff --git a/gitattributes.html b/gitattributes.html index 1a093eb3f..35a4820ea 100644 --- a/gitattributes.html +++ b/gitattributes.html @@ -546,7 +546,7 @@ want to appear as the hunk header, like this:

Note. A single level of backslashes are eaten by the configuration file parser, so you would need to double the backslashes; the pattern above picks a line that begins with a -backslash, and zero or more occurences of sub followed by +backslash, and zero or more occurrences of sub followed by section followed by open brace, to the end of line.

There are a few built-in patterns to make this easier, and tex is one of them, so you do not have to write the above in your @@ -658,7 +658,7 @@ abc -foo -bar

  • By examining t/.gitattributes (which is in the same - diretory as the path in question), git finds that the first + directory as the path in question), git finds that the first line matches. merge attribute is set. It also finds that the second line matches, and attributes foo and bar are unset. @@ -682,7 +682,7 @@ Finally it examines $GIT_DIR/info/attributes. This file

  • -

    As the result, the attributes assignement to t/abc becomes:

    +

    As the result, the attributes assignment to t/abc becomes:

    foo     set to true
    @@ -698,7 +698,7 @@ frotz   unspecified
    diff --git a/gitattributes.txt b/gitattributes.txt index 8b90a5b98..46f9d591a 100644 --- a/gitattributes.txt +++ b/gitattributes.txt @@ -285,7 +285,7 @@ want to appear as the hunk header, like this: Note. A single level of backslashes are eaten by the configuration file parser, so you would need to double the backslashes; the pattern above picks a line that begins with a -backslash, and zero or more occurences of `sub` followed by +backslash, and zero or more occurrences of `sub` followed by `section` followed by open brace, to the end of line. There are a few built-in patterns to make this easier, and `tex` @@ -394,7 +394,7 @@ abc -foo -bar the attributes given to path `t/abc` are computed as follows: 1. By examining `t/.gitattributes` (which is in the same - diretory as the path in question), git finds that the first + directory as the path in question), git finds that the first line matches. `merge` attribute is set. It also finds that the second line matches, and attributes `foo` and `bar` are unset. @@ -410,7 +410,7 @@ the attributes given to path `t/abc` are computed as follows: a match, and `foo` is set, `bar` is reverted to unspecified state, and `baz` is unset. -As the result, the attributes assignement to `t/abc` becomes: +As the result, the attributes assignment to `t/abc` becomes: ---------------------------------------------------------------- foo set to true diff --git a/hooks.html b/hooks.html index 4b3e56e65..28cd7d6da 100644 --- a/hooks.html +++ b/hooks.html @@ -418,7 +418,7 @@ arguments, but gets the same information as the hook does on its standard input.

    This hook does not affect the outcome of git-receive-pack, as it is called after the real work is done.

    -

    This supersedes the post-update hook in that it get's +

    This supersedes the post-update hook in that it gets both old and new values of all the refs in addition to their names.

    Both standard output and standard error output are forwarded to @@ -456,7 +456,7 @@ for the user.

    diff --git a/hooks.txt b/hooks.txt index 6836477ca..c39edc57c 100644 --- a/hooks.txt +++ b/hooks.txt @@ -176,7 +176,7 @@ hook does on its standard input. This hook does not affect the outcome of `git-receive-pack`, as it is called after the real work is done. -This supersedes the <> hook in that it get's +This supersedes the <> hook in that it gets both old and new values of all the refs in addition to their names. diff --git a/tutorial.html b/tutorial.html index bbf2d555b..dca03ad94 100644 --- a/tutorial.html +++ b/tutorial.html @@ -550,7 +550,7 @@ tracking branch
    , like this:

    $ git pull . remotes/bob/master

    Note that git pull always merges into the current branch, -regardless of what else is given on the commandline.

    +regardless of what else is given on the command line.

    Later, Bob can update his repo with Alice's latest changes using

    @@ -786,7 +786,7 @@ digressions that may be interesting at this point are:

    diff --git a/tutorial.txt b/tutorial.txt index bd9fbee99..fff1068c5 100644 --- a/tutorial.txt +++ b/tutorial.txt @@ -339,7 +339,7 @@ $ git pull . remotes/bob/master ------------------------------------- Note that git pull always merges into the current branch, -regardless of what else is given on the commandline. +regardless of what else is given on the command line. Later, Bob can update his repo with Alice's latest changes using diff --git a/user-manual.html b/user-manual.html index 0159872a7..d6f58d191 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 editing 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
    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
    Modifying a single commit
    Reordering or selecting from a patch series
    Other tools
    Problems with rewriting 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 internals
    The Object Database
    Blob Object
    Tree Object
    Commit Object
    Trust
    Tag Object
    The "index" aka "Current Directory Cache"
    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
    How git stores objects efficiently: pack files
    Dangling objects
    A birds-eye view of Git's source code
    8. 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 editing 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
    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
    Modifying a single commit
    Reordering or selecting from a patch series
    Other tools
    Problems with rewriting 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 internals
    The Object Database
    Blob Object
    Tree Object
    Commit Object
    Trust
    Tag Object
    The "index" aka "Current Directory Cache"
    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
    How git stores objects efficiently: pack files
    Dangling objects
    A birds-eye view of Git's source code
    8. 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 @@ -102,7 +102,7 @@ of development leading to that point.

    The best way to see how this works i command; running gitk now on a git repository and looking for merge commits will help understand how the git organizes history.

    In the following, we say that commit X is "reachable" from commit Y if commit X is an ancestor of commit Y. Equivalently, you could say -that Y is a descendent of X, or that there is a chain of parents +that Y is a descendant of X, or that there is a chain of parents leading from commit Y to commit X.

    Understanding history: History diagrams

    We will sometimes represent git history using diagrams like the one below. Commits are shown as "o", and the links between them with lines drawn with - / and \. Time goes left to right:

             o--o--o <-- Branch A
    @@ -768,7 +768,7 @@ $ git --bare update-server-info
    $ chmod a+x hooks/post-update

    (For an explanation of the last two lines, see git-update-server-info(1), and the documentation Hooks used by git.)

    Advertise the url of proj.git. Anybody else should then be able to -clone or pull from that url, for example with a commandline like:

    $ git clone http://yourserver.com/~you/proj.git

    (See also +clone or pull from that url, for example with a command line like:

    $ git clone http://yourserver.com/~you/proj.git

    (See also setup-git-server-over-http for a slightly more sophisticated setup using WebDAV which also allows pushing over http.)

    Pushing changes to a public repository

    Note that the two techniques outlined above (exporting via @@ -1046,7 +1046,7 @@ select diff hunks for inclusion in the index (by right-clicking on the diff hunk and choosing "Stage Hunk for Commit").

    Another technique is to use git-format-patch to create a series of patches, then reset the state to before the patches:

    $ git format-patch origin
    $ git reset --hard origin

    Then modify, reorder, or eliminate patches as preferred before applying -them again with git-am(1).

    Other tools

    There are numerous other tools, such as stgit, which exist for the +them again with git-am(1).

    Other tools

    There are numerous other tools, such as StGIT, which exist for the purpose of maintaining a patch series. These are outside of the scope of this manual.

    Problems with rewriting history

    The primary problem with rewriting the history of a branch has to do with merging. Suppose somebody fetches your branch and merges it into @@ -2174,8 +2174,8 @@ current branch:

    $ git pull git://example.com branch with your commits:

    $ git push ssh://example.com/project.git mybranch:theirbranch

    When remote and local branch are both named "test":

    $ git push ssh://example.com/project.git test

    Shortcut version for a frequently used remote repository:

    $ git remote add example ssh://example.com/project.git
    $ git push example test

    Repository maintenance

    Check for corruption:

    $ git fsck

    Recompress, remove unused cruft:

    $ git gc

    Appendix B. Notes and todo list for this manual

    This is a work in progress.

    The basic requirements: - It must be readable in order, from beginning to end, by - someone intelligent with a basic grasp of the unix - commandline, but without any special knowledge of git. If + someone intelligent with a basic grasp of the UNIX + command line, but without any special knowledge of git. If necessary, any other prerequisites should be specifically mentioned as they arise. - Whenever possible, section headings should clearly describe diff --git a/user-manual.txt b/user-manual.txt index f89952ad8..3d02198cc 100644 --- a/user-manual.txt +++ b/user-manual.txt @@ -4,7 +4,7 @@ ______________________________________________ Git is a fast distributed revision control system. -This manual is designed to be readable by someone with basic unix +This manual is designed to be readable by someone with basic UNIX command-line skills, but no previous knowledge of git. <> and <> explain how @@ -217,7 +217,7 @@ commits will help understand how the git organizes history. In the following, we say that commit X is "reachable" from commit Y if commit X is an ancestor of commit Y. Equivalently, you could say -that Y is a descendent of X, or that there is a chain of parents +that Y is a descendant of X, or that there is a chain of parents leading from commit Y to commit X. [[history-diagrams]] @@ -1911,7 +1911,7 @@ gitlink:git-update-server-info[1], and the documentation link:hooks.html[Hooks used by git].) Advertise the url of proj.git. Anybody else should then be able to -clone or pull from that url, for example with a commandline like: +clone or pull from that url, for example with a command line like: ------------------------------------------------- $ git clone http://yourserver.com/~you/proj.git @@ -2531,7 +2531,7 @@ them again with gitlink:git-am[1]. Other tools ----------- -There are numerous other tools, such as stgit, which exist for the +There are numerous other tools, such as StGIT, which exist for the purpose of maintaining a patch series. These are outside of the scope of this manual. @@ -3961,8 +3961,8 @@ This is a work in progress. The basic requirements: - It must be readable in order, from beginning to end, by - someone intelligent with a basic grasp of the unix - commandline, but without any special knowledge of git. If + someone intelligent with a basic grasp of the UNIX + command line, but without any special knowledge of git. If necessary, any other prerequisites should be specifically mentioned as they arise. - Whenever possible, section headings should clearly describe