From: Junio C Hamano
Date: Sun, 6 Jul 2008 05:20:31 +0000 (+0000)
Subject: Autogenerated HTML docs for v1.5.6.2-212-g08b5
X-Git-Url: http://git.tremily.us/?a=commitdiff_plain;h=ba4b9286c25f18c7ebbb809ee5732a7810377ab6;p=git.git
Autogenerated HTML docs for v1.5.6.2-212-g08b5
---
diff --git a/RelNotes-1.5.6.2.txt b/RelNotes-1.5.6.2.txt
index 02d5910d5..5902a85a7 100644
--- a/RelNotes-1.5.6.2.txt
+++ b/RelNotes-1.5.6.2.txt
@@ -11,21 +11,30 @@ Futureproof
Fixes since v1.5.6.1
--------------------
-* Optimization for a large import via "git-svn" introduced in v1.5.6 had a
- serious memory and temporary file leak, which made it unusable for
- moderately large import.
+* "git clone" from a remote that is named with url.insteadOf setting in
+ $HOME/.gitconfig did not work well.
-* "git-svn" mangled remote nickname used in the configuration file
- unnecessarily.
+* "git describe --long --tags" segfaulted when the described revision was
+ tagged with a lightweight tag.
* "git diff --check" did not report the result via its exit status
reliably.
+* When remote side used to have branch 'foo' and git-fetch finds that now
+ it has branch 'foo/bar', it refuses to lose the existing remote tracking
+ branch and its reflog. The error message has been improved to suggest
+ pruning the remote if the user wants to proceed and get the latest set
+ of branches from the remote, including such 'foo/bar'.
+
+* "git reset file" should mean the same thing as "git reset HEAD file",
+ but we required disambiguating -- even when "file" is not ambiguous.
+
* "git show" segfaulted when an annotated tag that points at another
annotated tag was given to it.
---
-exec >/var/tmp/1
-echo O=$(git describe maint)
-O=v1.5.6.1-13-g4f3dcc2
-git shortlog --no-merges $O..maint
+* Optimization for a large import via "git-svn" introduced in v1.5.6 had a
+ serious memory and temporary file leak, which made it unusable for
+ moderately large import.
+
+* "git-svn" mangled remote nickname used in the configuration file
+ unnecessarily.
diff --git a/cmds-mainporcelain.txt b/cmds-mainporcelain.txt
index 514de13d6..95ad966ab 100644
--- a/cmds-mainporcelain.txt
+++ b/cmds-mainporcelain.txt
@@ -86,7 +86,7 @@ linkgit:git-rm[1]::
Remove files from the working tree and from the index.
linkgit:git-shortlog[1]::
- Summarize 'git log' output.
+ Summarize 'git-log' output.
linkgit:git-show[1]::
Show various types of objects.
diff --git a/config.txt b/config.txt
index 561ff645f..a403d46c1 100644
--- a/config.txt
+++ b/config.txt
@@ -63,7 +63,7 @@ The values following the equals sign in variable assign are all either
a string, an integer, or a boolean. Boolean values may be given as yes/no,
0/1 or true/false. Case is not significant in boolean values, when
converting value to the canonical form using '--bool' type specifier;
-`git-config` will ensure that the output is "true" or "false".
+'git-config' will ensure that the output is "true" or "false".
String values may be entirely or partially enclosed in double quotes.
You need to enclose variable value in double quotes if you want to
@@ -118,8 +118,8 @@ core.fileMode::
See linkgit:git-update-index[1]. True by default.
core.quotepath::
- The commands that output paths (e.g. `ls-files`,
- `diff`), when not given the `-z` option, will quote
+ The commands that output paths (e.g. 'ls-files',
+ 'diff'), when not given the `-z` option, will quote
"unusual" characters in the pathname by enclosing the
pathname in a double-quote pair and with backslashes the
same way strings in C source code are quoted. If this
@@ -356,8 +356,8 @@ core.pager::
core.whitespace::
A comma separated list of common whitespace problems to
- notice. `git diff` will use `color.diff.whitespace` to
- highlight them, and `git apply --whitespace=error` will
+ notice. 'git-diff' will use `color.diff.whitespace` to
+ highlight them, and 'git-apply --whitespace=error' will
consider them as errors:
+
* `trailing-space` treats trailing whitespaces at the end of the line
@@ -396,11 +396,11 @@ it will be treated as a shell command. For example, defining
"gitk --all --not ORIG_HEAD".
apply.whitespace::
- Tells `git-apply` how to handle whitespaces, in the same way
+ Tells 'git-apply' how to handle whitespaces, in the same way
as the '--whitespace' option. See linkgit:git-apply[1].
branch.autosetupmerge::
- Tells `git-branch` and `git-checkout` to setup new branches
+ Tells 'git-branch' and 'git-checkout' to setup new branches
so that linkgit:git-pull[1] will appropriately merge from the
starting point branch. Note that even if this option is not set,
this behavior can be chosen per-branch using the `--track`
@@ -411,7 +411,7 @@ branch.autosetupmerge::
branch. This option defaults to true.
branch.autosetuprebase::
- When a new branch is created with `git-branch` or `git-checkout`
+ When a new branch is created with 'git-branch' or 'git-checkout'
that tracks another branch, this variable tells git to set
up pull to rebase instead of merge (see "branch..rebase").
When `never`, rebase is never automatically set to true.
@@ -426,20 +426,20 @@ branch.autosetuprebase::
This option defaults to never.
branch..remote::
- When in branch , it tells `git fetch` which remote to fetch.
- If this option is not given, `git fetch` defaults to remote "origin".
+ When in branch , it tells 'git-fetch' which remote to fetch.
+ If this option is not given, 'git-fetch' defaults to remote "origin".
branch..merge::
- When in branch , it tells `git fetch` the default
+ When in branch , it tells 'git-fetch' the default
refspec to be marked for merging in FETCH_HEAD. The value is
handled like the remote part of a refspec, and must match a
ref which is fetched from the remote given by
"branch..remote".
- The merge information is used by `git pull` (which at first calls
- `git fetch`) to lookup the default branch for merging. Without
- this option, `git pull` defaults to merge the first refspec fetched.
+ The merge information is used by 'git-pull' (which at first calls
+ 'git-fetch') to lookup the default branch for merging. Without
+ this option, 'git-pull' defaults to merge the first refspec fetched.
Specify multiple values to get an octopus merge.
- If you wish to setup `git pull` so that it merges into from
+ If you wish to setup 'git-pull' so that it merges into from
another branch in the local repository, you can point
branch..merge to the desired branch, and use the special setting
`.` (a period) for branch..remote.
@@ -508,12 +508,12 @@ color.diff.::
color.interactive::
When set to `always`, always use colors for interactive prompts
- and displays (such as those used by "git add --interactive").
+ and displays (such as those used by "git-add --interactive").
When false (or `never`), never. When set to `true` or `auto`, use
colors only when the output is to the terminal. Defaults to false.
color.interactive.::
- Use customized color for `git add --interactive`
+ Use customized color for 'git-add --interactive'
output. `` may be `prompt`, `header`, or `help`, for
three distinct types of normal output from interactive
programs. The values of these variables may be specified as
@@ -550,14 +550,14 @@ color.ui::
take precedence over this setting. Defaults to false.
diff.autorefreshindex::
- When using `git diff` to compare with work tree
+ When using 'git-diff' to compare with work tree
files, do not consider stat-only change as changed.
Instead, silently run `git update-index --refresh` to
update the cached stat information for paths whose
contents in the work tree match the contents in the
index. This option defaults to true. Note that this
- affects only `git diff` Porcelain, and not lower level
- `diff` commands, such as `git diff-files`.
+ affects only 'git-diff' Porcelain, and not lower level
+ 'diff' commands, such as 'git-diff-files'.
diff.external::
If this config variable is set, diff generation is not
@@ -568,7 +568,7 @@ diff.external::
diff.renameLimit::
The number of files to consider when performing the copy/rename
- detection; equivalent to the git diff option '-l'.
+ detection; equivalent to the 'git-diff' option '-l'.
diff.renames::
Tells git to detect renames. If set to any boolean value, it
@@ -608,7 +608,7 @@ format.pretty::
gc.aggressiveWindow::
The window size parameter used in the delta compression
- algorithm used by 'git gc --aggressive'. This defaults
+ algorithm used by 'git-gc --aggressive'. This defaults
to 10.
gc.auto::
@@ -625,37 +625,37 @@ gc.autopacklimit::
default value is 50. Setting this to 0 disables it.
gc.packrefs::
- `git gc` does not run `git pack-refs` in a bare repository by
+ 'git-gc' does not run `git pack-refs` in a bare repository by
default so that older dumb-transport clients can still fetch
- from the repository. Setting this to `true` lets `git
- gc` to run `git pack-refs`. Setting this to `false` tells
- `git gc` never to run `git pack-refs`. The default setting is
+ from the repository. Setting this to `true` lets 'git-gc'
+ to run `git pack-refs`. Setting this to `false` tells
+ 'git-gc' never to run `git pack-refs`. The default setting is
`notbare`. Enable it only when you know you do not have to
support such clients. The default setting will change to `true`
at some stage, and setting this to `false` will continue to
- prevent `git pack-refs` from being run from `git gc`.
+ prevent `git pack-refs` from being run from 'git-gc'.
gc.pruneexpire::
- When `git gc` is run, it will call `prune --expire 2.weeks.ago`.
+ When 'git-gc' is run, it will call 'prune --expire 2.weeks.ago'.
Override the grace period with this config variable.
gc.reflogexpire::
- `git reflog expire` removes reflog entries older than
+ 'git-reflog expire' removes reflog entries older than
this time; defaults to 90 days.
gc.reflogexpireunreachable::
- `git reflog expire` removes reflog entries older than
+ 'git-reflog expire' removes reflog entries older than
this time and are not reachable from the current tip;
defaults to 30 days.
gc.rerereresolved::
Records of conflicted merge you resolved earlier are
- kept for this many days when `git rerere gc` is run.
+ kept for this many days when 'git-rerere gc' is run.
The default is 60 days. See linkgit:git-rerere[1].
gc.rerereunresolved::
Records of conflicted merge you have not resolved are
- kept for this many days when `git rerere gc` is run.
+ kept for this many days when 'git-rerere gc' is run.
The default is 15 days. See linkgit:git-rerere[1].
rerere.enabled::
@@ -821,7 +821,7 @@ i18n.commitEncoding::
i18n.logOutputEncoding::
Character encoding the commit messages are converted to when
- running `git-log` and friends.
+ running 'git-log' and friends.
instaweb.browser::
Specify the program that will be used to browse your working
@@ -844,7 +844,7 @@ instaweb.port::
log.date::
Set default date-time mode for the log command. Setting log.date
- value is similar to using git log's --date option. The value is one of
+ value is similar to using 'git-log'\'s --date option. The value is one of the
following alternatives: {relative,local,default,iso,rfc,short}.
See linkgit:git-log[1].
diff --git a/fetch-options.txt b/fetch-options.txt
index 85c87180d..d313795fd 100644
--- a/fetch-options.txt
+++ b/fetch-options.txt
@@ -21,7 +21,7 @@
-f::
--force::
- When `git-fetch` is used with `:`
+ When 'git-fetch' is used with `:`
refspec, it refuses to update the local branch
`` unless the remote branch `` it
fetches is a descendant of ``. This option
@@ -53,10 +53,10 @@ endif::git-pull[]
-u::
--update-head-ok::
- By default `git-fetch` refuses to update the head which
+ By default 'git-fetch' refuses to update the head which
corresponds to the current branch. This flag disables the
- check. This is purely for the internal use for `git-pull`
- to communicate with `git-fetch`, and unless you are
+ check. This is purely for the internal use for 'git-pull'
+ to communicate with 'git-fetch', and unless you are
implementing your own Porcelain you are not supposed to
use it.
diff --git a/git-am.html b/git-am.html
index 830ba2789..7fcfa1333 100644
--- a/git-am.html
+++ b/git-am.html
@@ -3,7 +3,7 @@
-
+
git-am(1)
@@ -279,15 +327,15 @@ git-am(1) Manual Page
<mbox>|<Maildir>…
git am [--skip | --resolved]
-DESCRIPTION
+DESCRIPTION
-
Splits mail messages in a mailbox into commit log message,
+
Splits mail messages in a mailbox into commit log message,
authorship information and patches, and applies them to the
-current branch.
+current branch.
-OPTIONS
+OPTIONS
-
+
<mbox>|<Maildir>…
@@ -318,7 +366,7 @@ current branch.
- Pass -k flag to git-mailinfo (see git-mailinfo(1) ).
+ Pass -k flag to git-mailinfo (see git-mailinfo(1) ).
@@ -329,21 +377,21 @@ current branch.
- Pass -u flag to git-mailinfo (see git-mailinfo(1) ).
+ Pass -u flag to git-mailinfo (see git-mailinfo(1) ).
The proposed commit log message taken from the e-mail
is re-coded into UTF-8 encoding (configuration variable
i18n.commitencoding can be used to specify project's
preferred encoding if it is not UTF-8).
-This was optional in prior versions of git, but now it is the
-default. You could use --no-utf8 to override this.
+This was optional in prior versions of git, but now it is the
+default. You could use --no-utf8 to override this.
--no-utf8
- Pass -n flag to git-mailinfo (see
+ Pass -n flag to git-mailinfo (see
git-mailinfo(1) ).
@@ -369,7 +417,7 @@ default. You could use --no-utf8 to override this.
- Pass --allow-binary-replacement flag to git-apply
+ Pass --allow-binary-replacement flag to git-apply
(see git-apply(1) ).
@@ -378,7 +426,7 @@ default. You could use --no-utf8 to override this.
- This flag is passed to the git-apply (see git-apply(1) )
+ This flag is passed to the git-apply (see git-apply(1) )
program that applies
the patch.
@@ -391,7 +439,7 @@ default. You could use --no-utf8 to override this.
- These flags are passed to the git-apply (see git-apply(1) )
+ These flags are passed to the git-apply (see git-apply(1) )
program that applies
the patch.
@@ -441,30 +489,30 @@ default. You could use --no-utf8 to override this.
to the screen before exiting. This overrides the
standard message informing you to use --resolved
or --skip to handle the failure. This is solely
- for internal use between git-rebase and git-am .
+ for internal use between git-rebase and git-am .
-
+
-DISCUSSION
+DISCUSSION
-
The commit author name is taken from the "From: " line of the
+
The commit author name is taken from the "From: " line of the
message, and commit author time is taken from the "Date: " line
of the message. The "Subject: " line is used as the title of
the commit, after stripping common prefix "[PATCH <anything>]".
It is supposed to describe what the commit is about concisely as
-a one line text.
-
The body of the message (iow, after a blank line that terminates
+a one line text.
+
The body of the message (iow, after a blank line that terminates
RFC2822 headers) can begin with "Subject: " and "From: " lines
that are different from those of the mail header, to override
-the values of these fields.
-
The commit message is formed by the title taken from the
+the values of these fields.
+
The commit message is formed by the title taken from the
"Subject: ", a blank line and the body of the message up to
where the patch begins. Excess whitespaces at the end of the
-lines are automatically stripped.
-
The patch is expected to be inline, directly following the
-message. Any line that is of form:
-
+lines are automatically stripped.
+
The patch is expected to be inline, directly following the
+message. Any line that is of form:
+
three-dashes and end-of-line, or
@@ -480,13 +528,13 @@ a line that begins with "diff -", or
a line that begins with "Index: "
-
-
is taken as the beginning of a patch, and the commit log message
-is terminated before the first occurrence of such a line.
-
When initially invoking it, you give it names of the mailboxes
+
+
is taken as the beginning of a patch, and the commit log message
+is terminated before the first occurrence of such a line.
+
When initially invoking it, you give it names of the mailboxes
to crunch. Upon seeing the first patch that does not apply, it
-aborts in the middle,. You can recover from this in one of two ways:
-
+aborts in the middle,. You can recover from this in one of two ways:
+
skip the current patch by re-running the command with --skip
@@ -500,31 +548,31 @@ hand resolve the conflict in the working directory, and update
have produced. Then run the command with --resolved option.
-
-
The command refuses to process new mailboxes while .dotest
+
+
The command refuses to process new mailboxes while .dotest
directory exists, so if you decide to start over from scratch,
run rm -f -r .dotest before running the command with mailbox
-names.
+names.
-SEE ALSO
+SEE ALSO
-Author
+Author
-
Written by Junio C Hamano <junkio@cox.net>
+
Written by Junio C Hamano <junkio@cox.net>
-Documentation
+Documentation
-
Documentation by Petr Baudis, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
Documentation by Petr Baudis, Junio C Hamano and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-am.txt b/git-am.txt
index 1296b9117..3863eebce 100644
--- a/git-am.txt
+++ b/git-am.txt
@@ -35,11 +35,11 @@ OPTIONS
-k::
--keep::
- Pass `-k` flag to `git-mailinfo` (see linkgit:git-mailinfo[1]).
+ Pass `-k` flag to 'git-mailinfo' (see linkgit:git-mailinfo[1]).
-u::
--utf8::
- Pass `-u` flag to `git-mailinfo` (see linkgit:git-mailinfo[1]).
+ Pass `-u` flag to 'git-mailinfo' (see linkgit:git-mailinfo[1]).
The proposed commit log message taken from the e-mail
is re-coded into UTF-8 encoding (configuration variable
`i18n.commitencoding` can be used to specify project's
@@ -49,7 +49,7 @@ This was optional in prior versions of git, but now it is the
default. You could use `--no-utf8` to override this.
--no-utf8::
- Pass `-n` flag to `git-mailinfo` (see
+ Pass `-n` flag to 'git-mailinfo' (see
linkgit:git-mailinfo[1]).
-3::
@@ -61,17 +61,17 @@ default. You could use `--no-utf8` to override this.
-b::
--binary::
- Pass `--allow-binary-replacement` flag to `git-apply`
+ Pass `--allow-binary-replacement` flag to 'git-apply'
(see linkgit:git-apply[1]).
--whitespace=::
- This flag is passed to the `git-apply` (see linkgit:git-apply[1])
+ This flag is passed to the 'git-apply' (see linkgit:git-apply[1])
program that applies
the patch.
-C::
-p::
- These flags are passed to the `git-apply` (see linkgit:git-apply[1])
+ These flags are passed to the 'git-apply' (see linkgit:git-apply[1])
program that applies
the patch.
@@ -97,7 +97,7 @@ default. You could use `--no-utf8` to override this.
to the screen before exiting. This overrides the
standard message informing you to use `--resolved`
or `--skip` to handle the failure. This is solely
- for internal use between `git-rebase` and `git-am`.
+ for internal use between 'git-rebase' and 'git-am'.
DISCUSSION
----------
diff --git a/git-apply.html b/git-apply.html
index 728322578..13ba3221b 100644
--- a/git-apply.html
+++ b/git-apply.html
@@ -3,7 +3,7 @@
-
+
git-apply(1)
@@ -280,14 +328,14 @@ git-apply(1) Manual Page
[--whitespace=<nowarn|warn|fix|error|error-all>]
[--exclude=PATH] [--verbose] [<patch>…]
-DESCRIPTION
+DESCRIPTION
-
Reads supplied diff output and applies it on a git index file
-and a work tree.
+
Reads supplied diff output and applies it on a git index file
+and a work tree.
-OPTIONS
+OPTIONS
-
+
<patch>…
@@ -368,14 +416,14 @@ and a work tree.
- Newer git-diff output has embedded index information
+ Newer git-diff output has embedded index information
for each blob to help identify the original version that
the patch applies to. When this flag is given, and if
the original versions of the blobs is available locally,
builds a temporary index containing those blobs.
-When a pure mode change is encountered (which has no index information),
-the information is read from the current index instead.
+When a pure mode change is encountered (which has no index information),
+the information is read from the current index instead.
-R
@@ -393,7 +441,7 @@ the information is read from the current index instead.
- For atomicity, git-apply by default fails the whole patch and
+ For atomicity, git-apply by default fails the whole patch and
does not touch the working tree when some of the hunks
do not apply. This option makes it apply
the parts of the patch that are applicable, and leave the
@@ -437,14 +485,14 @@ the information is read from the current index instead.
- By default, git-apply expects that the patch being
+ By default, git-apply expects that the patch being
applied is a unified diff with at least one line of context.
This provides good safety measures, but breaks down when
applying a diff generated with --unified=0. To bypass these
checks use --unidiff-zero .
-Note, for the reasons stated above usage of context-free patches are
-discouraged.
+Note, for the reasons stated above usage of context-free patches are
+discouraged.
--apply
@@ -452,7 +500,7 @@ discouraged.
If you use any of the options marked "Turns off
- apply " above, git-apply reads and outputs the
+ apply " above, git-apply reads and outputs the
information you asked without actually applying the
patch. Give this flag after those flags to also apply
the patch.
@@ -465,7 +513,7 @@ discouraged.
When applying a patch, ignore additions made by the
patch. This can be used to extract the common part between
- two files by first running diff on them and applying
+ two files by first running diff on them and applying
the result with this option, which would apply the
deletion part but not addition part.
@@ -507,12 +555,12 @@ discouraged.
by a tab character inside the initial indent of the line are
considered whitespace errors.
-By default, the command outputs warning messages but applies the patch.
+
By default, the command outputs warning messages but applies the patch.
When git-apply is used for statistics and not applying a
-patch, it defaults to `nowarn .
-
You can use different <action> to control this
-behavior:
-
+patch, it defaults to `nowarn.
+You can use different <action> to control this
+behavior:
+
--inaccurate-eof
- Under certain circumstances, some versions of diff do not correctly
+ Under certain circumstances, some versions of diff do not correctly
detect a missing new-line at the end of the file. As a result, patches
- created by such diff programs do not record incomplete lines
+ created by such diff programs do not record incomplete lines
correctly. This option adds support for applying such patches by
working around this bug.
@@ -580,11 +628,11 @@ behavior:
adjusting the hunk headers appropriately).
-
+
-Configuration
+Configuration
-
+
apply.whitespace
@@ -594,36 +642,36 @@ apply.whitespace
line, this configuration item is used as the default.
-
+
-Submodules
+Submodules
-
If the patch contains any changes to submodules then git-apply
-treats these changes as follows.
-
If --index is specified (explicitly or implicitly), then the submodule
+
If the patch contains any changes to submodules then git-apply
+treats these changes as follows.
+
If --index is specified (explicitly or implicitly), then the submodule
commits must match the index exactly for the patch to apply. If any
of the submodules are checked-out, then these check-outs are completely
ignored, i.e., they are not required to be up-to-date or clean and they
-are not updated.
-
If --index is not specified, then the submodule commits in the patch
+are not updated.
+
If --index is not specified, then the submodule commits in the patch
are ignored and only the absence of presence of the corresponding
-subdirectory is checked and (if possible) updated.
+subdirectory is checked and (if possible) updated.
-Author
+Author
-
Written by Linus Torvalds <torvalds@osdl.org>
+
Written by Linus Torvalds <torvalds@osdl.org>
-Documentation
+Documentation
-
Documentation by Junio C Hamano
+
Documentation by Junio C Hamano
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-apply.txt b/git-apply.txt
index 70d19f63e..e9f724b2f 100644
--- a/git-apply.txt
+++ b/git-apply.txt
@@ -18,7 +18,7 @@ SYNOPSIS
DESCRIPTION
-----------
-Reads supplied diff output and applies it on a git index file
+Reads supplied 'diff' output and applies it on a git index file
and a work tree.
OPTIONS
@@ -64,7 +64,7 @@ OPTIONS
without using the working tree. This implies '--index'.
--build-fake-ancestor ::
- Newer `git-diff` output has embedded 'index information'
+ Newer 'git-diff' output has embedded 'index information'
for each blob to help identify the original version that
the patch applies to. When this flag is given, and if
the original versions of the blobs is available locally,
@@ -78,7 +78,7 @@ the information is read from the current index instead.
Apply the patch in reverse.
--reject::
- For atomicity, `git-apply` by default fails the whole patch and
+ For atomicity, 'git-apply' by default fails the whole patch and
does not touch the working tree when some of the hunks
do not apply. This option makes it apply
the parts of the patch that are applicable, and leave the
@@ -102,7 +102,7 @@ the information is read from the current index instead.
ever ignored.
--unidiff-zero::
- By default, `git-apply` expects that the patch being
+ By default, 'git-apply' expects that the patch being
applied is a unified diff with at least one line of context.
This provides good safety measures, but breaks down when
applying a diff generated with --unified=0. To bypass these
@@ -113,7 +113,7 @@ discouraged.
--apply::
If you use any of the options marked "Turns off
- 'apply'" above, `git-apply` reads and outputs the
+ 'apply'" above, 'git-apply' reads and outputs the
information you asked without actually applying the
patch. Give this flag after those flags to also apply
the patch.
@@ -121,7 +121,7 @@ discouraged.
--no-add::
When applying a patch, ignore additions made by the
patch. This can be used to extract the common part between
- two files by first running `diff` on them and applying
+ two files by first running 'diff' on them and applying
the result with this option, which would apply the
deletion part but not addition part.
@@ -165,9 +165,9 @@ behavior:
* `error-all` is similar to `error` but shows all errors.
--inaccurate-eof::
- Under certain circumstances, some versions of diff do not correctly
+ Under certain circumstances, some versions of 'diff' do not correctly
detect a missing new-line at the end of the file. As a result, patches
- created by such diff programs do not record incomplete lines
+ created by such 'diff' programs do not record incomplete lines
correctly. This option adds support for applying such patches by
working around this bug.
@@ -191,7 +191,7 @@ apply.whitespace::
Submodules
----------
-If the patch contains any changes to submodules then `git-apply`
+If the patch contains any changes to submodules then 'git-apply'
treats these changes as follows.
If --index is specified (explicitly or implicitly), then the submodule
diff --git a/git-archimport.html b/git-archimport.html
index d2f8c36b0..67315b90c 100644
--- a/git-archimport.html
+++ b/git-archimport.html
@@ -3,7 +3,7 @@
-
+
git-archimport(1)
@@ -276,53 +324,53 @@ git-archimport(1) Manual Page
git archimport [-h] [-v] [-o] [-a] [-f] [-T] [-D depth] [-t tempdir]
<archive/branch>[:<git-branch>] …
-DESCRIPTION
+DESCRIPTION
-
Imports a project from one or more Arch repositories. It will follow branches
+
Imports a project from one or more Arch repositories. It will follow branches
and repositories within the namespaces defined by the <archive/branch>
parameters supplied. If it cannot find the remote branch a merge comes from
it will just import it as a regular commit. If it can find it, it will mark it
-as a merge whenever possible (see discussion below).
-
The script expects you to provide the key roots where it can start the import
+as a merge whenever possible (see discussion below).
+
The script expects you to provide the key roots where it can start the import
from an initial import or tag type of Arch commit. It will follow and
-import new branches within the provided roots.
-
It expects to be dealing with one project only. If it sees
+import new branches within the provided roots.
+
It expects to be dealing with one project only. If it sees
branches that have different roots, it will refuse to run. In that case,
edit your <archive/branch> parameters to define clearly the scope of the
-import.
-
git-archimport uses tla extensively in the background to access the
+import.
+
git-archimport uses tla extensively in the background to access the
Arch repository.
Make sure you have a recent version of tla available in the path. tla must
-know about the repositories you pass to git-archimport .
-
For the initial import, git-archimport expects to find itself in an empty
+know about the repositories you pass to git-archimport .
+
For the initial import, git-archimport expects to find itself in an empty
directory. To follow the development of a project that uses Arch, rerun
-git-archimport with the same parameters as the initial import to perform
-incremental imports.
-
While git-archimport will try to create sensible branch names for the
+git-archimport with the same parameters as the initial import to perform
+incremental imports.
+
While git-archimport will try to create sensible branch names for the
archives that it imports, it is also possible to specify git branch names
manually. To do so, write a git branch name after each <archive/branch>
parameter, separated by a colon. This way, you can shorten the Arch
branch names and convert Arch jargon to git jargon, for example mapping a
-"PROJECT--devo--VERSION" branch to "master".
-
Associating multiple Arch branches to one git branch is possible; the
+"PROJECT--devo--VERSION" branch to "master".
+
Associating multiple Arch branches to one git branch is possible; the
result will make the most sense only if no commits are made to the first
branch, after the second branch is created. Still, this is useful to
-convert Arch repositories that had been rotated periodically.
+convert Arch repositories that had been rotated periodically.
-MERGES
+MERGES
-
Patch merge data from Arch is used to mark merges in git as well. git
+
Patch merge data from Arch is used to mark merges in git as well. git
does not care much about tracking patches, and only considers a merge when a
branch incorporates all the commits since the point they forked. The end result
is that git will have a good idea of how far branches have diverged. So the
-import process does lose some patch-trading metadata.
-
Fortunately, when you try and merge branches imported from Arch,
+import process does lose some patch-trading metadata.
+
Fortunately, when you try and merge branches imported from Arch,
git will find a good merge base, and it has a good chance of identifying
-patches that have been traded out-of-sequence between the branches.
+patches that have been traded out-of-sequence between the branches.
-OPTIONS
+OPTIONS
-
+
-h
@@ -364,7 +412,7 @@ patches that have been traded out-of-sequence between the branches.
Use this for compatibility with old-style branch names used by
- earlier versions of git-archimport . Old-style branch names
+ earlier versions of git-archimport . Old-style branch names
were category--branch, whereas new-style branch names are
archive,category--branch--version. In both cases, names given
on the command-line will override the automatically-generated
@@ -406,23 +454,23 @@ patches that have been traded out-of-sequence between the branches.
Archive/branch identifier in a format that tla log understands.
-
+
-Author
+Author
-
Written by Martin Langhoff <martin@catalyst.net.nz>.
+
Written by Martin Langhoff <martin@catalyst.net.nz>.
-Documentation
+Documentation
-
Documentation by Junio C Hamano, Martin Langhoff and the git-list <git@vger.kernel.org>.
+
Documentation by Junio C Hamano, Martin Langhoff and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-archimport.txt b/git-archimport.txt
index f089debaa..c7a6e3ec0 100644
--- a/git-archimport.txt
+++ b/git-archimport.txt
@@ -29,17 +29,17 @@ branches that have different roots, it will refuse to run. In that case,
edit your parameters to define clearly the scope of the
import.
-`git-archimport` uses `tla` extensively in the background to access the
+'git-archimport' uses `tla` extensively in the background to access the
Arch repository.
Make sure you have a recent version of `tla` available in the path. `tla` must
-know about the repositories you pass to `git-archimport`.
+know about the repositories you pass to 'git-archimport'.
-For the initial import, `git-archimport` expects to find itself in an empty
+For the initial import, 'git-archimport' expects to find itself in an empty
directory. To follow the development of a project that uses Arch, rerun
-`git-archimport` with the same parameters as the initial import to perform
+'git-archimport' with the same parameters as the initial import to perform
incremental imports.
-While `git-archimport` will try to create sensible branch names for the
+While 'git-archimport' will try to create sensible branch names for the
archives that it imports, it is also possible to specify git branch names
manually. To do so, write a git branch name after each
parameter, separated by a colon. This way, you can shorten the Arch
@@ -84,7 +84,7 @@ OPTIONS
-o::
Use this for compatibility with old-style branch names used by
- earlier versions of `git-archimport`. Old-style branch names
+ earlier versions of 'git-archimport'. Old-style branch names
were category--branch, whereas new-style branch names are
archive,category--branch--version. In both cases, names given
on the command-line will override the automatically-generated
diff --git a/git-archive.html b/git-archive.html
index b9549703e..ed183dd7b 100644
--- a/git-archive.html
+++ b/git-archive.html
@@ -3,7 +3,7 @@
-
+
git-archive(1)
@@ -277,24 +325,24 @@ git-archive(1) Manual Page
[--remote=<repo> [--exec=<git-upload-archive>]] <tree-ish>
[path…]
-DESCRIPTION
+DESCRIPTION
-
Creates an archive of the specified format containing the tree
+
Creates an archive of the specified format containing the tree
structure for the named tree, and writes it out to the standard
output. If <prefix> is specified it is
-prepended to the filenames in the archive.
-
git-archive behaves differently when given a tree ID versus when
+prepended to the filenames in the archive.
+
git-archive behaves differently when given a tree ID versus when
given a commit ID or tag ID. In the first case the current time is
used as modification time of each file in the archive. In the latter
case the commit time as recorded in the referenced commit object is
used instead. Additionally the commit ID is stored in a global
extended pax header if the tar format is used; it can be extracted
-using git-get-tar-commit-id . In ZIP files it is stored as a file
-comment.
+using
git-get-tar-commit-id . In ZIP files it is stored as a file
+comment.
-OPTIONS
+OPTIONS
-
+
--format=<fmt>
@@ -358,7 +406,7 @@ comment.
Used with --remote to specify the path to the
- git-upload-archive on the remote side.
+ git-upload-archive on the remote side.
@@ -378,12 +426,12 @@ path
archive, otherwise include all files and subdirectories.
-
+
-BACKEND EXTRA OPTIONS
+
-
zip
-
+zip
+
-0
@@ -401,11 +449,11 @@ path
number from 1 to 9 to adjust compression speed and ratio.
-
+
-CONFIGURATION
+CONFIGURATION
-
+
tar.umask
@@ -418,11 +466,11 @@ tar.umask
details.
-
+
-EXAMPLES
+EXAMPLES
-
+
git archive --format=tar --prefix=junk/ HEAD | (cd /var/tmp/ && tar xf -)
@@ -459,23 +507,23 @@ git archive --format=zip --prefix=git-docs/ HEAD:Documentation/ > git-1.4.0-d
into git-1.4.0-docs.zip , with the prefix git-docs/ .
-
+
-Author
+Author
-
Written by Franck Bui-Huu and Rene Scharfe.
+
Written by Franck Bui-Huu and Rene Scharfe.
-Documentation
+Documentation
-
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-archive.txt b/git-archive.txt
index dbe9bad2f..41cbf9c08 100644
--- a/git-archive.txt
+++ b/git-archive.txt
@@ -20,13 +20,13 @@ structure for the named tree, and writes it out to the standard
output. If is specified it is
prepended to the filenames in the archive.
-`git-archive` behaves differently when given a tree ID versus when
+'git-archive' behaves differently when given a tree ID versus when
given a commit ID or tag ID. In the first case the current time is
used as modification time of each file in the archive. In the latter
case the commit time as recorded in the referenced commit object is
used instead. Additionally the commit ID is stored in a global
extended pax header if the tar format is used; it can be extracted
-using `git-get-tar-commit-id`. In ZIP files it is stored as a file
+using 'git-get-tar-commit-id'. In ZIP files it is stored as a file
comment.
OPTIONS
@@ -57,7 +57,7 @@ OPTIONS
--exec=::
Used with --remote to specify the path to the
- `git-upload-archive` on the remote side.
+ 'git-upload-archive' on the remote side.
::
The tree or commit to produce an archive for.
diff --git a/git-bisect.html b/git-bisect.html
index 0a39d974c..ee7465e48 100644
--- a/git-bisect.html
+++ b/git-bisect.html
@@ -3,7 +3,7 @@
-
+
git-bisect(1)
@@ -272,12 +320,12 @@ git-bisect(1) Manual Page
SYNOPSIS
-
git bisect <subcommand> <options>
+
git bisect <subcommand> <options>
-DESCRIPTION
+DESCRIPTION
-
The command takes various subcommands, and different options depending
-on the subcommand:
+
The command takes various subcommands, and different options depending
+on the subcommand:
git bisect help
@@ -291,14 +339,14 @@ git bisect replay <logfile>
git bisect log
git bisect run <cmd>...
-
This command uses git rev-list --bisect to help drive the
+
This command uses git-rev-list --bisect to help drive the
binary search process to find which change introduced a bug, given an
-old "good" commit object name and a later "bad" commit object name.
-
Getting help
-
Use "git bisect" to get a short usage description, and "git bisect
-help" or "git bisect -h" to get a long usage description.
-
Basic bisect commands: start, bad, good
-
The way you use it is:
+old "good" commit object name and a later "bad" commit object name.
+
Getting help
+
Use "git bisect" to get a short usage description, and "git bisect
+help" or "git bisect -h" to get a long usage description.
+
Basic bisect commands: start, bad, good
+
$ git bisect start
@@ -306,74 +354,74 @@ $ git bisect bad # Current version is bad
$ git bisect good v2.6.13-rc2 # v2.6.13-rc2 was the last version
# tested that was good
-
When you give at least one bad and one good versions, it will bisect
-the revision tree and say something like:
+
When you give at least one bad and one good versions, it will bisect
+the revision tree and say something like:
Bisecting: 675 revisions left to test after this
-
and check out the state in the middle. Now, compile that kernel, and
+
and check out the state in the middle. Now, compile that kernel, and
boot it. Now, let's say that this booted kernel works fine, then just
-do
+do
$ git bisect good # this one is good
-
which will now say
+
Bisecting: 337 revisions left to test after this
-
and you continue along, compiling that one, testing it, and depending
+
and you continue along, compiling that one, testing it, and depending
on whether it is good or bad, you say "git bisect good" or "git bisect
-bad", and ask for the next bisection.
-
Until you have no more left, and you'll have been left with the first
-bad kernel rev in "refs/bisect/bad".
-
Bisect reset
-
Oh, and then after you want to reset to the original head, do a
+bad", and ask for the next bisection.
+
Until you have no more left, and you'll have been left with the first
+bad kernel rev in "refs/bisect/bad".
+
Bisect reset
+
Oh, and then after you want to reset to the original head, do a
-
to get back to the original branch, instead of being on the bisection
+
to get back to the original branch, instead of being on the bisection
commit ("git bisect start" will do that for you too, actually: it will
-reset the bisection state).
-
Bisect visualize
-
During the bisection process, you can say
+reset the bisection state).
+
Bisect visualize
+
During the bisection process, you can say
-
to see the currently remaining suspects in gitk . visualize is a bit
-too long to type and view is provided as a synonym.
-
If DISPLAY environment variable is not set, git log is used
+
to see the currently remaining suspects in gitk . visualize is a bit
+too long to type and view is provided as a synonym.
+
If DISPLAY environment variable is not set, git-log is used
instead. You can even give command line options such as -p and
---stat .
+
--stat .
-
Bisect log and bisect replay
-
The good/bad input is logged, and
+
Bisect log and bisect replay
+
The good/bad input is logged, and
-
shows what you have done so far. You can truncate its output somewhere
-and save it in a file, and run
+
shows what you have done so far. You can truncate its output somewhere
+and save it in a file, and run
$ git bisect replay that-file
-
if you find later you made a mistake telling good/bad about a
-revision.
-
Avoiding to test a commit
-
If in a middle of bisect session, you know what the bisect suggested
+
if you find later you made a mistake telling good/bad about a
+revision.
+
Avoiding to test a commit
+
If in a middle of bisect session, you know what the bisect suggested
to try next is not a good one to test (e.g. the change the commit
introduces is known not to work in your environment and you know it
does not have anything to do with the bug you are chasing), you may
-want to find a near-by commit and try that instead.
-
It goes something like this:
+want to find a near-by commit and try that instead.
+
It goes something like this:
$ git bisect good/bad # previous round was good/bad.
@@ -382,69 +430,69 @@ $ git bisect visualize # oops, that is uninteresting.
$ git reset --hard HEAD~3 # try 3 revs before what
# was suggested
-
Then compile and test the one you chose to try. After that, tell
-bisect what the result was as usual.
-
Bisect skip
-
Instead of choosing by yourself a nearby commit, you may just want git
-to do it for you using:
+
Then compile and test the one you chose to try. After that, tell
+bisect what the result was as usual.
+
Bisect skip
+
Instead of choosing by yourself a nearby commit, you may just want git
+to do it for you using:
$ git bisect skip # Current version cannot be tested
-
But computing the commit to test may be slower afterwards and git may
+
But computing the commit to test may be slower afterwards and git may
eventually not be able to tell the first bad among a bad and one or
-more "skip"ped commits.
-
Cutting down bisection by giving more parameters to bisect start
-
You can further cut down the number of trials if you know what part of
+more "skip"ped commits.
+
Cutting down bisection by giving more parameters to bisect start
+
You can further cut down the number of trials if you know what part of
the tree is involved in the problem you are tracking down, by giving
-paths parameters when you say bisect start , like this:
+paths parameters when you say
bisect start , like this:
$ git bisect start -- arch/i386 include/asm-i386
-
If you know beforehand more than one good commits, you can narrow the
+
If you know beforehand more than one good commits, you can narrow the
bisect space down without doing the whole tree checkout every time you
give good commits. You give the bad revision immediately after start
-and then you give all the good revisions you have:
+and then you give all the good revisions you have:
$ git bisect start v2.6.20-rc6 v2.6.20-rc4 v2.6.20-rc1 --
# v2.6.20-rc6 is bad
# v2.6.20-rc4 and v2.6.20-rc1 are good
-
Bisect run
-
If you have a script that can tell if the current source code is good
-or bad, you can automatically bisect using:
+
Bisect run
+
If you have a script that can tell if the current source code is good
+or bad, you can automatically bisect using:
$ git bisect run my_script
-
Note that the "run" script (my_script in the above example) should
+
Note that the "run" script (my_script in the above example) should
exit with code 0 in case the current source code is good. Exit with a
code between 1 and 127 (inclusive), except 125, if the current
-source code is bad.
-
Any other exit code will abort the automatic bisect process. (A
+source code is bad.
+
Any other exit code will abort the automatic bisect process. (A
program that does "exit(-1)" leaves $? = 255, see exit(3) manual page,
-the value is chopped with "& 0377".)
-
The special exit code 125 should be used when the current source code
+the value is chopped with "& 0377".)
+
The special exit code 125 should be used when the current source code
cannot be tested. If the "run" script exits with this code, the current
-revision will be skipped, see git bisect skip above.
-
You may often find that during bisect you want to have near-constant
+revision will be skipped, see git bisect skip above.
+
You may often find that during bisect you want to have near-constant
tweaks (e.g., s/#define DEBUG 0/#define DEBUG 1/ in a header file, or
"revision that does not have this commit needs this patch applied to
work around other problem this bisection is not interested in")
-applied to the revision being tested.
-
To cope with such a situation, after the inner git-bisect finds the
+applied to the revision being tested.
+
To cope with such a situation, after the inner git-bisect finds the
next revision to test, with the "run" script, you can apply that tweak
before compiling, run the real test, and after the test decides if the
revision (possibly with the needed tweaks) passed the test, rewind the
tree to the pristine state. Finally the "run" script can exit with
the status of the real test to let the "git bisect run" command loop to
-determine the outcome.
+determine the outcome.
-EXAMPLES
+EXAMPLES
-
+
Automatically bisect a broken build between v1.2 and HEAD:
@@ -468,13 +516,13 @@ make test # "make test" runs the test suite
$ git bisect start v1.3 v1.1 -- # v1.3 is bad, v1.1 is good
$ git bisect run ~/test.sh
-Here we use a "test.sh" custom script. In this script, if "make"
-fails, we "skip" the current commit.
-It's safer to use a custom script outside the repo to prevent
+
Here we use a "test.sh" custom script. In this script, if "make"
+fails, we "skip" the current commit.
+It's safer to use a custom script outside the repo to prevent
interactions between the bisect, make and test processes and the
-script.
-
And "make test" should "exit 0", if the test suite passes, and
-"exit 1" (for example) otherwise.
+script.
+And "make test" should "exit 0", if the test suite passes, and
+"exit 1" (for example) otherwise.
@@ -489,29 +537,29 @@ make || exit 125 # this "skip"s broken builds
$ git bisect start HEAD HEAD~10 -- # culprit is among the last 10
$ git bisect run ~/test.sh
-
Here "check_test_case.sh" should "exit 0", if the test case passes,
-and "exit 1" (for example) otherwise.
-It's safer if both "test.sh" and "check_test_case.sh" scripts are
+
Here "check_test_case.sh" should "exit 0", if the test case passes,
+and "exit 1" (for example) otherwise.
+It's safer if both "test.sh" and "check_test_case.sh" scripts are
outside the repo to prevent interactions between the bisect, make and
-test processes and the scripts.
+test processes and the scripts.
-
+
-Author
+Author
-
Written by Linus Torvalds <torvalds@osdl.org>
+
Written by Linus Torvalds <torvalds@osdl.org>
-Documentation
+Documentation
-
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-bisect.txt b/git-bisect.txt
index 8bbcb940f..c7981efcd 100644
--- a/git-bisect.txt
+++ b/git-bisect.txt
@@ -26,7 +26,7 @@ on the subcommand:
git bisect log
git bisect run ...
-This command uses `git rev-list --bisect` to help drive the
+This command uses 'git-rev-list --bisect' to help drive the
binary search process to find which change introduced a bug, given an
old "good" commit object name and a later "bad" commit object name.
@@ -98,10 +98,10 @@ During the bisection process, you can say
$ git bisect visualize
------------
-to see the currently remaining suspects in `gitk`. `visualize` is a bit
+to see the currently remaining suspects in 'gitk'. `visualize` is a bit
too long to type and `view` is provided as a synonym.
-If `DISPLAY` environment variable is not set, `git log` is used
+If 'DISPLAY' environment variable is not set, 'git-log' is used
instead. You can even give command line options such as `-p` and
`--stat`.
@@ -215,7 +215,7 @@ tweaks (e.g., s/#define DEBUG 0/#define DEBUG 1/ in a header file, or
work around other problem this bisection is not interested in")
applied to the revision being tested.
-To cope with such a situation, after the inner `git-bisect` finds the
+To cope with such a situation, after the inner 'git-bisect' finds the
next revision to test, with the "run" script, you can apply that tweak
before compiling, run the real test, and after the test decides if the
revision (possibly with the needed tweaks) passed the test, rewind the
diff --git a/git-blame.html b/git-blame.html
index 84a08c4d2..1e92ad4e5 100644
--- a/git-blame.html
+++ b/git-blame.html
@@ -3,7 +3,7 @@
-
+
git-blame(1)
@@ -277,19 +325,19 @@ git-blame(1) Manual Page
[-S <revs-file>] [-M] [-C] [-C] [--since=<date>]
[<rev> | --contents <file>] [--] <file>
-DESCRIPTION
+DESCRIPTION
-
Annotates each line in the given file with information from the revision which
-last modified the line. Optionally, start annotating from the given revision.
-
Also it can limit the range of lines annotated.
-
This report doesn't tell you anything about lines which have been deleted or
-replaced; you need to use a tool such as git-diff or the "pickaxe"
-interface briefly mentioned in the following paragraph.
-
Apart from supporting file annotation, git also supports searching the
+
Annotates each line in the given file with information from the revision which
+last modified the line. Optionally, start annotating from the given revision.
+
Also it can limit the range of lines annotated.
+
This report doesn't tell you anything about lines which have been deleted or
+replaced; you need to use a tool such as git-diff or the "pickaxe"
+interface briefly mentioned in the following paragraph.
+
Apart from supporting file annotation, git also supports searching the
development history for when a code snippet occurred in a change. This makes it
possible to track when a code snippet was added to a file, moved or copied
between files, and eventually deleted or replaced. It works by searching for
-a text string in the diff. A small example:
+a text string in the diff. A small example:
$ git log --pretty=oneline -S'blame_usage'
@@ -297,9 +345,9 @@ a text string in the diff. A small example:
ea4c7f9bf69e781dd0cd88d2bccb2bf5cc15c9a7 git-blame: Make the output
-OPTIONS
+OPTIONS
-
+
-b
@@ -334,30 +382,30 @@ ea4c7f9bf69e781dd0cd88d2bccb2bf5cc15c9a7 git-blame: Make the output
Annotate only the given line range. <start> and <end> can take
one of these forms:
-
+
-THE PORCELAIN FORMAT
+
-
In this format, each line is output after a header; the
-header at the minimum has the first line which has:
-
+In this format, each line is output after a header; the
+header at the minimum has the first line which has:
+
-
This header line is followed by the following information
-at least once for each commit:
-
+This header line is followed by the following information
+at least once for each commit:
+
author name ("author"), email ("author-mail"), time
@@ -575,70 +623,70 @@ filename in the commit the line is attributed to.
the first line of the commit log message ("summary").
-
-
The contents of the actual line is output after the above
+
+The contents of the actual line is output after the above
header, prefixed by a TAB. This is to allow adding more
-header elements later.
+header elements later.
-SPECIFYING RANGES
+SPECIFYING RANGES
-
Unlike git-blame and git-annotate in older git, the extent
+
Unlike git-blame and git-annotate in older git, the extent
of annotation can be limited to both line ranges and revision
ranges. When you are interested in finding the origin for
ll. 40-60 for file foo , you can use -L option like these
(they mean the same thing — both ask for 21 lines starting at
-line 40):
+line 40):
git blame -L 40,60 foo
git blame -L 40,+21 foo
-
Also you can use regular expression to specify the line range.
+
Also you can use regular expression to specify the line range.
git blame -L '/^sub hello {/,/^}$/' foo
-
would limit the annotation to the body of hello subroutine.
-
When you are not interested in changes older than the version
+
would limit the annotation to the body of hello subroutine.
+
When you are not interested in changes older than the version
v2.6.18, or changes older than 3 weeks, you can use revision
-range specifiers similar to git-rev-list :
+range specifiers similar to
git-rev-list :
git blame v2.6.18.. -- foo
git blame --since=3.weeks -- foo
-
When revision range specifiers are used to limit the annotation,
+
When revision range specifiers are used to limit the annotation,
lines that have not changed since the range boundary (either the
commit v2.6.18 or the most recent commit that is more than 3
weeks old in the above example) are blamed for that range
-boundary commit.
-
A particularly useful way is to see if an added file have lines
+boundary commit.
+
A particularly useful way is to see if an added file have lines
created by copy-and-paste from existing files. Sometimes this
indicates that the developer was being sloppy and did not
refactor the code properly. You can first find the commit that
-introduced the file with:
+introduced the file with:
git log --diff-filter=A --pretty=short -- foo
-
and then annotate the change between the commit and its
-parents, using commit^! notation:
+
and then annotate the change between the commit and its
+parents, using commit^! notation:
git blame -C -C -f $commit^! -- foo
-INCREMENTAL OUTPUT
+INCREMENTAL OUTPUT
-
When called with --incremental option, the command outputs the
+
When called with --incremental option, the command outputs the
result as it is built. The output generally will talk about
lines touched by more recent commits first (i.e. the lines will
be annotated out of order) and is meant to be used by
-interactive viewers.
-
The output format is similar to the Porcelain format, but it
+interactive viewers.
+
The output format is similar to the Porcelain format, but it
does not contain the actual lines from the file that is being
-annotated.
-
+annotated.
+
Each blame entry always starts with a line of:
@@ -647,7 +695,7 @@ Each blame entry always starts with a line of:
<40-byte hex sha1> <sourceline> <resultline> <num_lines>
-
Line numbers count from 1.
+
Line numbers count from 1.
@@ -666,8 +714,8 @@ Unlike Porcelain format, the filename information is always
"filename" <whitespace-quoted-filename-goes-here>
-and thus it's really quite easy to parse for some line- and word-oriented
-parser (which should be quite natural for most scripting languages).
+and thus it's really quite easy to parse for some line- and word-oriented
+parser (which should be quite natural for most scripting languages).
@@ -682,23 +730,23 @@ commit commentary), a blame viewer won't ever care.
-
+
-SEE ALSO
+SEE ALSO
-AUTHOR
+AUTHOR
-
Written by Junio C Hamano <junkio@cox.net>
+
Written by Junio C Hamano <junkio@cox.net>
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-blame.txt b/git-blame.txt
index 443039fd9..34b24a3ca 100644
--- a/git-blame.txt
+++ b/git-blame.txt
@@ -21,7 +21,7 @@ last modified the line. Optionally, start annotating from the given revision.
Also it can limit the range of lines annotated.
This report doesn't tell you anything about lines which have been deleted or
-replaced; you need to use a tool such as `git-diff` or the "pickaxe"
+replaced; you need to use a tool such as 'git-diff' or the "pickaxe"
interface briefly mentioned in the following paragraph.
Apart from supporting file annotation, git also supports searching the
@@ -49,7 +49,7 @@ include::blame-options.txt[]
file (see `-M`). The first number listed is the score.
This is the number of alphanumeric characters detected
to be moved between or within files. This must be above
- a certain threshold for `git-blame` to consider those lines
+ a certain threshold for 'git-blame' to consider those lines
of code to have been moved.
-f::
@@ -100,7 +100,7 @@ header elements later.
SPECIFYING RANGES
-----------------
-Unlike `git-blame` and `git-annotate` in older git, the extent
+Unlike 'git-blame' and 'git-annotate' in older git, the extent
of annotation can be limited to both line ranges and revision
ranges. When you are interested in finding the origin for
ll. 40-60 for file `foo`, you can use `-L` option like these
@@ -118,7 +118,7 @@ would limit the annotation to the body of `hello` subroutine.
When you are not interested in changes older than the version
v2.6.18, or changes older than 3 weeks, you can use revision
-range specifiers similar to `git-rev-list`:
+range specifiers similar to 'git-rev-list':
git blame v2.6.18.. -- foo
git blame --since=3.weeks -- foo
diff --git a/git-branch.html b/git-branch.html
index 2c1f8878e..6365ba299 100644
--- a/git-branch.html
+++ b/git-branch.html
@@ -3,7 +3,7 @@
-
+
git-branch(1)
@@ -280,9 +328,9 @@ git-branch(1) Manual Page
git branch (-m | -M) [<oldbranch>] <newbranch>
git branch (-d | -D) [-r] <branchname>…
-DESCRIPTION
+DESCRIPTION
-
With no arguments given a list of existing branches
+
With no arguments given a list of existing branches
will be shown, the current branch will be highlighted with an asterisk.
Option -r causes the remote-tracking branches to be listed,
and option -a shows both.
@@ -290,36 +338,36 @@ With --contains <commit> , shows only the branches that
contains the named commit (in other words, the branches whose
tip commits are descendant of the named commit).
With --merged , only branches merged into HEAD will be listed, and
-with --no-merged only branches not merged into HEAD will be listed.
-
In its second form, a new branch named <branchname> will be created.
+with --no-merged only branches not merged into HEAD will be listed.
+
In its second form, a new branch named <branchname> will be created.
It will start out with a head equal to the one given as <start-point>.
If no <start-point> is given, the branch will be created with a head
-equal to that of the currently checked out branch.
-
Note that this will create the new branch, but it will not switch the
+equal to that of the currently checked out branch.
+
Note that this will create the new branch, but it will not switch the
working tree to it; use "git checkout <newbranch>" to switch to the
-new branch.
-
When a local branch is started off a remote branch, git sets up the
-branch so that git-pull will appropriately merge from
+new branch.
+
When a local branch is started off a remote branch, git sets up the
+branch so that git-pull will appropriately merge from
the remote branch. This behavior may be changed via the global
branch.autosetupmerge configuration flag. That setting can be
-overridden by using the --track and --no-track options.
-
With a -m or -M option, <oldbranch> will be renamed to <newbranch>.
+overridden by using the --track and --no-track options.
+
With a -m or -M option, <oldbranch> will be renamed to <newbranch>.
If <oldbranch> had a corresponding reflog, it is renamed to match
<newbranch>, and a reflog entry is created to remember the branch
renaming. If <newbranch> exists, -M must be used to force the rename
-to happen.
-
With a -d or -D option, <branchname> will be deleted. You may
+to happen.
+
With a -d or -D option, <branchname> will be deleted. You may
specify more than one branch for deletion. If the branch currently
-has a reflog then the reflog will also be deleted.
-
Use -r together with -d to delete remote-tracking branches. Note, that it
+has a reflog then the reflog will also be deleted.
+
Use -r together with -d to delete remote-tracking branches. Note, that it
only makes sense to delete remote-tracking branches if they no longer exist
-in remote repository or if git-fetch was configured not to fetch
+in remote repository or if git-fetch was configured not to fetch
them again. See also prune subcommand of git-remote(1) for way to
-clean up all obsolete remote-tracking branches.
+clean up all obsolete remote-tracking branches.
-OPTIONS
+OPTIONS
-
+
-d
@@ -437,14 +485,14 @@ clean up all obsolete remote-tracking branches.
- When creating a new branch, set up configuration so that git-pull
+ When creating a new branch, set up configuration so that git-pull
will automatically retrieve data from the start point, which must be
a branch. Use this if you always pull from the same upstream branch
into the new branch, and if you don't want to use "git pull
<repository> <refspec>" explicitly. This behavior is the default
when the start point is a remote branch. Set the
branch.autosetupmerge configuration variable to false if you want
- git-checkout and git-branch to always behave as if --no-track were
+ git-checkout and git-branch to always behave as if --no-track were
given. Set it to always if you want this behavior when the
start-point is either a local or remote branch.
@@ -519,11 +567,11 @@ clean up all obsolete remote-tracking branches.
<branchname> applies.
-
+
-Examples
+Examples
-
+
Start development off of a known tag
@@ -535,14 +583,14 @@ $ cd my2.6
$ git branch my2.6.14 v2.6.14 (1)
$ git checkout my2.6.14
-
+
This step and the next one could be combined into a single step with
"checkout -b my2.6.14 v2.6.14".
-
+
Delete unneeded branch
@@ -555,7 +603,7 @@ $ cd my.git
$ git branch -d -r origin/todo origin/html origin/man (1)
$ git branch -D test (2)
-
+
Delete remote-tracking branches "todo", "html", "man". Next fetch or
@@ -569,18 +617,18 @@ Delete "test" branch even if the "master" branch (or whichever branch is
currently checked out) does not have all commits from test branch.
-
+
-
+
-Notes
+Notes
-
If you are creating a branch that you want to immediately checkout, it's
+
If you are creating a branch that you want to immediately checkout, it's
easier to use the git checkout command with its -b option to create
-a branch and check it out with a single command.
-
The options --contains , --merged and --no-merged serves three related
-but different purposes:
-
+a branch and check it out with a single command.
+
The options --contains , --merged and --no-merged serves three related
+but different purposes:
+
-Author
+Author
-
Written by Linus Torvalds <torvalds@osdl.org> and Junio C Hamano <junkio@cox.net>
+
Written by Linus Torvalds <torvalds@osdl.org> and Junio C Hamano <junkio@cox.net>
-Documentation
+Documentation
-
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-branch.txt b/git-branch.txt
index 5e78aed7d..b3e62ed01 100644
--- a/git-branch.txt
+++ b/git-branch.txt
@@ -37,7 +37,7 @@ working tree to it; use "git checkout " to switch to the
new branch.
When a local branch is started off a remote branch, git sets up the
-branch so that `git-pull` will appropriately merge from
+branch so that 'git-pull' will appropriately merge from
the remote branch. This behavior may be changed via the global
`branch.autosetupmerge` configuration flag. That setting can be
overridden by using the `--track` and `--no-track` options.
@@ -54,7 +54,7 @@ has a reflog then the reflog will also be deleted.
Use -r together with -d to delete remote-tracking branches. Note, that it
only makes sense to delete remote-tracking branches if they no longer exist
-in remote repository or if `git-fetch` was configured not to fetch
+in remote repository or if 'git-fetch' was configured not to fetch
them again. See also 'prune' subcommand of linkgit:git-remote[1] for way to
clean up all obsolete remote-tracking branches.
@@ -107,14 +107,14 @@ OPTIONS
Display the full sha1s in output listing rather than abbreviating them.
--track::
- When creating a new branch, set up configuration so that `git-pull`
+ When creating a new branch, set up configuration so that 'git-pull'
will automatically retrieve data from the start point, which must be
a branch. Use this if you always pull from the same upstream branch
into the new branch, and if you don't want to use "git pull
" explicitly. This behavior is the default
when the start point is a remote branch. Set the
branch.autosetupmerge configuration variable to `false` if you want
- `git-checkout` and `git-branch` to always behave as if '--no-track' were
+ 'git-checkout' and 'git-branch' to always behave as if '--no-track' were
given. Set it to `always` if you want this behavior when the
start-point is either a local or remote branch.
diff --git a/git-bundle.html b/git-bundle.html
index 3ec368b7e..0dedd9ca4 100644
--- a/git-bundle.html
+++ b/git-bundle.html
@@ -3,7 +3,7 @@
-
+
git-bundle(1)
@@ -278,31 +326,31 @@ git-bundle(1) Manual Page
git bundle list-heads <file> [refname…]
git bundle unbundle <file> [refname…]
-DESCRIPTION
+DESCRIPTION
-
Some workflows require that one or more branches of development on one
+
Some workflows require that one or more branches of development on one
machine be replicated on another machine, but the two machines cannot
be directly connected so the interactive git protocols (git, ssh,
rsync, http) cannot be used. This command provides support for
-git-fetch and git-pull to operate by packaging objects and references
+git-fetch and git-pull to operate by packaging objects and references
in an archive at the originating machine, then importing those into
-another repository using git-fetch and git-pull
+another repository using git-fetch and git-pull
after moving the archive by some means (i.e., by sneakernet). As no
direct connection between repositories exists, the user must specify a
basis for the bundle that is held by the destination repository: the
bundle assumes that all objects in the basis are already in the
-destination repository.
+destination repository.
-OPTIONS
+OPTIONS
-
+
create <file>
Used to create a bundle named file . This requires the
- git-rev-list arguments to define the bundle contents.
+ git-rev-list arguments to define the bundle contents.
@@ -314,7 +362,7 @@ verify <file>
cleanly to the current repository. This includes checks on the
bundle format itself as well as checking that the prerequisite
commits exist and are fully linked in the current repository.
- git-bundle prints a list of missing commits, if any, and exits
+ git-bundle prints a list of missing commits, if any, and exits
with non-zero status.
@@ -333,11 +381,11 @@ unbundle <file>
- Passes the objects in the bundle to git-index-pack
+ Passes the objects in the bundle to git-index-pack
for storage in the repository, then prints the names of all
defined references. If a reflist is given, only references
matching those in the given list are printed. This command is
- really plumbing, intended to be called only by git-fetch .
+ really plumbing, intended to be called only by git-fetch .
@@ -345,8 +393,8 @@ unbundle <file>
- A list of arguments, acceptable to git-rev-parse and
- git-rev-list , that specify the specific objects and references
+ A list of arguments, acceptable to git-rev-parse and
+ git-rev-list , that specify the specific objects and references
to transport. For example, "master~10..master" causes the
current master reference to be packaged along with all objects
added since its 10th ancestor commit. There is no explicit
@@ -360,130 +408,130 @@ unbundle <file>
A list of references used to limit the references reported as
- available. This is principally of use to git-fetch , which
+ available. This is principally of use to git-fetch , which
expects to receive only those references asked for and not
- necessarily everything in the pack (in this case, git-bundle is
- acting like git-fetch-pack ).
+ necessarily everything in the pack (in this case, git-bundle is
+ acting like git-fetch-pack ).
-
+
-SPECIFYING REFERENCES
+SPECIFYING REFERENCES
-
git-bundle will only package references that are shown by
-git-show-ref : this includes heads, tags, and remote heads. References
-such as master~1 cannot be packaged, but are perfectly suitable for
+
git-bundle will only package references that are shown by
+git-show-ref : this includes heads, tags, and remote heads. References
+such as master1 cannot be packaged, but are perfectly suitable for
defining the basis. More than one reference may be packaged, and more
than one basis can be specified. The objects packaged are those not
contained in the union of the given bases. Each basis can be
-specified explicitly (e.g., ^master~10), or implicitly (e.g.,
-master~10..master, master --since=10.days.ago).
-
It is very important that the basis used be held by the destination.
+specified explicitly (e.g., ^master10), or implicitly (e.g.,
+master~10..master, master --since=10.days.ago).
+
It is very important that the basis used be held by the destination.
It is okay to err on the side of conservatism, causing the bundle file
to contain objects already in the destination as these are ignored
-when unpacking at the destination.
+when unpacking at the destination.
-EXAMPLE
+EXAMPLE
-
Assume two repositories exist as R1 on machine A, and R2 on machine B.
+
Assume two repositories exist as R1 on machine A, and R2 on machine B.
For whatever reason, direct connection between A and B is not allowed,
but we can move data from A to B via some mechanism (CD, email, etc).
-We want to update R2 with developments made on branch master in R1.
-
To create the bundle you have to specify the basis. You have some options:
-
+We want to update R2 with developments made on branch master in R1.
+
To create the bundle you have to specify the basis. You have some options:
+
$ git bundle create mybundle master
-
+
$ git bundle create mybundle master ^lastR2bundle
$ git tag -f lastR2bundle master
-
+
$ git bundle create mybundle master ^v1.0.0
-
+
$ git bundle create mybundle master --since=10.days.ago
-
+
$ git bundle create mybundle master -n 10
-Then you move mybundle from A to B, and in R2 on B:
+Then you move mybundle from A to B, and in R2 on B:
$ git bundle verify mybundle
$ git fetch mybundle master:localRef
-With something like this in the config in R2:
+With something like this in the config in R2:
[remote "bundle"]
url = /home/me/tmp/file.bdl
fetch = refs/heads/*:refs/remotes/origin/*
-You can first sneakernet the bundle file to ~/tmp/file.bdl and
-then these commands on machine B:
+You can first sneakernet the bundle file to ~/tmp/file.bdl and
+then these commands on machine B:
$ git ls-remote bundle
$ git fetch bundle
$ git pull bundle
-would treat it as if it is talking with a remote side over the
-network.
+would treat it as if it is talking with a remote side over the
+network.
-Author
+Author
-
Written by Mark Levedahl <mdl123@verizon.net>
+
Written by Mark Levedahl <mdl123@verizon.net>
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-bundle.txt b/git-bundle.txt
index b729db7d2..1b66ab743 100644
--- a/git-bundle.txt
+++ b/git-bundle.txt
@@ -21,9 +21,9 @@ Some workflows require that one or more branches of development on one
machine be replicated on another machine, but the two machines cannot
be directly connected so the interactive git protocols (git, ssh,
rsync, http) cannot be used. This command provides support for
-`git-fetch` and `git-pull` to operate by packaging objects and references
+'git-fetch' and 'git-pull' to operate by packaging objects and references
in an archive at the originating machine, then importing those into
-another repository using `git-fetch` and `git-pull`
+another repository using 'git-fetch' and 'git-pull'
after moving the archive by some means (i.e., by sneakernet). As no
direct connection between repositories exists, the user must specify a
basis for the bundle that is held by the destination repository: the
@@ -35,14 +35,14 @@ OPTIONS
create ::
Used to create a bundle named 'file'. This requires the
- `git-rev-list` arguments to define the bundle contents.
+ 'git-rev-list' arguments to define the bundle contents.
verify ::
Used to check that a bundle file is valid and will apply
cleanly to the current repository. This includes checks on the
bundle format itself as well as checking that the prerequisite
commits exist and are fully linked in the current repository.
- `git-bundle` prints a list of missing commits, if any, and exits
+ 'git-bundle' prints a list of missing commits, if any, and exits
with non-zero status.
list-heads ::
@@ -51,15 +51,15 @@ list-heads ::
printed out.
unbundle ::
- Passes the objects in the bundle to `git-index-pack`
+ Passes the objects in the bundle to 'git-index-pack'
for storage in the repository, then prints the names of all
defined references. If a reflist is given, only references
matching those in the given list are printed. This command is
- really plumbing, intended to be called only by `git-fetch`.
+ really plumbing, intended to be called only by 'git-fetch'.
[git-rev-list-args...]::
- A list of arguments, acceptable to `git-rev-parse` and
- `git-rev-list`, that specify the specific objects and references
+ A list of arguments, acceptable to 'git-rev-parse' and
+ 'git-rev-list', that specify the specific objects and references
to transport. For example, "master~10..master" causes the
current master reference to be packaged along with all objects
added since its 10th ancestor commit. There is no explicit
@@ -69,16 +69,16 @@ unbundle ::
[refname...]::
A list of references used to limit the references reported as
- available. This is principally of use to `git-fetch`, which
+ available. This is principally of use to 'git-fetch', which
expects to receive only those references asked for and not
- necessarily everything in the pack (in this case, `git-bundle` is
- acting like `git-fetch-pack`).
+ necessarily everything in the pack (in this case, 'git-bundle' is
+ acting like 'git-fetch-pack').
SPECIFYING REFERENCES
---------------------
-`git-bundle` will only package references that are shown by
-`git-show-ref`: this includes heads, tags, and remote heads. References
+'git-bundle' will only package references that are shown by
+'git-show-ref': this includes heads, tags, and remote heads. References
such as master~1 cannot be packaged, but are perfectly suitable for
defining the basis. More than one reference may be packaged, and more
than one basis can be specified. The objects packaged are those not
diff --git a/git-check-ref-format.html b/git-check-ref-format.html
index 85c588a9e..0796f4809 100644
--- a/git-check-ref-format.html
+++ b/git-check-ref-format.html
@@ -3,7 +3,7 @@
-
+
git-check-ref-format(1)
@@ -272,17 +320,17 @@ git-check-ref-format(1) Manual Page
SYNOPSIS
-
git check-ref-format <refname>
+
git check-ref-format <refname>
-DESCRIPTION
+DESCRIPTION
-
Checks if a given refname is acceptable, and exits non-zero if
-it is not.
-
A reference is used in git to specify branches and tags. A
+
Checks if a given refname is acceptable, and exits non-zero if
+it is not.
+
A reference is used in git to specify branches and tags. A
branch head is stored under $GIT_DIR/refs/heads directory, and
a tag is stored under $GIT_DIR/refs/tags directory. git
-imposes the following rules on how refs are named:
-
+imposes the following rules on how refs are named:
+
It can include slash / for hierarchical (directory)
@@ -308,12 +356,12 @@ It cannot have ASCII control character (i.e. bytes whose
It cannot end with a slash / .
-
-
These rules makes it easy for shell script based tools to parse
+
+
These rules makes it easy for shell script based tools to parse
refnames, pathname expansion by the shell when a refname is used
unquoted (by mistake), and also avoids ambiguities in certain
-refname expressions (see git-rev-parse(1) ). Namely:
-
+refname expressions (see git-rev-parse(1) ). Namely:
+
double-dot .. are often used as in ref1..ref2 , and in some
@@ -332,18 +380,18 @@ tilde ~ and caret ^ are used to introduce postfix
colon : is used as in srcref:dstref to mean "use srcref's
value and store it in dstref" in fetch and push operations.
It may also be used to select a specific object such as with
- git-cat-file : "git cat-file blob v1.3.3:refs.c".
+ 'git-cat-file': "git cat-file blob v1.3.3:refs.c".
-
+
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-check-ref-format.txt b/git-check-ref-format.txt
index 429083bb6..034223cc5 100644
--- a/git-check-ref-format.txt
+++ b/git-check-ref-format.txt
@@ -47,7 +47,7 @@ refname expressions (see linkgit:git-rev-parse[1]). Namely:
. colon `:` is used as in `srcref:dstref` to mean "use srcref\'s
value and store it in dstref" in fetch and push operations.
It may also be used to select a specific object such as with
- `git-cat-file`: "git cat-file blob v1.3.3:refs.c".
+ 'git-cat-file': "git cat-file blob v1.3.3:refs.c".
GIT
diff --git a/git-checkout-index.html b/git-checkout-index.html
index 76e81a057..cd74976d8 100644
--- a/git-checkout-index.html
+++ b/git-checkout-index.html
@@ -3,7 +3,7 @@
-
+
git-checkout-index(1)
@@ -279,14 +327,14 @@ git-checkout-index(1) Manual Page
[-z] [--stdin]
[--] [<file>]*
-DESCRIPTION
+DESCRIPTION
-
Will copy all files listed from the index to the working directory
-(not overwriting existing files).
+
Will copy all files listed from the index to the working directory
+(not overwriting existing files).
-OPTIONS
+OPTIONS
-
+
-u
@@ -401,75 +449,75 @@ git-checkout-index(1) Manual Page
Do not interpret any more arguments as options.
-
-
The order of the flags used to matter, but not anymore.
-
Just doing git checkout-index does nothing. You probably meant
+
+The order of the flags used to matter, but not anymore.
+Just doing git checkout-index does nothing. You probably meant
git checkout-index -a . And if you want to force it, you want
-git checkout-index -f -a .
-
Intuitiveness is not the goal here. Repeatability is. The reason for
+git checkout-index -f -a .
+Intuitiveness is not the goal here. Repeatability is. The reason for
the "no arguments means no work" behavior is that from scripts you are
-supposed to be able to do:
+supposed to be able to do:
$ find . -name '*.h' -print0 | xargs -0 git checkout-index -f --
-which will force all existing *.h files to be replaced with their
+
which will force all existing *.h files to be replaced with their
cached copies. If an empty command line implied "all", then this would
force-refresh everything in the index, which was not the point. But
-since git-checkout-index accepts --stdin it would be faster to use:
+since
git-checkout-index accepts --stdin it would be faster to use:
$ find . -name '*.h' -print0 | git checkout-index -f -z --stdin
-The -- is just a good idea when you know the rest will be filenames;
+
The -- is just a good idea when you know the rest will be filenames;
it will prevent problems with a filename of, for example, -a .
-Using -- is probably a good policy in scripts.
+Using
-- is probably a good policy in scripts.
-Using --temp or --stage=all
+Using --temp or --stage=all
-
When --temp is used (or implied by --stage=all )
-git-checkout-index will create a temporary file for each index
+
When --temp is used (or implied by --stage=all )
+git-checkout-index will create a temporary file for each index
entry being checked out. The index will not be updated with stat
information. These options can be useful if the caller needs all
stages of all unmerged entries so that the unmerged files can be
-processed by an external merge tool.
-
A listing will be written to stdout providing the association of
+processed by an external merge tool.
+
A listing will be written to stdout providing the association of
temporary file names to tracked path names. The listing format
-has two variations:
-
+has two variations:
+
tempname TAB path RS
-The first format is what gets used when --stage is omitted or
+
The first format is what gets used when --stage is omitted or
is not --stage=all . The field tempname is the temporary file
name holding the file content and path is the tracked path name in
-the index. Only the requested entries are output.
+the index. Only the requested entries are output.
stage1temp SP stage2temp SP stage3tmp TAB path RS
-The second format is what gets used when --stage=all . The three
+
The second format is what gets used when --stage=all . The three
stage temporary fields (stage1temp, stage2temp, stage3temp) list the
name of the temporary file if there is a stage entry in the index
or . if there is no stage entry. Paths which only have a stage 0
-entry will always be omitted from the output.
+entry will always be omitted from the output.
-
-
In both formats RS (the record separator) is newline by default
+
+
In both formats RS (the record separator) is newline by default
but will be the null byte if -z was passed on the command line.
The temporary file names are always safe strings; they will never
contain directory separators or whitespace characters. The path
field is always relative to the current directory and the temporary
-file names are always relative to the top level directory.
-
If the object being copied out to a temporary file is a symbolic
+file names are always relative to the top level directory.
+
If the object being copied out to a temporary file is a symbolic
link the content of the link will be written to a normal file. It is
-up to the end-user or the Porcelain to make use of this information.
+up to the end-user or the Porcelain to make use of this information.
-EXAMPLES
+EXAMPLES
-
+
To update and refresh only the files already checked out
@@ -480,23 +528,23 @@ To update and refresh only the files already checked out
-Using git-checkout-index to "export an entire tree"
+Using git-checkout-index to "export an entire tree"
The prefix ability basically makes it trivial to use
- git-checkout-index as an "export as tree" function.
+ git-checkout-index as an "export as tree" function.
Just read the desired tree into the index, and do:
$ git checkout-index --prefix=git-export-dir/ -a
-git checkout-index will "export" the index into the specified
-directory.
-The final "/" is important. The exported name is literally just
+
git checkout-index will "export" the index into the specified
+directory.
+The final "/" is important. The exported name is literally just
prefixed with the specified string. Contrast this with the
-following example.
+following example.
Export files with a prefix
@@ -506,27 +554,27 @@ Export files with a prefix
$ git checkout-index --prefix=.merged- Makefile
-This will check out the currently cached copy of Makefile
-into the file .merged-Makefile .
+This will check out the currently cached copy of Makefile
+into the file .merged-Makefile .
-
+
-Author
+Author
-
Written by Linus Torvalds <torvalds@osdl.org>
+
Written by Linus Torvalds <torvalds@osdl.org>
-Documentation
+Documentation
-
Documentation by David Greaves,
-Junio C Hamano and the git-list <git@vger.kernel.org>.
+
Documentation by David Greaves,
+Junio C Hamano and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-checkout-index.txt b/git-checkout-index.txt
index a833a4dda..62d84836b 100644
--- a/git-checkout-index.txt
+++ b/git-checkout-index.txt
@@ -88,7 +88,7 @@ $ find . -name '*.h' -print0 | xargs -0 git checkout-index -f --
which will force all existing `*.h` files to be replaced with their
cached copies. If an empty command line implied "all", then this would
force-refresh everything in the index, which was not the point. But
-since `git-checkout-index` accepts --stdin it would be faster to use:
+since 'git-checkout-index' accepts --stdin it would be faster to use:
----------------
$ find . -name '*.h' -print0 | git checkout-index -f -z --stdin
@@ -102,7 +102,7 @@ Using `--` is probably a good policy in scripts.
Using --temp or --stage=all
---------------------------
When `--temp` is used (or implied by `--stage=all`)
-`git-checkout-index` will create a temporary file for each index
+'git-checkout-index' will create a temporary file for each index
entry being checked out. The index will not be updated with stat
information. These options can be useful if the caller needs all
stages of all unmerged entries so that the unmerged files can be
@@ -147,9 +147,9 @@ To update and refresh only the files already checked out::
$ git checkout-index -n -f -a && git update-index --ignore-missing --refresh
----------------
-Using `git-checkout-index` to "export an entire tree"::
+Using 'git-checkout-index' to "export an entire tree"::
The prefix ability basically makes it trivial to use
- `git-checkout-index` as an "export as tree" function.
+ 'git-checkout-index' as an "export as tree" function.
Just read the desired tree into the index, and do:
+
----------------
diff --git a/git-checkout.html b/git-checkout.html
index 8765bef7c..22230f0cc 100644
--- a/git-checkout.html
+++ b/git-checkout.html
@@ -3,7 +3,7 @@
-
+
git-checkout(1)
@@ -276,15 +324,15 @@ git-checkout(1) Manual Page
git checkout [-q] [-f] [[--track | --no-track] -b <new_branch> [-l]] [-m] [<branch>]
git checkout [<tree-ish>] <paths>…
-DESCRIPTION
+DESCRIPTION
-
When <paths> are not given, this command switches branches by
+
When <paths> are not given, this command switches branches by
updating the index and working tree to reflect the specified
branch, <branch>, and updating HEAD to be <branch> or, if
specified, <new_branch>. Using -b will cause <new_branch> to
be created; in this case you can use the --track or --no-track
-options, which will be passed to git branch .
-
When <paths> are given, this command does not switch
+options, which will be passed to git branch .
+
When <paths> are given, this command does not switch
branches. It updates the named paths in the working tree from
the index file (i.e. it runs git checkout-index -f -u ), or
from a named commit. In
@@ -292,11 +340,11 @@ this case, the -f and -b options are meaningless and giving
either of them results in an error. <tree-ish> argument can be
used to specify a specific tree-ish (i.e. commit, tag or tree)
to update the index for the given paths before updating the
-working tree.
+working tree.
-OPTIONS
+OPTIONS
-
+
-q
@@ -333,14 +381,14 @@ working tree.
- When creating a new branch, set up configuration so that git-pull
+ When creating a new branch, set up configuration so that git-pull
will automatically retrieve data from the start point, which must be
a branch. Use this if you always pull from the same upstream branch
into the new branch, and if you don't want to use "git pull
<repository> <refspec>" explicitly. This behavior is the default
when the start point is a remote branch. Set the
branch.autosetupmerge configuration variable to false if you want
- git-checkout and git-branch to always behave as if --no-track were
+ git-checkout and git-branch to always behave as if --no-track were
given. Set it to always if you want this behavior when the
start-point is either a local or remote branch.
@@ -376,10 +424,10 @@ working tree.
branch, your working tree contents, and the new branch
is done, and you will be on the new branch.
-When a merge conflict happens, the index entries for conflicting
+
When a merge conflict happens, the index entries for conflicting
paths are left unmerged, and you need to resolve the conflicts
and mark the resolved paths with git add (or git rm if the merge
-should result in deletion of the path).
+should result in deletion of the path).
<new_branch>
@@ -397,46 +445,46 @@ should result in deletion of the path).
Branch to checkout; may be any object ID that resolves to a
commit. Defaults to HEAD.
-When this parameter names a non-branch (but still a valid commit object),
-your HEAD becomes detached .
+When this parameter names a non-branch (but still a valid commit object),
+your HEAD becomes detached .
-
+
-Detached HEAD
+Detached HEAD
-
It is sometimes useful to be able to checkout a commit that is
+
It is sometimes useful to be able to checkout a commit that is
not at the tip of one of your branches. The most obvious
example is to check out the commit at a tagged official release
-point, like this:
+point, like this:
-
Earlier versions of git did not allow this and asked you to
+
Earlier versions of git did not allow this and asked you to
create a temporary branch using -b option, but starting from
version 1.5.0, the above command detaches your HEAD from the
current branch and directly point at the commit named by the tag
-(v2.6.18 in the above example).
-
You can use usual git commands while in this state. You can use
+(v2.6.18 in the above example).
+
You can use usual git commands while in this state. You can use
git reset --hard $othercommit to further move around, for
example. You can make changes and create a new commit on top of
a detached HEAD. You can even create a merge by using git
-merge $othercommit .
-
The state you are in while your HEAD is detached is not recorded
+merge $othercommit.
+
The state you are in while your HEAD is detached is not recorded
by any branch (which is natural --- you are not on any branch).
What this means is that you can discard your temporary commits
and merges by switching back to an existing branch (e.g. git
checkout master ), and a later git prune or git gc would
garbage-collect them. If you did this by mistake, you can ask
-the reflog for HEAD where you were, e.g.
+the reflog for HEAD where you were, e.g.
-EXAMPLES
+EXAMPLES
-
+
The following sequence checks out the master branch, reverts
@@ -450,7 +498,7 @@ $ git checkout master~2 Makefile (2)
$ rm -f hello.c
$ git checkout hello.c (3)
-
+
switch branch
@@ -465,15 +513,15 @@ take out a file out of other commit
restore hello.c from HEAD of current branch
-If you have an unfortunate branch that is named hello.c , this
+
If you have an unfortunate branch that is named hello.c , this
step would be confused as an instruction to switch to that branch.
-You should instead write:
+You should instead write:
$ git checkout -- hello.c
-
+
@@ -484,24 +532,24 @@ branch would be done using:
-However, your "wrong" branch and correct "mytopic" branch may
+
However, your "wrong" branch and correct "mytopic" branch may
differ in files that you have locally modified, in which case,
-the above checkout would fail like this:
+the above checkout would fail like this:
$ git checkout mytopic
fatal: Entry 'frotz' not uptodate. Cannot merge.
-You can give the -m flag to the command, which would try a
-three-way merge:
+You can give the -m flag to the command, which would try a
+three-way merge:
$ git checkout -m mytopic
Auto-merging frotz
-After this three-way merge, the local modifications are _not_
+
After this three-way merge, the local modifications are not
registered in your index file, so git diff would show you what
-changes you made since the tip of the new branch.
+changes you made since the tip of the new branch.
@@ -516,33 +564,33 @@ merge: warning: conflicts during merge
ERROR: Merge conflict in frotz
fatal: merge program failed
-
At this point, git diff shows the changes cleanly merged as in
+
At this point, git diff shows the changes cleanly merged as in
the previous example, as well as the changes in the conflicted
files. Edit and resolve the conflict and mark it resolved with
-git add as usual:
+
git add as usual:
$ edit frotz
$ git add frotz
-
+
-Author
+Author
-
Written by Linus Torvalds <torvalds@osdl.org>
+
Written by Linus Torvalds <torvalds@osdl.org>
-Documentation
+Documentation
-
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-checkout.txt b/git-checkout.txt
index c0f9c6e88..2abfbdaad 100644
--- a/git-checkout.txt
+++ b/git-checkout.txt
@@ -49,14 +49,14 @@ OPTIONS
-t::
--track::
- When creating a new branch, set up configuration so that `git-pull`
+ When creating a new branch, set up configuration so that 'git-pull'
will automatically retrieve data from the start point, which must be
a branch. Use this if you always pull from the same upstream branch
into the new branch, and if you don't want to use "git pull
" explicitly. This behavior is the default
when the start point is a remote branch. Set the
branch.autosetupmerge configuration variable to `false` if you want
- `git-checkout` and `git-branch` to always behave as if '--no-track' were
+ 'git-checkout' and 'git-branch' to always behave as if '--no-track' were
given. Set it to `always` if you want this behavior when the
start-point is either a local or remote branch.
diff --git a/git-cherry-pick.html b/git-cherry-pick.html
index 3dcec28fa..79e62bb76 100644
--- a/git-cherry-pick.html
+++ b/git-cherry-pick.html
@@ -3,7 +3,7 @@
-
+
git-cherry-pick(1)
@@ -272,17 +320,17 @@ git-cherry-pick(1) Manual Page
SYNOPSIS
-
git cherry-pick [--edit] [-n] [-m parent-number] [-s] [-x] <commit>
+
git cherry-pick [--edit] [-n] [-m parent-number] [-s] [-x] <commit>
-DESCRIPTION
+DESCRIPTION
-
Given one existing commit, apply the change the patch introduces, and record a
+
Given one existing commit, apply the change the patch introduces, and record a
new commit that records it. This requires your working tree to be clean (no
-modifications from the HEAD commit).
+modifications from the HEAD commit).
-OPTIONS
+OPTIONS
-
+
<commit>
@@ -301,7 +349,7 @@ modifications from the HEAD commit).
- With this option, git-cherry-pick will let you edit the commit
+ With this option, git-cherry-pick will let you edit the commit
message prior to committing.
@@ -365,8 +413,8 @@ modifications from the HEAD commit).
the HEAD commit. The cherry-pick is done against the
beginning state of your working tree.
-This is useful when cherry-picking more than one commits'
-effect to your working tree in a row.
+This is useful when cherry-picking more than one commits'
+effect to your working tree in a row.
-s
@@ -379,23 +427,23 @@ effect to your working tree in a row.
Add Signed-off-by line at the end of the commit message.
-
+
-Author
+Author
-
Written by Junio C Hamano <junkio@cox.net>
+
Written by Junio C Hamano <junkio@cox.net>
-Documentation
+Documentation
-
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-cherry-pick.txt b/git-cherry-pick.txt
index 1b864dacf..a691173ba 100644
--- a/git-cherry-pick.txt
+++ b/git-cherry-pick.txt
@@ -24,7 +24,7 @@ OPTIONS
-e::
--edit::
- With this option, `git-cherry-pick` will let you edit the commit
+ With this option, 'git-cherry-pick' will let you edit the commit
message prior to committing.
-x::
diff --git a/git-cherry.html b/git-cherry.html
index aa6f08438..1e6195d89 100644
--- a/git-cherry.html
+++ b/git-cherry.html
@@ -3,7 +3,7 @@
-
+
git-cherry(1)
@@ -272,19 +320,19 @@ git-cherry(1) Manual Page
SYNOPSIS
-
git cherry [-v] <upstream> [<head>] [<limit>]
+
git cherry [-v] <upstream> [<head>] [<limit>]
-DESCRIPTION
+DESCRIPTION
-
The changeset (or "diff") of each commit between the fork-point and <head>
+
The changeset (or "diff") of each commit between the fork-point and <head>
is compared against each commit between the fork-point and <upstream>.
The commits are compared with their patch id , obtained from
-the git-patch-id program.
-
Every commit that doesn't exist in the <upstream> branch
+the git-patch-id program.
+
Every commit that doesn't exist in the <upstream> branch
has its id (sha1) reported, prefixed by a symbol. The ones that have
equivalent change already
in the <upstream> branch are prefixed with a minus (-) sign, and those
-that only exist in the <head> branch are prefixed with a plus (+) symbol:
+that only exist in the <head> branch are prefixed with a plus (+) symbol:
__*__*__*__*__> <upstream>
@@ -292,8 +340,8 @@ that only exist in the <head> branch are prefixed with a plus (+) symbol:<
fork-point
\__+__+__-__+__+__-__+__> <head>
-
If a <limit> has been given then the commits along the <head> branch up
-to and including <limit> are not reported:
+
If a <limit> has been given then the commits along the <head> branch up
+to and including <limit> are not reported:
__*__*__*__*__> <upstream>
@@ -301,15 +349,15 @@ to and including <limit> are not reported:
fork-point
\__*__*__<limit>__-__+__> <head>
-
Because git-cherry compares the changeset rather than the commit id
-(sha1), you can use git-cherry to find out if a commit you made locally
+
Because git-cherry compares the changeset rather than the commit id
+(sha1), you can use git-cherry to find out if a commit you made locally
has been applied <upstream> under a different commit id. For example,
this will happen if you're feeding patches <upstream> via email rather
-than pushing or pulling commits directly.
+than pushing or pulling commits directly.
-OPTIONS
+OPTIONS
-
+
-v
@@ -342,27 +390,27 @@ than pushing or pulling commits directly.
Do not report commits up to (and including) limit.
-
+
-SEE ALSO
+SEE ALSO
-Author
+Author
-
Written by Junio C Hamano <junkio@cox.net>
+
Written by Junio C Hamano <junkio@cox.net>
-Documentation
+Documentation
-
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-cherry.txt b/git-cherry.txt
index 9859bc8f2..d761a7342 100644
--- a/git-cherry.txt
+++ b/git-cherry.txt
@@ -14,7 +14,7 @@ DESCRIPTION
The changeset (or "diff") of each commit between the fork-point and
is compared against each commit between the fork-point and .
The commits are compared with their 'patch id', obtained from
-the `git-patch-id` program.
+the 'git-patch-id' program.
Every commit that doesn't exist in the branch
has its id (sha1) reported, prefixed by a symbol. The ones that have
@@ -37,8 +37,8 @@ to and including are not reported:
\__*__*____-__+__>
-Because `git-cherry` compares the changeset rather than the commit id
-(sha1), you can use `git-cherry` to find out if a commit you made locally
+Because 'git-cherry' compares the changeset rather than the commit id
+(sha1), you can use 'git-cherry' to find out if a commit you made locally
has been applied under a different commit id. For example,
this will happen if you're feeding patches via email rather
than pushing or pulling commits directly.
diff --git a/git-citool.html b/git-citool.html
index 75c82276f..812b40012 100644
--- a/git-citool.html
+++ b/git-citool.html
@@ -3,7 +3,7 @@
-
+
git-citool(1)
@@ -272,32 +320,32 @@ git-citool(1) Manual Page
SYNOPSIS
-DESCRIPTION
+DESCRIPTION
-
A Tcl/Tk based graphical interface to review modified files, stage
+
A Tcl/Tk based graphical interface to review modified files, stage
them into the index, enter a commit message and record the new
commit onto the current branch. This interface is an alternative
-to the less interactive git-commit program.
-
git-citool is actually a standard alias for git gui citool .
-See git-gui(1) for more details.
+to the less interactive
git-commit program.
+
git-citool is actually a standard alias for git gui citool .
+See git-gui(1) for more details.
-Author
+Author
-
Written by Shawn O. Pearce <spearce@spearce.org>.
+
Written by Shawn O. Pearce <spearce@spearce.org>.
-Documentation
+Documentation
-
Documentation by Shawn O. Pearce <spearce@spearce.org>.
+
Documentation by Shawn O. Pearce <spearce@spearce.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-citool.txt b/git-citool.txt
index 8e6c7e67c..670cb02b6 100644
--- a/git-citool.txt
+++ b/git-citool.txt
@@ -14,9 +14,9 @@ DESCRIPTION
A Tcl/Tk based graphical interface to review modified files, stage
them into the index, enter a commit message and record the new
commit onto the current branch. This interface is an alternative
-to the less interactive `git-commit` program.
+to the less interactive 'git-commit' program.
-`git-citool` is actually a standard alias for `git gui citool`.
+'git-citool' is actually a standard alias for `git gui citool`.
See linkgit:git-gui[1] for more details.
Author
diff --git a/git-clean.html b/git-clean.html
index bef7d1102..0fc3e0c28 100644
--- a/git-clean.html
+++ b/git-clean.html
@@ -3,7 +3,7 @@
-
+
git-clean(1)
@@ -275,18 +323,18 @@ git-clean(1) Manual Page
git clean [-d] [-f] [-n] [-q] [-x | -X] [--] <paths>…
-DESCRIPTION
+DESCRIPTION
-
Removes files unknown to git. This allows to clean the working tree
+
Removes files unknown to git. This allows to clean the working tree
from files that are not under version control. If the -x option is
specified, ignored files are also removed, allowing to remove all
build products.
When optional <paths>… arguments are given, the paths
-affected are further limited to those that match them.
+affected are further limited to those that match them.
-OPTIONS
+OPTIONS
-
+
-d
@@ -301,7 +349,7 @@ affected are further limited to those that match them.
If the git configuration specifies clean.requireForce as true,
- git-clean will refuse to run unless given -f or -n.
+ git-clean will refuse to run unless given -f or -n.
@@ -334,7 +382,7 @@ affected are further limited to those that match them.
Don't use the ignore rules. This allows removing all untracked
files, including build products. This can be used (possibly in
- conjunction with git-reset ) to create a pristine
+ conjunction with git-reset ) to create a pristine
working directory to test a clean build.
@@ -347,19 +395,19 @@ affected are further limited to those that match them.
everything from scratch, but keep manually created files.
-
+
-Author
+Author
-
Written by Pavel Roskin <proski@gnu.org>
+
Written by Pavel Roskin <proski@gnu.org>
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-clean.txt b/git-clean.txt
index 8168bf3bf..7dcc1ba58 100644
--- a/git-clean.txt
+++ b/git-clean.txt
@@ -27,7 +27,7 @@ OPTIONS
-f::
If the git configuration specifies clean.requireForce as true,
- `git-clean` will refuse to run unless given -f or -n.
+ 'git-clean' will refuse to run unless given -f or -n.
-n::
--dry-run::
@@ -41,7 +41,7 @@ OPTIONS
-x::
Don't use the ignore rules. This allows removing all untracked
files, including build products. This can be used (possibly in
- conjunction with `git-reset`) to create a pristine
+ conjunction with 'git-reset') to create a pristine
working directory to test a clean build.
-X::
diff --git a/git-clone.html b/git-clone.html
index 37bd14dcc..4b8ba1d74 100644
--- a/git-clone.html
+++ b/git-clone.html
@@ -3,7 +3,7 @@
-
+
git-clone(1)
@@ -278,24 +326,24 @@ git-clone(1) Manual Page
[-o <name>] [-u <upload-pack>] [--reference <repository>]
[--depth <depth>] [--] <repository> [<directory>]
-DESCRIPTION
+DESCRIPTION
-
Clones a repository into a newly created directory, creates
+
Clones a repository into a newly created directory, creates
remote-tracking branches for each branch in the cloned repository
(visible using git branch -r ), and creates and checks out an initial
-branch equal to the cloned repository's currently active branch.
-
After the clone, a plain git fetch without arguments will update
+branch equal to the cloned repository's currently active branch.
+
After the clone, a plain git fetch without arguments will update
all the remote-tracking branches, and a git pull without
arguments will in addition merge the remote master branch into the
-current master branch, if any.
-
This default configuration is achieved by creating references to
+current master branch, if any.
+
This default configuration is achieved by creating references to
the remote branch heads under $GIT_DIR/refs/remotes/origin and
by initializing remote.origin.url and remote.origin.fetch
-configuration variables.
+configuration variables.
-OPTIONS
+OPTIONS
-
+
--local
@@ -342,15 +390,15 @@ configuration variables.
with the source repository. The resulting repository
starts out without any object of its own.
-NOTE : this is a possibly dangerous operation; do not use
+
NOTE : this is a possibly dangerous operation; do not use
it unless you understand what it does. If you clone your
repository using this option and then delete branches (or use any
other git command that makes any existing commit unreferenced) in the
source repository, some objects may become unreferenced (or dangling).
-These objects may be removed by normal git operations (such as git-commit )
+These objects may be removed by normal git operations (such as git-commit )
which automatically call git gc --auto . (See git-gc(1) .)
If these objects are removed and were referenced by the cloned repository,
-then the cloned repository will become corrupt.
+then the cloned repository will become corrupt.
--reference <repository>
@@ -364,7 +412,7 @@ then the cloned repository will become corrupt.
require fewer objects to be copied from the repository
being cloned, reducing network and local storage costs.
-NOTE : see NOTE to --shared option.
+NOTE : see NOTE to --shared option.
--quiet
@@ -375,7 +423,7 @@ then the cloned repository will become corrupt.
Operate quietly. This flag is passed to "rsync" and
- git-fetch-pack commands when given.
+ git-fetch-pack commands when given.
@@ -427,7 +475,7 @@ then the cloned repository will become corrupt.
When given, and the repository to clone from is handled
- by git-fetch-pack , --exec=<upload-pack> is passed to
+ by git-fetch-pack , --exec=<upload-pack> is passed to
the command to specify non-default path for the command
run on the other end.
@@ -478,15 +526,15 @@ then the cloned repository will become corrupt.
is not allowed.
-
+
-GIT URLS
+GIT URLS
-
One of the following notations can be used
-to name the remote repository:
+
One of the following notations can be used
+to name the remote repository:
-
SSH is the default transport protocol over the network. You can
+
SSH is the default transport protocol over the network. You can
optionally specify which user to log-in as, and an alternate,
scp-like syntax is also supported. Both syntaxes support
username expansion, as does the native git protocol, but
only the former supports port specification. The following
-three are identical to the last three above, respectively:
+three are identical to the last three above, respectively:
-
+
[user@]host.xz:/path/to/repo.git/
@@ -558,12 +606,12 @@ three are identical to the last three above, respectively:
[user@]host.xz:path/to/repo.git
-
+
-
To sync with a local directory, you can use:
+
To sync with a local directory, you can use:
-
They are equivalent, except the former implies --local option.
-
If there are a large number of similarly-named remote repositories and
+
They are equivalent, except the former implies --local option.
+
If there are a large number of similarly-named remote repositories and
you want to use a different format for them (such that the URLs you
use will be rewritten into URLs that work), you can create a
-configuration section of the form:
+configuration section of the form:
[url "<actual url base>"]
insteadOf = <other url base>
-
For example, with this:
+
[url "git://git.host.xz/"]
insteadOf = host.xz:/path/to/
insteadOf = work:
-
a URL like "work:repo.git" or like "host.xz:/path/to/repo.git" will be
-rewritten in any context that takes a URL to be "git://git.host.xz/repo.git".
+
a URL like "work:repo.git" or like "host.xz:/path/to/repo.git" will be
+rewritten in any context that takes a URL to be "git://git.host.xz/repo.git".
-Examples
+Examples
-
+
Clone from upstream
@@ -652,23 +700,23 @@ Create a repository on the kernel.org machine that borrows from Linus
/pub/scm/.../me/subsys-2.6.git
-
+
-Author
+Author
-
Written by Linus Torvalds <torvalds@osdl.org>
+
Written by Linus Torvalds <torvalds@osdl.org>
-Documentation
+Documentation
-
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-clone.txt b/git-clone.txt
index eef95a404..91efac920 100644
--- a/git-clone.txt
+++ b/git-clone.txt
@@ -68,7 +68,7 @@ it unless you understand what it does. If you clone your
repository using this option and then delete branches (or use any
other git command that makes any existing commit unreferenced) in the
source repository, some objects may become unreferenced (or dangling).
-These objects may be removed by normal git operations (such as `git-commit`)
+These objects may be removed by normal git operations (such as 'git-commit')
which automatically call `git gc --auto`. (See linkgit:git-gc[1].)
If these objects are removed and were referenced by the cloned repository,
then the cloned repository will become corrupt.
@@ -88,7 +88,7 @@ then the cloned repository will become corrupt.
--quiet::
-q::
Operate quietly. This flag is passed to "rsync" and
- `git-fetch-pack` commands when given.
+ 'git-fetch-pack' commands when given.
--no-checkout::
-n::
@@ -114,7 +114,7 @@ then the cloned repository will become corrupt.
--upload-pack ::
-u ::
When given, and the repository to clone from is handled
- by `git-fetch-pack`, `--exec=` is passed to
+ by 'git-fetch-pack', `--exec=` is passed to
the command to specify non-default path for the command
run on the other end.
diff --git a/git-commit-tree.html b/git-commit-tree.html
index 0e5372683..1f832dfb7 100644
--- a/git-commit-tree.html
+++ b/git-commit-tree.html
@@ -3,7 +3,7 @@
-
+
git-commit-tree(1)
@@ -272,30 +320,30 @@ git-commit-tree(1) Manual Page
SYNOPSIS
-
git commit-tree <tree> [-p <parent commit>]* < changelog
+
git commit-tree <tree> [-p <parent commit>]* < changelog
-DESCRIPTION
+DESCRIPTION
-
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
+
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
+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.
-
While a tree represents a particular directory state of a working
+that led to them.
+
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.
-
Normally a commit would identify a new "HEAD" state, and while git
+to get there.
+
Normally a commit would identify a new "HEAD" state, and while git
doesn't care where you save the note about that state, in practice we
tend to just write the result to the file that is pointed at by
.git/HEAD , so that we can always see what the last committed
-state was.
+state was.
-OPTIONS
+OPTIONS
-
+
<tree>
@@ -312,12 +360,12 @@ state was.
Each -p indicates the id of a parent commit object.
-
+
-Commit Information
+
-
A commit encapsulates:
-
+
+
all parent object ids
@@ -333,10 +381,10 @@ author name, email and date
committer name and email and the commit time.
-
-
While parent object ids are provided on the command line, author and
+
+While parent object ids are provided on the command line, author and
committer information is taken from the following environment variables,
-if set:
+if set:
GIT_AUTHOR_NAME
@@ -347,17 +395,17 @@ GIT_COMMITTER_EMAIL
GIT_COMMITTER_DATE
EMAIL
-(nb "<", ">" and "\n"s are stripped)
-In case (some of) these environment variables are not set, the information
+
(nb "<", ">" and "\n"s are stripped)
+In case (some of) these environment variables are not set, the information
is taken from the configuration items user.name and user.email, or, if not
-present, system user name and fully qualified hostname.
-
A commit comment is read from stdin. If a changelog
-entry is not provided via "<" redirection, git-commit-tree will just wait
-for one to be entered and terminated with ^D.
+present, system user name and fully qualified hostname.
+A commit comment is read from stdin. If a changelog
+entry is not provided via "<" redirection, git-commit-tree will just wait
+for one to be entered and terminated with ^D.
-Diagnostics
+Diagnostics
-
+
You don't exist. Go away!
@@ -382,12 +430,12 @@ Your sysadmin must hate you!
The password(5) name field is longer than a giant static buffer.
-
+
-Discussion
+Discussion
-
At the core level, git is character encoding agnostic.
-
+At the core level, git is character encoding agnostic.
+
-
Although we encourage that the commit log messages are encoded
+
+Although we encourage that the commit log messages are encoded
in UTF-8, both the core and git Porcelain are designed not to
force UTF-8 on projects. If all participants of a particular
project find it more convenient to use legacy encodings, git
does not forbid it. However, there are a few things to keep in
-mind.
-
+mind.
+
-git-commit-tree (hence, git-commit which uses it) issues
+git-commit-tree (hence, git-commit which uses it) issues
a warning if the commit log message given to it does not look
like a valid UTF-8 string, unless you explicitly say your
project uses a legacy encoding. The way to say this is to
@@ -432,14 +480,14 @@ mind.
[i18n]
commitencoding = ISO-8859-1
-Commit objects created with the above setting record the value
+
Commit objects created with the above setting record the value
of i18n.commitencoding in its encoding header. This is to
help other people who look at them later. Lack of this header
-implies that the commit log message is encoded in UTF-8.
+implies that the commit log message is encoded in UTF-8.
-git-log , git-show and friends looks at the encoding
+git-log , git-show and friends looks at the encoding
header of a commit object, and tries to re-code the log
message into UTF-8 unless otherwise specified. You can
specify the desired output encoding with
@@ -450,34 +498,34 @@ implies that the commit log message is encoded in UTF-8.
[i18n]
logoutputencoding = ISO-8859-1
-If you do not have this configuration variable, the value of
-i18n.commitencoding is used instead.
+If you do not have this configuration variable, the value of
+i18n.commitencoding is used instead.
-
-Note that we deliberately chose not to re-code the commit log
+
+
Note that we deliberately chose not to re-code the commit log
message when a commit is made to force UTF-8 at the commit
object level, because re-coding to UTF-8 is not necessarily a
-reversible operation.
+reversible operation.
-SEE ALSO
+SEE ALSO
-Author
+Author
-
Written by Linus Torvalds <torvalds@osdl.org>
+
Written by Linus Torvalds <torvalds@osdl.org>
-Documentation
+Documentation
-
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-commit-tree.txt b/git-commit-tree.txt
index 9cd8d07c8..feec58400 100644
--- a/git-commit-tree.txt
+++ b/git-commit-tree.txt
@@ -70,7 +70,7 @@ is taken from the configuration items user.name and user.email, or, if not
present, system user name and fully qualified hostname.
A commit comment is read from stdin. If a changelog
-entry is not provided via "<" redirection, `git-commit-tree` will just wait
+entry is not provided via "<" redirection, 'git-commit-tree' will just wait
for one to be entered and terminated with ^D.
diff --git a/git-commit.html b/git-commit.html
index 696c0cbf2..e18732ada 100644
--- a/git-commit.html
+++ b/git-commit.html
@@ -3,7 +3,7 @@
-
+
git-commit(1)
@@ -278,22 +326,22 @@ git-commit(1) Manual Page
[--allow-empty] [--no-verify] [-e] [--author=<author>]
[--cleanup=<mode>] [--] [[-i | -o ]<file>…]
-DESCRIPTION
+DESCRIPTION
-
Use git commit to store the current contents of the index in a new
-commit along with a log message describing the changes you have made.
-
The content to be added can be specified in several ways:
-
+Stores the current contents of the index in a new commit along
+with a log message from the user describing the changes.
+The content to be added can be specified in several ways:
+
-by using git-add to incrementally "add" changes to the
+by using git-add to incrementally "add" changes to the
index before using the commit command (Note: even modified
files must be "added");
-by using git-rm to remove files from the working tree
+by using git-rm to remove files from the working tree
and the index, again before using the commit command;
@@ -317,20 +365,20 @@ by using the -a switch with the commit command to automatically
by using the --interactive switch with the commit command to decide one
by one which files should be part of the commit, before finalizing the
- operation. Currently, this is done by invoking git-add --interactive .
+ operation. Currently, this is done by invoking git-add --interactive .
-
-
The git-status command can be used to obtain a
+
+The git-status command can be used to obtain a
summary of what is included by any of the above for the next
commit by giving the same set of parameters you would give to
-this command.
-
If you make a commit and then find a mistake immediately after
-that, you can recover from it with git-reset .
+this command.
+If you make a commit and then find a mistake immediately after
+that, you can recover from it with git-reset .
-OPTIONS
+OPTIONS
-
+
-a
@@ -493,7 +541,7 @@ that, you can recover from it with git-reset .
the current tip as parents — so the current top commit is
discarded.
-It is a rough equivalent for:
+It is a rough equivalent for:
$ git reset --soft HEAD^
@@ -501,7 +549,7 @@ that, you can recover from it with git-reset .
$ git commit -c ORIG_HEAD
-but can be used to amend a merge commit.
+but can be used to amend a merge commit.
-i
@@ -528,7 +576,7 @@ that, you can recover from it with git-reset .
Make a commit only from the paths specified on the
command line, disregarding any contents that have been
staged so far. This is the default mode of operation of
- git commit if any paths are given on the command line,
+ git-commit if any paths are given on the command line,
in which case this option can be omitted.
If this option is specified together with --amend , then
no paths need be specified, which can be used to amend
@@ -546,9 +594,9 @@ that, you can recover from it with git-reset .
Show untracked files (Default: all ).
-The mode parameter is optional, and is used to specify
-the handling of untracked files. The possible options are:
-
+The mode parameter is optional, and is used to specify
+the handling of untracked files. The possible options are:
+
+See git-config(1) for configuration variable
used to change the default for when the option is not
-specified.
+specified.
-v
@@ -614,21 +662,21 @@ specified.
of what have been staged before.
-
+
-EXAMPLES
+EXAMPLES
-
When recording your own work, the contents of modified files in
+
When recording your own work, the contents of modified files in
your working tree are temporarily stored to a staging area
-called the "index" with git-add . A file can be
+called the "index" with git-add . A file can be
reverted back, only in the index but not in the working tree,
to that of the last commit with git reset HEAD — <file> ,
-which effectively reverts git-add and prevents the changes to
+which effectively reverts git-add and prevents the changes to
this file from participating in the next commit. After building
the state to be committed incrementally with these commands,
git commit (without any pathname parameter) is used to record what
has been staged so far. This is the most basic form of the
-command. An example:
+command. An example:
$ edit hello.c
@@ -636,25 +684,25 @@ $ git rm goodbye.c
$ git add hello.c
$ git commit
-
Instead of staging files after each individual change, you can
+
Instead of staging files after each individual change, you can
tell git commit to notice the changes to the files whose
contents are tracked in
your working tree and do corresponding git add and git rm
for you. That is, this example does the same as the earlier
-example if there is no other change in your working tree:
+example if there is no other change in your working tree:
$ edit hello.c
$ rm goodbye.c
$ git commit -a
-
The command git commit -a first looks at your working tree,
+
The command git commit -a first looks at your working tree,
notices that you have modified hello.c and removed goodbye.c,
-and performs necessary git add and git rm for you.
-
After staging changes to many files, you can alter the order the
+and performs necessary git add and git rm for you.
+
After staging changes to many files, you can alter the order the
changes are recorded in, by giving pathnames to git commit .
When pathnames are given, the command makes a commit that
-only records the changes made to the named paths:
+only records the changes made to the named paths:
$ edit hello.c hello.h
@@ -662,24 +710,24 @@ $ git add hello.c hello.h
$ edit Makefile
$ git commit Makefile
-
This makes a commit that records the modification to Makefile .
+
This makes a commit that records the modification to Makefile .
The changes staged for hello.c and hello.h are not included
in the resulting commit. However, their changes are not lost —
they are still staged and merely held back. After the above
-sequence, if you do:
+sequence, if you do:
-
this second commit would record the changes to hello.c and
-hello.h as expected.
-
After a merge (initiated by git-merge or git-pull ) stops
+
this second commit would record the changes to hello.c and
+hello.h as expected.
+
After a merge (initiated by git-merge or git-pull ) stops
because of conflicts, cleanly merged
paths are already staged to be committed for you, and paths that
conflicted are left in unmerged state. You would have to first
-check which paths are conflicting with git-status
+check which paths are conflicting with git-status
and after fixing them manually in your working tree, you would
-stage the result as usual with git-add :
+stage the result as usual with
git-add :
$ git status | grep unmerged
@@ -687,29 +735,29 @@ unmerged: hello.c
$ edit hello.c
$ git add hello.c
-
After resolving conflicts and staging the result, git ls-files -u
+
After resolving conflicts and staging the result, git ls-files -u
would stop mentioning the conflicted path. When you are done,
-run git commit to finally record the merge:
+run
git commit to finally record the merge:
-
As with the case to record your own changes, you can use -a
+
As with the case to record your own changes, you can use -a
option to save typing. One difference is that during a merge
resolution, you cannot use git commit with pathnames to
alter the order the changes are committed, because the merge
should be recorded as a single commit. In fact, the command
-refuses to run when given pathnames (but see -i option).
+refuses to run when given pathnames (but see
-i option).
-DISCUSSION
+DISCUSSION
-
Though not required, it's a good idea to begin the commit message
+
Though not required, it's a good idea to begin the commit message
with a single short (less than 50 character) line summarizing the
change, followed by a blank line and then a more thorough description.
Tools that turn commits into email, for example, use the first line
-on the Subject: line and the rest of the commit in the body.
-
At the core level, git is character encoding agnostic.
-
+on the Subject: line and the rest of the commit in the body.
+
At the core level, git is character encoding agnostic.
+
-
Although we encourage that the commit log messages are encoded
+
+
Although we encourage that the commit log messages are encoded
in UTF-8, both the core and git Porcelain are designed not to
force UTF-8 on projects. If all participants of a particular
project find it more convenient to use legacy encodings, git
does not forbid it. However, there are a few things to keep in
-mind.
-
+mind.
+
-git-commit-tree (hence, git-commit which uses it) issues
+git-commit-tree (hence, git-commit which uses it) issues
a warning if the commit log message given to it does not look
like a valid UTF-8 string, unless you explicitly say your
project uses a legacy encoding. The way to say this is to
@@ -754,14 +802,14 @@ mind.
[i18n]
commitencoding = ISO-8859-1
-Commit objects created with the above setting record the value
+
Commit objects created with the above setting record the value
of i18n.commitencoding in its encoding header. This is to
help other people who look at them later. Lack of this header
-implies that the commit log message is encoded in UTF-8.
+implies that the commit log message is encoded in UTF-8.
-git-log , git-show and friends looks at the encoding
+git-log , git-show and friends looks at the encoding
header of a commit object, and tries to re-code the log
message into UTF-8 unless otherwise specified. You can
specify the desired output encoding with
@@ -772,48 +820,48 @@ implies that the commit log message is encoded in UTF-8.
[i18n]
logoutputencoding = ISO-8859-1
-If you do not have this configuration variable, the value of
-i18n.commitencoding is used instead.
+If you do not have this configuration variable, the value of
+i18n.commitencoding is used instead.
-
-Note that we deliberately chose not to re-code the commit log
+
+
Note that we deliberately chose not to re-code the commit log
message when a commit is made to force UTF-8 at the commit
object level, because re-coding to UTF-8 is not necessarily a
-reversible operation.
+reversible operation.
-ENVIRONMENT AND CONFIGURATION VARIABLES
+ENVIRONMENT AND CONFIGURATION VARIABLES
-
The editor used to edit the commit log message will be chosen from the
+
The editor used to edit the commit log message will be chosen from the
GIT_EDITOR environment variable, the core.editor configuration variable, the
VISUAL environment variable, or the EDITOR environment variable (in that
-order).
+order).
-HOOKS
+HOOKS
-
This command can run commit-msg , prepare-commit-msg , pre-commit ,
+
This command can run commit-msg , prepare-commit-msg , pre-commit ,
and post-commit hooks. See githooks(5) for more
-information.
+information.
-SEE ALSO
+SEE ALSO
-Author
+Author
-
Written by Linus Torvalds <torvalds@osdl.org> and
-Junio C Hamano <junkio@cox.net>
+
Written by Linus Torvalds <torvalds@osdl.org> and
+Junio C Hamano <junkio@cox.net>
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-commit.txt b/git-commit.txt
index 03594cd5d..01bd2d6b7 100644
--- a/git-commit.txt
+++ b/git-commit.txt
@@ -15,16 +15,16 @@ SYNOPSIS
DESCRIPTION
-----------
-Use 'git commit' to store the current contents of the index in a new
-commit along with a log message describing the changes you have made.
+Stores the current contents of the index in a new commit along
+with a log message from the user describing the changes.
The content to be added can be specified in several ways:
-1. by using `git-add` to incrementally "add" changes to the
+1. by using 'git-add' to incrementally "add" changes to the
index before using the 'commit' command (Note: even modified
files must be "added");
-2. by using `git-rm` to remove files from the working tree
+2. by using 'git-rm' to remove files from the working tree
and the index, again before using the 'commit' command;
3. by listing files as arguments to the 'commit' command, in which
@@ -39,15 +39,15 @@ The content to be added can be specified in several ways:
5. by using the --interactive switch with the 'commit' command to decide one
by one which files should be part of the commit, before finalizing the
- operation. Currently, this is done by invoking `git-add --interactive`.
+ operation. Currently, this is done by invoking 'git-add --interactive'.
-The `git-status` command can be used to obtain a
+The 'git-status' command can be used to obtain a
summary of what is included by any of the above for the next
commit by giving the same set of parameters you would give to
this command.
If you make a commit and then find a mistake immediately after
-that, you can recover from it with `git-reset`.
+that, you can recover from it with 'git-reset'.
OPTIONS
@@ -155,7 +155,7 @@ but can be used to amend a merge commit.
Make a commit only from the paths specified on the
command line, disregarding any contents that have been
staged so far. This is the default mode of operation of
- 'git commit' if any paths are given on the command line,
+ 'git-commit' if any paths are given on the command line,
in which case this option can be omitted.
If this option is specified together with '--amend', then
no paths need be specified, which can be used to amend
@@ -205,10 +205,10 @@ EXAMPLES
--------
When recording your own work, the contents of modified files in
your working tree are temporarily stored to a staging area
-called the "index" with `git-add`. A file can be
+called the "index" with 'git-add'. A file can be
reverted back, only in the index but not in the working tree,
to that of the last commit with `git reset HEAD -- `,
-which effectively reverts `git-add` and prevents the changes to
+which effectively reverts 'git-add' and prevents the changes to
this file from participating in the next commit. After building
the state to be committed incrementally with these commands,
`git commit` (without any pathname parameter) is used to record what
@@ -264,13 +264,13 @@ $ git commit
this second commit would record the changes to `hello.c` and
`hello.h` as expected.
-After a merge (initiated by `git-merge` or `git-pull`) stops
+After a merge (initiated by 'git-merge' or 'git-pull') stops
because of conflicts, cleanly merged
paths are already staged to be committed for you, and paths that
conflicted are left in unmerged state. You would have to first
-check which paths are conflicting with `git-status`
+check which paths are conflicting with 'git-status'
and after fixing them manually in your working tree, you would
-stage the result as usual with `git-add`:
+stage the result as usual with 'git-add':
------------
$ git status | grep unmerged
diff --git a/git-config.html b/git-config.html
index d2df6d30c..ad33cf1db 100644
--- a/git-config.html
+++ b/git-config.html
@@ -3,7 +3,7 @@
-
+
git-config(1)
@@ -287,29 +335,29 @@ git-config(1) Manual Page
git config [<file-option>] --get-color name [default]
git config [<file-option>] --get-colorbool name [stdout-is-tty]
-DESCRIPTION
+DESCRIPTION
-
You can query/set/replace/unset options with this command. The name is
+
You can query/set/replace/unset options with this command. The name is
actually the section and the key separated by a dot, and the value will be
-escaped.
-
Multiple lines can be added to an option by using the --add option.
+escaped.
+
Multiple lines can be added to an option by using the --add option.
If you want to update or unset an option which can occur on multiple
lines, a POSIX regexp value_regex needs to be given. Only the
existing values that match the regexp are updated or unset. If
you want to handle the lines that do not match the regex, just
-prepend a single exclamation mark in front (see also [EXAMPLES] ).
-
The type specifier can be either --int or --bool , which will make
-git-config ensure that the variable(s) are of the given type and
+prepend a single exclamation mark in front (see also [EXAMPLES] ).
+
The type specifier can be either --int or --bool , which will make
+git-config ensure that the variable(s) are of the given type and
convert the value to the canonical form (simple decimal number for int,
a "true" or "false" string for bool). If no type specifier is passed,
-no checks or transformations are performed on the value.
-
The file-option can be one of --system , --global or --file
+no checks or transformations are performed on the value.
+
The file-option can be one of --system , --global or --file
which specify where the values will be read from or written to.
The default is to assume the config file of the current repository,
.git/config unless defined otherwise with GIT_DIR and GIT_CONFIG
-(see [FILES] ).
-
This command will fail if:
-
+(see [FILES] ).
+
This command will fail if:
+
The config file is invalid,
@@ -345,11 +393,11 @@ you try to unset/set an option for which multiple lines match, or
you use --global option without $HOME being properly set.
-
+
-OPTIONS
+OPTIONS
-
+
--replace-all
@@ -404,9 +452,9 @@ you use --global option without $HOME being properly set.
For writing options: write to global ~/.gitconfig file rather than
the repository .git/config.
-For reading options: read only from global ~/.gitconfig rather than
-from all available files.
-See also [FILES] .
+For reading options: read only from global ~/.gitconfig rather than
+from all available files.
+
--system
@@ -416,9 +464,9 @@ from all available files.
For writing options: write to system-wide $(prefix)/etc/gitconfig
rather than the repository .git/config.
-For reading options: read only from system-wide $(prefix)/etc/gitconfig
-rather than from all available files.
-See also [FILES] .
+For reading options: read only from system-wide $(prefix)/etc/gitconfig
+rather than from all available files.
+
-f config-file
@@ -479,7 +527,7 @@ rather than from all available files.
- git-config will ensure that the output is "true" or "false"
+ git-config will ensure that the output is "true" or "false"
@@ -487,7 +535,7 @@ rather than from all available files.
- git-config will ensure that the output is a simple
+ git-config will ensure that the output is a simple
decimal number. An optional value suffix of k , m , or g
in the config file will cause the value to be multiplied
by 1024, 1048576, or 1073741824 prior to output.
@@ -535,13 +583,13 @@ rather than from all available files.
there is no color configured for name .
-
+
- FILES
+FILES
-
If not set explicitly with --file , there are three files where
-git-config will search for configuration options:
-
+If not set explicitly with --file , there are three files where
+git-config will search for configuration options:
+
$GIT_DIR/config
@@ -569,27 +617,27 @@ $(prefix)/etc/gitconfig
System-wide configuration file.
-
-
If no further options are given, all reading options will read all of these
+
+If no further options are given, all reading options will read all of these
files that are available. If the global or the system-wide configuration
file are not available they will be ignored. If the repository configuration
-file is not available or readable, git-config will exit with a non-zero
-error code. However, in neither case will an error message be issued.
-
All writing options will per default write to the repository specific
+file is not available or readable, git-config will exit with a non-zero
+error code. However, in neither case will an error message be issued.
+All writing options will per default write to the repository specific
configuration file. Note that this also affects options like --replace-all
-and --unset . git-config will only ever change one file at a time .
-
You can override these rules either by command line options or by environment
+and --unset . git-config will only ever change one file at a time .
+You can override these rules either by command line options or by environment
variables. The --global and the --system options will limit the file used
to the global or system-wide file respectively. The GIT_CONFIG environment
-variable has a similar effect, but you can specify any filename you want.
-
The GIT_CONFIG_LOCAL environment variable on the other hand only changes
+variable has a similar effect, but you can specify any filename you want.
+The GIT_CONFIG_LOCAL environment variable on the other hand only changes
the name used instead of the repository configuration file. The global and
the system-wide configuration files will still be read. (For writing options
-this will obviously result in the same behavior as using GIT_CONFIG.)
+this will obviously result in the same behavior as using GIT_CONFIG.)
-ENVIRONMENT
+ENVIRONMENT
-
+
GIT_CONFIG
@@ -609,12 +657,12 @@ GIT_CONFIG_LOCAL
Still read the global and the system-wide configuration files, though.
-
-
See also [FILES] .
+
+
- EXAMPLES
+EXAMPLES
-
Given a .git/config like this:
+
Given a .git/config like this:
#
@@ -644,70 +692,70 @@ GIT_CONFIG_LOCAL
gitproxy="proxy-command" for kernel.org
gitproxy=default-proxy ; for all the rest
-
you can set the filemode to true with
+
you can set the filemode to true with
% git config core.filemode true
-
The hypothetical proxy command entries actually have a postfix to discern
+
The hypothetical proxy command entries actually have a postfix to discern
what URL they apply to. Here is how to change the entry for kernel.org
-to "ssh".
+to "ssh".
% git config core.gitproxy '"ssh" for kernel.org' 'for kernel.org$'
-
This makes sure that only the key/value pair for kernel.org is replaced.
-
To delete the entry for renames, do
+
This makes sure that only the key/value pair for kernel.org is replaced.
+
To delete the entry for renames, do
% git config --unset diff.renames
-
If you want to delete an entry for a multivar (like core.gitproxy above),
-you have to provide a regex matching the value of exactly one line.
-
To query the value for a given key, do
+
If you want to delete an entry for a multivar (like core.gitproxy above),
+you have to provide a regex matching the value of exactly one line.
+
To query the value for a given key, do
% git config --get core.filemode
-
or
+
% git config core.filemode
-
or, to query a multivar:
+
% git config --get core.gitproxy "for kernel.org$"
-
If you want to know all the values for a multivar, do:
+
If you want to know all the values for a multivar, do:
% git config --get-all core.gitproxy
-
If you like to live dangerous, you can replace all core.gitproxy by a
-new one with
+
If you like to live dangerous, you can replace all core.gitproxy by a
+new one with
% git config --replace-all core.gitproxy ssh
-
However, if you really only want to replace the line for the default proxy,
-i.e. the one without a "for …" postfix, do something like this:
+
However, if you really only want to replace the line for the default proxy,
+i.e. the one without a "for …" postfix, do something like this:
% git config core.gitproxy ssh '! for '
-
To actually match only values with an exclamation mark, you have to
+
To actually match only values with an exclamation mark, you have to
% git config section.key value '[!]'
-
To add a new proxy, without altering any of the existing ones, use
+
To add a new proxy, without altering any of the existing ones, use
% git config core.gitproxy '"proxy-command" for example.com'
-
An example to use customized color from the configuration in your
-script:
+
An example to use customized color from the configuration in your
+script:
#!/bin/sh
@@ -716,74 +764,74 @@ RESET=$(git config --get-color "" "reset")
echo "${WS}your whitespace color or blue reverse${RESET}"
-CONFIGURATION FILE
+CONFIGURATION FILE
-
The git configuration file contains a number of variables that affect
+
The git configuration file contains a number of variables that affect
the git command's behavior. .git/config file for each repository
is used to store the information for that repository, and
$HOME/.gitconfig is used to store per user information to give
fallback values for .git/config file. The file /etc/gitconfig
-can be used to store system-wide defaults.
-
They can be used by both the git plumbing
+can be used to store system-wide defaults.
+
They can be used by both the git plumbing
and the porcelains. The variables are divided into sections, where
in the fully qualified variable name the variable itself is the last
dot-separated segment and the section name is everything before the last
dot. The variable names are case-insensitive and only alphanumeric
-characters are allowed. Some variables may appear multiple times.
-
Syntax
-
The syntax is fairly flexible and permissive; whitespaces are mostly
+characters are allowed. Some variables may appear multiple times.
+
Syntax
+
The syntax is fairly flexible and permissive; whitespaces are mostly
ignored. The # and ; characters begin comments to the end of line,
-blank lines are ignored.
-
The file consists of sections and variables. A section begins with
+blank lines are ignored.
+
The file consists of sections and variables. A section begins with
the name of the section in square brackets and continues until the next
section begins. Section names are not case sensitive. Only alphanumeric
characters, - and . are allowed in section names. Each variable
must belong to some section, which means that there must be section
-header before first setting of a variable.
-
Sections can be further divided into subsections. To begin a subsection
+header before first setting of a variable.
+
Sections can be further divided into subsections. To begin a subsection
put its name in double quotes, separated by space from the section name,
-in the section header, like in example below:
+in the section header, like in example below:
-
Subsection names can contain any characters except newline (doublequote
+
Subsection names can contain any characters except newline (doublequote
" and backslash have to be escaped as \" and \\ ,
respectively) and are case sensitive. Section header cannot span multiple
lines. Variables may belong directly to a section or to a given subsection.
You can have [section] if you have [section "subsection"] , but you
-don't need to.
-
There is also (case insensitive) alternative [section.subsection] syntax.
+don't need to.
+
There is also (case insensitive) alternative [section.subsection] syntax.
In this syntax subsection names follow the same restrictions as for section
-name.
-
All the other lines are recognized as setting variables, in the form
+name.
+
All the other lines are recognized as setting variables, in the form
name = value . If there is no equal sign on the line, the entire line
is taken as name and the variable is recognized as boolean "true".
The variable names are case-insensitive and only alphanumeric
characters and - are allowed. There can be more than one value
-for a given variable; we say then that variable is multivalued.
-
Leading and trailing whitespace in a variable value is discarded.
-Internal whitespace within a variable value is retained verbatim.
-
The values following the equals sign in variable assign are all either
+for a given variable; we say then that variable is multivalued.
+
Leading and trailing whitespace in a variable value is discarded.
+Internal whitespace within a variable value is retained verbatim.
+
The values following the equals sign in variable assign are all either
a string, an integer, or a boolean. Boolean values may be given as yes/no,
0/1 or true/false. Case is not significant in boolean values, when
converting value to the canonical form using --bool type specifier;
-git-config will ensure that the output is "true" or "false".
-
String values may be entirely or partially enclosed in double quotes.
+git-config will ensure that the output is "true" or "false".
+
String values may be entirely or partially enclosed in double quotes.
You need to enclose variable value in double quotes if you want to
preserve leading or trailing whitespace, or if variable value contains
beginning of comment characters (if it contains # or ; ).
Double quote " and backslash \ characters in variable value must
-be escaped: use \" for " and \\ for \ .
-
The following escape sequences (beside \" and \\ ) are recognized:
+be escaped: use \" for " and \\ for \ .
+
The following escape sequences (beside \" and \\ ) are recognized:
\n for newline character (NL), \t for horizontal tabulation (HT, TAB)
and \b for backspace (BS). No other char escape sequence, nor octal
-char sequences are valid.
-
Variable value ending in a \ is continued on the next line in the
-customary UNIX fashion.
-
Some variables may require special value format.
-
Example
+char sequences are valid.
+
Variable value ending in a \ is continued on the next line in the
+customary UNIX fashion.
+
Some variables may require special value format.
+
Example
# Core variables
@@ -811,12 +859,12 @@ customary UNIX fashion.
gitProxy="ssh" for "kernel.org"
gitProxy=default-proxy ; for the rest
-
Variables
-
Note that this list is non-comprehensive and not necessarily complete.
+
Variables
+
Note that this list is non-comprehensive and not necessarily complete.
For command-specific variables, you will find a more detailed description
in the appropriate manual page. You will find a description of non-core
-porcelain configuration variables in the respective porcelain documentation.
-
+porcelain configuration variables in the respective porcelain documentation.
+
core.fileMode
@@ -832,8 +880,8 @@ core.quotepath
- The commands that output paths (e.g. ls-files ,
- diff ), when not given the -z option, will quote
+ The commands that output paths (e.g. ls-files ,
+ diff ), when not given the -z option, will quote
"unusual" characters in the pathname by enclosing the
pathname in a double-quote pair and with backslashes the
same way strings in C source code are quoted. If this
@@ -874,27 +922,27 @@ core.safecrlf
be set to "warn", in which case git will only warn about an
irreversible conversion but continue the operation.
-CRLF conversion bears a slight chance of corrupting data.
+
CRLF conversion bears a slight chance of corrupting data.
autocrlf=true will convert CRLF to LF during commit and LF to
CRLF during checkout. A file that contains a mixture of LF and
CRLF before the commit cannot be recreated by git. For text
files this is the right thing to do: it corrects line endings
such that we have only LF line endings in the repository.
But for binary files that are accidentally classified as text the
-conversion can corrupt data.
-
If you recognize such corruption early you can easily fix it by
+conversion can corrupt data.
+If you recognize such corruption early you can easily fix it by
setting the conversion type explicitly in .gitattributes. Right
after committing you still have the original file in your work
tree and this file is not yet corrupted. You can explicitly tell
git that this file is binary and git will handle the file
-appropriately.
-
Unfortunately, the desired effect of cleaning up text files with
+appropriately.
+Unfortunately, the desired effect of cleaning up text files with
mixed line endings and the undesired effect of corrupting binary
files cannot be distinguished. In both cases CRLFs are removed
in an irreversible way. For text files this is the right thing
to do because CRLFs are line endings, while for binary files
-converting CRLFs corrupts data.
-
Note, this safety check does not mean that a checkout will generate a
+converting CRLFs corrupts data.
+Note, this safety check does not mean that a checkout will generate a
file identical to the original file for a different setting of
core.autocrlf , but only for the current one. For example, a text
file with LF would be accepted with core.autocrlf=input and could
@@ -903,7 +951,7 @@ resulting file would contain CRLF , although the original file
contained LF . However, in both work trees the line endings would be
consistent, that is either all LF or all CRLF , but never mixed. A
file with mixed line endings would be reported by the core.safecrlf
-mechanism.
+mechanism.
core.symlinks
@@ -930,9 +978,9 @@ core.gitProxy
may be set multiple times and is matched in the given order;
the first match wins.
-Can be overridden by the GIT_PROXY_COMMAND environment variable
+
Can be overridden by the GIT_PROXY_COMMAND environment variable
(which always applies universally, without the special "for"
-handling).
+handling).
core.ignoreStat
@@ -970,11 +1018,11 @@ core.bare
number of commands that require a working directory will be
disabled, such as git-add(1) or git-merge(1) .
-This setting is automatically guessed by git-clone(1) or
+
This setting is automatically guessed by git-clone(1) or
git-init(1) when the repository was created. By default a
repository that ends in "/.git" is assumed to be not bare (bare =
false), while all other repositories are assumed to be bare (bare
-= true).
+= true).
core.worktree
@@ -1006,11 +1054,11 @@ core.logAllRefUpdates
variable is set to true, missing "$GIT_DIR/logs/<ref>"
file is automatically created for branch heads.
-This information can be used to determine what commit
-was the tip of a branch "2 days ago".
-This value is true by default in a repository that has
+
This information can be used to determine what commit
+was the tip of a branch "2 days ago".
+This value is true by default in a repository that has
a working directory associated with it, and false by
-default in a bare repository.
+default in a bare repository.
core.repositoryFormatVersion
@@ -1085,11 +1133,11 @@ core.packedGitWindowSize
memory manager, but may improve performance when accessing
a large number of large pack files.
-Default is 1 MiB if NO_MMAP was set at compile time, otherwise 32
+
Default is 1 MiB if NO_MMAP was set at compile time, otherwise 32
MiB on 32 bit platforms and 1 GiB on 64 bit platforms. This should
be reasonable for all users/operating systems. You probably do
-not need to adjust this value.
-
Common unit suffixes of k , m , or g are supported.
+not need to adjust this value.
+Common unit suffixes of k , m , or g are supported.
core.packedGitLimit
@@ -1101,10 +1149,10 @@ core.packedGitLimit
bytes at once to complete an operation it will unmap existing
regions to reclaim virtual address space within the process.
-Default is 256 MiB on 32 bit platforms and 8 GiB on 64 bit platforms.
+
Default is 256 MiB on 32 bit platforms and 8 GiB on 64 bit platforms.
This should be reasonable for all users/operating systems, except on
-the largest projects. You probably do not need to adjust this value.
-
Common unit suffixes of k , m , or g are supported.
+the largest projects. You probably do not need to adjust this value.
+Common unit suffixes of k , m , or g are supported.
core.deltaBaseCacheLimit
@@ -1117,10 +1165,10 @@ core.deltaBaseCacheLimit
to avoid unpacking and decompressing frequently used base
objects multiple times.
-Default is 16 MiB on all platforms. This should be reasonable
+
Default is 16 MiB on all platforms. This should be reasonable
for all users/operating systems, except on the largest projects.
-You probably do not need to adjust this value.
-
Common unit suffixes of k , m , or g are supported.
+You probably do not need to adjust this value.
+Common unit suffixes of k , m , or g are supported.
core.excludesfile
@@ -1161,11 +1209,11 @@ core.whitespace
A comma separated list of common whitespace problems to
- notice. git diff will use color.diff.whitespace to
- highlight them, and git apply --whitespace=error will
+ notice. git-diff will use color.diff.whitespace to
+ highlight them, and git-apply --whitespace=error will
consider them as errors:
-
core.fsyncobjectfiles
@@ -1202,10 +1250,10 @@ core.fsyncobjectfiles
This boolean will enable fsync() when writing object files.
-This is a total waste of time and effort on a filesystem that orders
+
This is a total waste of time and effort on a filesystem that orders
data writes properly, but can be useful for filesystems that do not use
journalling (traditional UNIX filesystems) or that only journal metadata
-and not file contents (OS X's HFS+, or Linux ext3 with "data=writeback").
+and not file contents (OS X's HFS+, or Linux ext3 with "data=writeback").
alias.*
@@ -1220,18 +1268,18 @@ alias.*
spaces, the usual shell quoting and escaping is supported.
quote pair and a backslash can be used to quote them.
-If the alias expansion is prefixed with an exclamation point,
+
If the alias expansion is prefixed with an exclamation point,
it will be treated as a shell command. For example, defining
"alias.new = !gitk --all --not ORIG_HEAD", the invocation
"git new" is equivalent to running the shell command
-"gitk --all --not ORIG_HEAD".
+"gitk --all --not ORIG_HEAD".
apply.whitespace
- Tells git-apply how to handle whitespaces, in the same way
+ Tells git-apply how to handle whitespaces, in the same way
as the --whitespace option. See git-apply(1) .
@@ -1240,7 +1288,7 @@ branch.autosetupmerge
- Tells git-branch and git-checkout to setup new branches
+ Tells git-branch and git-checkout to setup new branches
so that git-pull(1) will appropriately merge from the
starting point branch. Note that even if this option is not set,
this behavior can be chosen per-branch using the --track
@@ -1256,7 +1304,7 @@ branch.autosetuprebase
- When a new branch is created with git-branch or git-checkout
+ When a new branch is created with git-branch or git-checkout
that tracks another branch, this variable tells git to set
up pull to rebase instead of merge (see "branch.<name>.rebase").
When never , rebase is never automatically set to true.
@@ -1276,8 +1324,8 @@ branch.<name>.remote
- When in branch <name>, it tells git fetch which remote to fetch.
- If this option is not given, git fetch defaults to remote "origin".
+ When in branch <name>, it tells git-fetch which remote to fetch.
+ If this option is not given, git-fetch defaults to remote "origin".
@@ -1285,16 +1333,16 @@ branch.<name>.merge
- When in branch <name>, it tells git fetch the default
+ When in branch <name>, it tells git-fetch the default
refspec to be marked for merging in FETCH_HEAD. The value is
handled like the remote part of a refspec, and must match a
ref which is fetched from the remote given by
"branch.<name>.remote".
- The merge information is used by git pull (which at first calls
- git fetch ) to lookup the default branch for merging. Without
- this option, git pull defaults to merge the first refspec fetched.
+ The merge information is used by git-pull (which at first calls
+ git-fetch ) to lookup the default branch for merging. Without
+ this option, git-pull defaults to merge the first refspec fetched.
Specify multiple values to get an octopus merge.
- If you wish to setup git pull so that it merges into <name> from
+ If you wish to setup git-pull so that it merges into <name> from
another branch in the local repository, you can point
branch.<name>.merge to the desired branch, and use the special setting
. (a period) for branch.<name>.remote.
@@ -1374,13 +1422,13 @@ color.branch.<slot>
remote (a tracking branch in refs/remotes/), plain (other
refs).
-The value for these configuration variables is a list of colors (at most
+
The value for these configuration variables is a list of colors (at most
two) and attributes (at most one), separated by spaces. The colors
accepted are normal , black , red , green , yellow , blue ,
magenta , cyan and white ; the attributes are bold , dim , ul ,
blink and reverse . The first color given is the foreground; the
second is the background. The position of the attribute, if any,
-doesn't matter.
+doesn't matter.
color.diff
@@ -1412,7 +1460,7 @@ color.interactive
When set to always , always use colors for interactive prompts
- and displays (such as those used by "git add --interactive").
+ and displays (such as those used by "git-add --interactive").
When false (or never ), never. When set to true or auto , use
colors only when the output is to the terminal. Defaults to false.
@@ -1422,7 +1470,7 @@ color.interactive.<slot>
- Use customized color for git add --interactive
+ Use customized color for git-add --interactive
output. <slot> may be prompt , header , or help , for
three distinct types of normal output from interactive
programs. The values of these variables may be specified as
@@ -1489,14 +1537,14 @@ diff.autorefreshindex
- When using git diff to compare with work tree
+ When using git-diff to compare with work tree
files, do not consider stat-only change as changed.
Instead, silently run git update-index --refresh to
update the cached stat information for paths whose
contents in the work tree match the contents in the
index. This option defaults to true. Note that this
- affects only git diff Porcelain, and not lower level
- diff commands, such as git diff-files .
+ affects only git-diff Porcelain, and not lower level
+ diff commands, such as git-diff-files .
@@ -1517,7 +1565,7 @@ diff.renameLimit
The number of files to consider when performing the copy/rename
- detection; equivalent to the git diff option -l .
+ detection; equivalent to the git-diff option -l .
@@ -1592,7 +1640,7 @@ gc.aggressiveWindow
The window size parameter used in the delta compression
- algorithm used by git gc --aggressive . This defaults
+ algorithm used by git-gc --aggressive . This defaults
to 10.
@@ -1624,15 +1672,15 @@ gc.packrefs
- git gc does not run git pack-refs in a bare repository by
+ git-gc does not run git pack-refs in a bare repository by
default so that older dumb-transport clients can still fetch
- from the repository. Setting this to true lets git
- gc to run git pack-refs . Setting this to false tells
- git gc never to run git pack-refs . The default setting is
+ from the repository. Setting this to true lets git-gc
+ to run git pack-refs . Setting this to false tells
+ git-gc never to run git pack-refs . The default setting is
notbare . Enable it only when you know you do not have to
support such clients. The default setting will change to true
at some stage, and setting this to false will continue to
- prevent git pack-refs from being run from git gc .
+ prevent git pack-refs from being run from git-gc .
@@ -1640,7 +1688,7 @@ gc.pruneexpire
- When git gc is run, it will call prune --expire 2.weeks.ago .
+ When git-gc is run, it will call prune --expire 2.weeks.ago .
Override the grace period with this config variable.
@@ -1649,7 +1697,7 @@ gc.reflogexpire
- git reflog expire removes reflog entries older than
+ git-reflog expire removes reflog entries older than
this time; defaults to 90 days.
@@ -1658,7 +1706,7 @@ gc.reflogexpireunreachable
- git reflog expire removes reflog entries older than
+ git-reflog expire removes reflog entries older than
this time and are not reachable from the current tip;
defaults to 30 days.
@@ -1669,7 +1717,7 @@ gc.rerereresolved
Records of conflicted merge you resolved earlier are
- kept for this many days when git rerere gc is run.
+ kept for this many days when git-rerere gc is run.
The default is 60 days. See git-rerere(1) .
@@ -1679,7 +1727,7 @@ gc.rerereunresolved
Records of conflicted merge you have not resolved are
- kept for this many days when git rerere gc is run.
+ kept for this many days when git-rerere gc is run.
The default is 15 days. See git-rerere(1) .
@@ -1713,16 +1761,16 @@ gitcvs.logfile
various stuff. See git-cvsserver(1) .
-
-
gitcvs.usecrlfattr
+
+
gitcvs.usecrlfattr
If true, the server will look up the crlf attribute for
files to determine the -k modes to use. If crlf is set,
the -k mode will be left blank, so cvs clients will
treat it as text. If crlf is explicitly unset, the file
will be set with -kb mode, which supresses any newline munging
the client might otherwise do. If crlf is not specified,
- then gitcvs.allbinary is used. See gitattribute(5) .
-
+ then gitcvs.allbinary is used. See gitattribute(5) .
+
gitcvs.allbinary
@@ -1787,13 +1835,13 @@ gitcvs.dbTableNamePrefix
characters will be replaced with underscores.
-
-
All gitcvs variables except for gitcvs.usecrlfattr and
+
+
All gitcvs variables except for gitcvs.usecrlfattr and
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.
-
+access method.
+
gui.commitmsgwidth
@@ -1987,7 +2035,7 @@ i18n.logOutputEncoding
Character encoding the commit messages are converted to when
- running git-log and friends.
+ running git-log and friends.
@@ -2040,7 +2088,7 @@ log.date
Set default date-time mode for the log command. Setting log.date
- value is similar to using git log's --date option. The value is one of
+ value is similar to using git-log 's --date option. The value is one of the
following alternatives: {relative,local,default,iso,rfc,short}.
See git-log(1) .
@@ -2304,13 +2352,13 @@ pack.indexVersion
and this config option ignored whenever the corresponding pack is
larger than 2 GB.
-If you have an old git that does not understand the version 2 *.idx file,
+
If you have an old git that does not understand the version 2 *.idx file,
cloning or fetching over a non native protocol (e.g. "http" and "rsync")
that will copy both *.pack file and corresponding *.idx file from the
other side may give you a repository that cannot be accessed with your
older version of git. If the *.pack file is smaller than 2 GB, however,
you can use git-index-pack(1) on the *.pack file to regenerate
-the *.idx file.
+the
*.idx file.
pack.packSizeLimit
@@ -2477,7 +2525,7 @@ status.showUntrackedFiles
systems. So, this variable controls how the commands displays
the untracked files. Possible values are:
-
+
-
If this variable is not specified, it defaults to normal .
+
+
tar.umask
@@ -2624,23 +2672,23 @@ web.browser
may use it.
-
+
-Author
+Author
-
Written by Johannes Schindelin <Johannes.Schindelin@gmx.de>
+
Written by Johannes Schindelin <Johannes.Schindelin@gmx.de>
-Documentation
+Documentation
-
Documentation by Johannes Schindelin, Petr Baudis and the git-list <git@vger.kernel.org>.
+
Documentation by Johannes Schindelin, Petr Baudis and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-config.txt b/git-config.txt
index 63ddb2c2f..df419e21f 100644
--- a/git-config.txt
+++ b/git-config.txt
@@ -37,7 +37,7 @@ you want to handle the lines that do *not* match the regex, just
prepend a single exclamation mark in front (see also <>).
The type specifier can be either '--int' or '--bool', which will make
-`git-config` ensure that the variable(s) are of the given type and
+'git-config' ensure that the variable(s) are of the given type and
convert the value to the canonical form (simple decimal number for int,
a "true" or "false" string for bool). If no type specifier is passed,
no checks or transformations are performed on the value.
@@ -122,10 +122,10 @@ See also <>.
List all variables set in config file.
--bool::
- `git-config` will ensure that the output is "true" or "false"
+ 'git-config' will ensure that the output is "true" or "false"
--int::
- `git-config` will ensure that the output is a simple
+ 'git-config' will ensure that the output is a simple
decimal number. An optional value suffix of 'k', 'm', or 'g'
in the config file will cause the value to be multiplied
by 1024, 1048576, or 1073741824 prior to output.
@@ -162,7 +162,7 @@ FILES
-----
If not set explicitly with '--file', there are three files where
-`git-config` will search for configuration options:
+'git-config' will search for configuration options:
$GIT_DIR/config::
Repository specific configuration file. (The filename is
@@ -179,12 +179,12 @@ $(prefix)/etc/gitconfig::
If no further options are given, all reading options will read all of these
files that are available. If the global or the system-wide configuration
file are not available they will be ignored. If the repository configuration
-file is not available or readable, `git-config` will exit with a non-zero
+file is not available or readable, 'git-config' will exit with a non-zero
error code. However, in neither case will an error message be issued.
All writing options will per default write to the repository specific
configuration file. Note that this also affects options like '--replace-all'
-and '--unset'. *`git-config` will only ever change one file at a time*.
+and '--unset'. *'git-config' will only ever change one file at a time*.
You can override these rules either by command line options or by environment
variables. The '--global' and the '--system' options will limit the file used
diff --git a/git-cvsexportcommit.html b/git-cvsexportcommit.html
index 054ce6240..17648b87e 100644
--- a/git-cvsexportcommit.html
+++ b/git-cvsexportcommit.html
@@ -3,7 +3,7 @@
-
+
git-cvsexportcommit(1)
@@ -272,26 +320,26 @@ git-cvsexportcommit(1) Manual Page
SYNOPSIS
-
git cvsexportcommit [-h] [-u] [-v] [-c] [-P] [-p] [-a] [-d cvsroot]
- [-w cvsworkdir] [-W] [-f] [-m msgprefix] [PARENTCOMMIT] COMMITID
+
git cvsexportcommit [-h] [-u] [-v] [-c] [-P] [-p] [-a] [-d cvsroot]
+ [-w cvsworkdir] [-W] [-f] [-m msgprefix] [PARENTCOMMIT] COMMITID
-DESCRIPTION
+DESCRIPTION
-
Exports a commit from GIT to a CVS checkout, making it easier
-to merge patches from a git repository into a CVS repository.
-
Specify the name of a CVS checkout using the -w switch or execute it
+
Exports a commit from GIT to a CVS checkout, making it easier
+to merge patches from a git repository into a CVS repository.
+
Specify the name of a CVS checkout using the -w switch or execute it
from the root of the CVS working copy. In the latter case GIT_DIR must
-be defined. See examples below.
-
It does its best to do the safe thing, it will check that the files are
+be defined. See examples below.
+
It does its best to do the safe thing, it will check that the files are
unchanged and up to date in the CVS checkout, and it will not autocommit
-by default.
-
Supports file additions, removals, and commits that affect binary files.
-
If the commit is a merge commit, you must tell git-cvsexportcommit what
-parent the changeset should be done against.
+by default.
+
Supports file additions, removals, and commits that affect binary files.
+
If the commit is a merge commit, you must tell git-cvsexportcommit what
+parent the changeset should be done against.
-OPTIONS
+OPTIONS
-
+
-c
@@ -391,11 +439,11 @@ parent the changeset should be done against.
Verbose.
-
+
-CONFIGURATION
+CONFIGURATION
-
+
cvsexportcommit.cvsdir
@@ -404,11 +452,11 @@ cvsexportcommit.cvsdir
The default location of the CVS checkout to use for the export.
-
+
-EXAMPLES
+EXAMPLES
-
+
Merge one patch into CVS
@@ -441,23 +489,23 @@ $ cd ~/project_cvs_checkout
$ git cherry cvshead myhead | sed -n 's/^+ //p' | xargs -l1 git cvsexportcommit -c -p -v
-
+
-Author
+Author
-
Written by Martin Langhoff <martin@catalyst.net.nz> and others.
+
Written by Martin Langhoff <martin@catalyst.net.nz> and others.
-Documentation
+Documentation
-
Documentation by Martin Langhoff <martin@catalyst.net.nz> and others.
+
Documentation by Martin Langhoff <martin@catalyst.net.nz> and others.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-cvsexportcommit.txt b/git-cvsexportcommit.txt
index 2a02ffa7c..2da8588f4 100644
--- a/git-cvsexportcommit.txt
+++ b/git-cvsexportcommit.txt
@@ -27,7 +27,7 @@ by default.
Supports file additions, removals, and commits that affect binary files.
-If the commit is a merge commit, you must tell `git-cvsexportcommit` what
+If the commit is a merge commit, you must tell 'git-cvsexportcommit' what
parent the changeset should be done against.
OPTIONS
diff --git a/git-cvsimport.html b/git-cvsimport.html
index 2de1108e8..8ba337273 100644
--- a/git-cvsimport.html
+++ b/git-cvsimport.html
@@ -3,7 +3,7 @@
-
+
git-cvsimport(1)
@@ -279,22 +327,27 @@ git-cvsimport(1) Manual Page
[-a] [-m] [-M <regex>] [-S <regex>] [-L <commitlimit>]
[-r <remote>] [<CVS_module>]
-DESCRIPTION
+DESCRIPTION
-
Imports a CVS repository into git. It will either create a new
-repository, or incrementally import into an existing one.
-
Splitting the CVS log into patch sets is done by cvsps .
-At least version 2.1 is required.
-
You should never do any work of your own on the branches that are
-created by git-cvsimport . By default initial import will create and populate a
+
Imports a CVS repository into git. It will either create a new
+repository, or incrementally import into an existing one.
+
Splitting the CVS log into patch sets is done by cvsps .
+At least version 2.1 is required.
+
You should never do any work of your own on the branches that are
+created by git-cvsimport . By default initial import will create and populate a
"master" branch from the CVS repository's main branch which you're free
-to work with; after that, you need to git-merge incremental imports, or
+to work with; after that, you need to git-merge incremental imports, or
any CVS branches, yourself. It is advisable to specify a named remote via
--r to separate and protect the incoming branches.
+-r to separate and protect the incoming branches.
+
If you intend to set up a shared public repository that all developers can
+read/write, or if you want to use git-cvsserver(1) , then you
+probably want to make a bare clone of the imported repository,
+and use the clone as the shared repository.
+See gitcvs-migration(7) .
-OPTIONS
+OPTIONS
-
+
-v
@@ -310,7 +363,7 @@ any CVS branches, yourself. It is advisable to specify a named remote via
The root of the CVS archive. May be local (a simple path) or remote;
currently, only the :local:, :ext: and :pserver: access methods
- are supported. If not given, git-cvsimport will try to read it
+ are supported. If not given, git-cvsimport will try to read it
from CVS/Root . If no such file exists, it checks for the
CVSROOT environment variable.
@@ -321,7 +374,7 @@ any CVS branches, yourself. It is advisable to specify a named remote via
The CVS module you want to import. Relative to <CVSROOT>.
- If not given, git-cvsimport tries to read it from
+ If not given, git-cvsimport tries to read it from
CVS/Repository .
@@ -341,7 +394,7 @@ any CVS branches, yourself. It is advisable to specify a named remote via
The git remote to import this CVS repository into.
Moves all CVS branches into remotes/<remote>/<branch>
- akin to the git-clone "--use-separate-remote" option.
+ akin to the git-clone "--use-separate-remote" option.
@@ -353,12 +406,12 @@ any CVS branches, yourself. It is advisable to specify a named remote via
from CVS is imported to the origin branch within the git
repository, as HEAD already has a special meaning for git.
When a remote is specified the HEAD branch is named
- remotes/<remote>/master mirroring git-clone behaviour.
+ remotes/<remote>/master mirroring git-clone behaviour.
Use this option if you want to import into a different
branch.
-Use -o master for continuing an import that was initially done by
-the old cvs2git tool.
+Use -o master for continuing an import that was initially done by
+the old cvs2git tool.
-i
@@ -404,7 +457,7 @@ the old cvs2git tool.
Additional options for cvsps.
The options -u and -A are implicit and should not be used here.
-If you need to pass multiple options, separate them with a comma.
+If you need to pass multiple options, separate them with a comma.
-z <fuzz>
@@ -443,8 +496,8 @@ the old cvs2git tool.
regex. It can be used with -m to enable the default regexes
as well. You must escape forward slashes.
-The regex must capture the source branch name in $1.
-This option can be used several times to provide several detection regexes.
+The regex must capture the source branch name in $1.
+This option can be used several times to provide several detection regexes.
-S <regex>
@@ -487,15 +540,15 @@ the old cvs2git tool.
spawn=Simon Pawn <spawn@frog-pond.org>
-git-cvsimport will make it appear as those authors had
+
git-cvsimport will make it appear as those authors had
their GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL set properly
-all along.
-
For convenience, this data is saved to $GIT_DIR/cvs-authors
+all along.
+For convenience, this data is saved to $GIT_DIR/cvs-authors
each time the -A option is provided and read from that same
-file each time git-cvsimport is run.
-
It is not recommended to use this feature if you intend to
+file each time git-cvsimport is run.
+It is not recommended to use this feature if you intend to
export changes back to CVS again later with
-git-cvsexportcommit .
+
git-cvsexportcommit .
-h
@@ -505,30 +558,30 @@ export changes back to CVS again later with
Print a short usage message and exit.
-
+
-OUTPUT
+OUTPUT
-
If -v is specified, the script reports what it is doing.
-
Otherwise, success is indicated the Unix way, i.e. by simply exiting with
-a zero exit status.
+
If -v is specified, the script reports what it is doing.
+
Otherwise, success is indicated the Unix way, i.e. by simply exiting with
+a zero exit status.
-Author
+Author
-
Written by Matthias Urlichs <smurf@smurf.noris.de>, with help from
-various participants of the git-list <git@vger.kernel.org>.
+
Written by Matthias Urlichs <smurf@smurf.noris.de>, with help from
+various participants of the git-list <git@vger.kernel.org>.
-Documentation
+Documentation
-
Documentation by Matthias Urlichs <smurf@smurf.noris.de>.
+
Documentation by Matthias Urlichs <smurf@smurf.noris.de>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-cvsimport.txt b/git-cvsimport.txt
index ed79bb8d5..b7a8c10b8 100644
--- a/git-cvsimport.txt
+++ b/git-cvsimport.txt
@@ -25,12 +25,18 @@ Splitting the CVS log into patch sets is done by 'cvsps'.
At least version 2.1 is required.
You should *never* do any work of your own on the branches that are
-created by `git-cvsimport`. By default initial import will create and populate a
+created by 'git-cvsimport'. By default initial import will create and populate a
"master" branch from the CVS repository's main branch which you're free
-to work with; after that, you need to `git-merge` incremental imports, or
+to work with; after that, you need to 'git-merge' incremental imports, or
any CVS branches, yourself. It is advisable to specify a named remote via
-r to separate and protect the incoming branches.
+If you intend to set up a shared public repository that all developers can
+read/write, or if you want to use linkgit:git-cvsserver[1], then you
+probably want to make a bare clone of the imported repository,
+and use the clone as the shared repository.
+See linkgit:gitcvs-migration[7].
+
OPTIONS
-------
@@ -40,13 +46,13 @@ OPTIONS
-d ::
The root of the CVS archive. May be local (a simple path) or remote;
currently, only the :local:, :ext: and :pserver: access methods
- are supported. If not given, `git-cvsimport` will try to read it
+ are supported. If not given, 'git-cvsimport' will try to read it
from `CVS/Root`. If no such file exists, it checks for the
`CVSROOT` environment variable.
::
The CVS module you want to import. Relative to .
- If not given, `git-cvsimport` tries to read it from
+ If not given, 'git-cvsimport' tries to read it from
`CVS/Repository`.
-C ::
@@ -56,14 +62,14 @@ OPTIONS
-r ::
The git remote to import this CVS repository into.
Moves all CVS branches into remotes//
- akin to the `git-clone` "--use-separate-remote" option.
+ akin to the 'git-clone' "--use-separate-remote" option.
-o ::
When no remote is specified (via -r) the 'HEAD' branch
from CVS is imported to the 'origin' branch within the git
repository, as 'HEAD' already has a special meaning for git.
When a remote is specified the 'HEAD' branch is named
- remotes//master mirroring `git-clone` behaviour.
+ remotes//master mirroring 'git-clone' behaviour.
Use this option if you want to import into a different
branch.
+
@@ -136,17 +142,17 @@ This option can be used several times to provide several detection regexes.
---------
+
-`git-cvsimport` will make it appear as those authors had
+'git-cvsimport' will make it appear as those authors had
their GIT_AUTHOR_NAME and GIT_AUTHOR_EMAIL set properly
all along.
+
For convenience, this data is saved to `$GIT_DIR/cvs-authors`
each time the '-A' option is provided and read from that same
-file each time `git-cvsimport` is run.
+file each time 'git-cvsimport' is run.
+
It is not recommended to use this feature if you intend to
export changes back to CVS again later with
-`git-cvsexportcommit`.
+'git-cvsexportcommit'.
-h::
Print a short usage message and exit.
diff --git a/git-cvsserver.html b/git-cvsserver.html
index 51269ed60..15935567a 100644
--- a/git-cvsserver.html
+++ b/git-cvsserver.html
@@ -3,7 +3,7 @@
-
+
git-cvsserver(1)
@@ -272,23 +320,23 @@ git-cvsserver(1) Manual Page
SYNOPSIS
-
SSH:
+
export CVS_SERVER=git-cvsserver
cvs -d :ext:user@server/path/repo.git co <HEAD_name>
-
pserver (/etc/inetd.conf):
+
pserver (/etc/inetd.conf):
cvspserver stream tcp nowait nobody /usr/bin/git-cvsserver git-cvsserver pserver
-
Usage:
+
git cvsserver [options] [pserver|server] [<directory> …]
-OPTIONS
+OPTIONS
-
All these options obviously only make sense if enforced by the server side.
+
All these options obviously only make sense if enforced by the server side.
They have been implemented to resemble the git-daemon(1) options as
-closely as possible.
-
+closely as possible.
+
--base-path <path>
@@ -350,29 +398,29 @@ access still needs to be enabled by the gitcvs.enabled config option
unless --export-all was given, too.
-
+
-DESCRIPTION
+DESCRIPTION
-
This application is a CVS emulation layer for git.
-
It is highly functional. However, not all methods are implemented,
+
This application is a CVS emulation layer for git.
+
It is highly functional. However, not all methods are implemented,
and for those methods that are implemented,
-not all switches are implemented.
-
Testing has been done using both the CLI CVS client, and the Eclipse CVS
-plugin. Most functionality works fine with both of these clients.
+not all switches are implemented.
+
Testing has been done using both the CLI CVS client, and the Eclipse CVS
+plugin. Most functionality works fine with both of these clients.
-LIMITATIONS
+LIMITATIONS
-
Currently cvsserver works over SSH connections for read/write clients, and
-over pserver for anonymous CVS access.
-
CVS clients cannot tag, branch or perform GIT merges.
-
git-cvsserver maps GIT branches to CVS modules. This is very different
+
Currently cvsserver works over SSH connections for read/write clients, and
+over pserver for anonymous CVS access.
+
CVS clients cannot tag, branch or perform GIT merges.
+
git-cvsserver maps GIT branches to CVS modules. This is very different
from what most CVS users would expect since in CVS modules usually represent
-one or more directories.
+one or more directories.
-INSTALLATION
+INSTALLATION
-
+
If you are going to offer anonymous CVS access via pserver, add a line in
@@ -383,29 +431,29 @@ If you are going to offer anonymous CVS access via pserver, add a line in
cvspserver stream tcp nowait nobody git-cvsserver pserver
-Note: Some inetd servers let you specify the name of the executable
+
Note: Some inetd servers let you specify the name of the executable
independently of the value of argv[0] (i.e. the name the program assumes
it was executed with). In this case the correct line in /etc/inetd.conf
-looks like
+looks like
cvspserver stream tcp nowait nobody /usr/bin/git-cvsserver git-cvsserver pserver
-No special setup is needed for SSH access, other than having GIT tools
+
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
-CVS_SERVER directly in CVSROOT like
+environment variable, you can rename
git-cvsserver to
cvs .
+Note: Newer CVS versions (>= 1.12.11) also support specifying
+CVS_SERVER directly in CVSROOT like
cvs -d ":ext;CVS_SERVER=git-cvsserver:user@server/path/repo.git" co <HEAD_name>
-This has the advantage that it will be saved in your CVS/Root files and
+
This has the advantage that it will be saved in your CVS/Root files and
you don't need to worry about always setting the correct environment
-variable. SSH users restricted to git-shell don't need to override the default
-with CVS_SERVER (and shouldn't) as git-shell understands cvs to mean
-git-cvsserver and pretends that the other end runs the real cvs better.
+variable. SSH users restricted to
git-shell don't need to override the default
+with CVS_SERVER (and shouldn't) as
git-shell understands
cvs to mean
+
git-cvsserver and pretends that the other end runs the real
cvs better.
@@ -420,14 +468,16 @@ For each repo that you want accessible from CVS you need to edit config in
logfile=/path/to/logfile
-
Note: you need to ensure each user that is going to invoke git-cvsserver has
+
Note: you need to ensure each user that is going to invoke git-cvsserver has
write access to the log file and to the database (see
Database Backend . If you want to offer write access over
-SSH, the users of course also need write access to the git repository itself.
-
All configuration variables can also be overridden for a specific method of
+SSH, the users of course also need write access to the git repository itself.
+You also need to ensure that each repository is "bare" (without a git index
+file) for cvs commit to work. See gitcvs-migration(7) .
+All configuration variables can also be overridden for a specific method of
access. Valid method names are "ext" (for SSH access) and "pserver". The
following example configuration would disable pserver access while still
-allowing access over SSH.
+allowing access over SSH.
[gitcvs]
@@ -443,7 +493,7 @@ If you didn't specify the CVSROOT/CVS_SERVER directly in the checkout command,
automatically saving it in your CVS/Root files, then you need to set them
explicitly in your environment. CVSROOT should be set as per normal, but the
directory should point at the appropriate git repo. As above, for SSH clients
- _not_ restricted to git-shell , CVS_SERVER should be set to git-cvsserver .
+ not restricted to git-shell , CVS_SERVER should be set to git-cvsserver .
@@ -473,36 +523,36 @@ Clients should now be able to check out the project. Use the CVS
module
cvs co -d project-master master
-
+
- Database Backend
+Database Backend
-
git-cvsserver uses one database per git head (i.e. CVS module) to
+
git-cvsserver uses one database per git head (i.e. CVS module) to
store information about the repository for faster access. The
database doesn't contain any persistent data and can be completely
regenerated from the git repository at any time. The database
-needs to be updated (i.e. written to) after every commit.
-
If the commit is done directly by using git (as opposed to
-using git-cvsserver ) the update will need to happen on the
-next repository access by git-cvsserver , independent of
-access method and requested operation.
-
That means that even if you offer only read access (e.g. by using
-the pserver method), git-cvsserver should have write access to
+needs to be updated (i.e. written to) after every commit.
+
If the commit is done directly by using git (as opposed to
+using git-cvsserver ) the update will need to happen on the
+next repository access by git-cvsserver , independent of
+access method and requested operation.
+
That means that even if you offer only read access (e.g. by using
+the pserver method), git-cvsserver should have write access to
the database to work reliably (otherwise you need to make sure
-that the database is up-to-date any time git-cvsserver is executed).
-
By default it uses SQLite databases in the git directory, named
+that the database is up-to-date any time git-cvsserver is executed).
+
By default it uses SQLite databases in the git directory, named
gitcvs.<module_name>.sqlite . Note that the SQLite backend creates
temporary files in the same directory as the database file on
write so it might not be enough to grant the users using
-git-cvsserver write access to the database file without granting
-them write access to the directory, too.
-
You can configure the database backend with the following
-configuration variables:
-
Configuring database backend
-
git-cvsserver uses the Perl DBI module. Please also read
+git-cvsserver write access to the database file without granting
+them write access to the directory, too.
+
You can configure the database backend with the following
+configuration variables:
+
Configuring database backend
+
git-cvsserver uses the Perl DBI module. Please also read
its documentation if changing these variables, especially
-about DBI->connect() .
-
+about DBI->connect() .
+
gitcvs.dbname
@@ -558,11 +608,11 @@ gitcvs.dbTableNamePrefix
with underscores.
-
-
All variables can also be set per access method, see above .
-
Variable substitution
-
In dbdriver and dbuser you can use the following variables:
-
+
+
All variables can also be set per access method, see above .
+
Variable substitution
+
In dbdriver and dbuser you can use the following variables:
+
%G
@@ -603,17 +653,17 @@ gitcvs.dbTableNamePrefix
- Name of the user running git-cvsserver .
+ Name of the user running git-cvsserver .
If no name can be determined, the
numeric uid is used.
-
+
-Eclipse CVS Client Notes
+Eclipse CVS Client Notes
-
To get a checkout with the Eclipse CVS client:
-
+To get a checkout with the Eclipse CVS client:
+
Select "Create a new project -> From CVS checkout"
@@ -638,20 +688,20 @@ Pick HEAD when it asks what branch/tag to check out. Untick the
"launch commit wizard" to avoid committing the .project file.
-
-
Protocol notes: If you are using anonymous access via pserver, just select that.
+
+Protocol notes: If you are using anonymous access via pserver, just select that.
Those using SSH access should choose the ext protocol, and configure ext
access on the Preferences->Team->CVS->ExtConnection pane. Set CVS_SERVER to
-git-cvsserver . Note that password support is not good when using ext ,
-you will definitely want to have SSH keys setup.
-
Alternatively, you can just use the non-standard extssh protocol that Eclipse
+git-cvsserver . Note that password support is not good when using ext ,
+you will definitely want to have SSH keys setup.
+Alternatively, you can just use the non-standard extssh protocol that Eclipse
offer. In that case CVS_SERVER is ignored, and you will have to replace
-the cvs utility on the server with git-cvsserver or manipulate your .bashrc
-so that calling cvs effectively calls git-cvsserver .
+the cvs utility on the server with
git-cvsserver or manipulate your
.bashrc
+so that calling
cvs effectively calls
git-cvsserver .
-Clients known to work
+Clients known to work
-
+
CVS 1.12.9 on Debian
@@ -672,46 +722,46 @@ Eclipse 3.0, 3.1.2 on MacOSX (see Eclipse CVS Client Notes)
TortoiseCVS
-
+
-Operations supported
+Operations supported
-
All the operations required for normal use are supported, including
+
All the operations required for normal use are supported, including
checkout, diff, status, update, log, add, remove, commit.
Legacy monitoring operations are not supported (edit, watch and related).
-Exports and tagging (tags and branches) are not supported at this stage.
-
CRLF Line Ending Conversions
-
By default the server leaves the -k mode blank for all files,
+Exports and tagging (tags and branches) are not supported at this stage.
+
CRLF Line Ending Conversions
+
By default the server leaves the -k mode blank for all files,
which causes the cvs client to treat them as a text files, subject
-to crlf conversion on some platforms.
-
You can make the server use crlf attributes to set the -k modes
+to crlf conversion on some platforms.
+
You can make the server use crlf attributes to set the -k modes
for files by setting the gitcvs.usecrlfattr config variable.
In this case, if crlf is explicitly unset (-crlf ), then the
server will set -kb mode for binary files. If crlf is set,
then the -k mode will explicitly be left blank. See
also gitattributes(5) for more information about the crlf
-attribute.
-
Alternatively, if gitcvs.usecrlfattr config is not enabled
+attribute.
+
Alternatively, if gitcvs.usecrlfattr config is not enabled
or if the crlf attribute is unspecified for a filename, then
the server uses the gitcvs.allbinary config for the default setting.
If gitcvs.allbinary is set, then file not otherwise
specified will default to -kb mode. Otherwise the -k mode
is left blank. But if gitcvs.allbinary is set to "guess", then
the correct -k mode will be guessed based on the contents of
-the file.
-
For best consistency with cvs , it is probably best to override the
+the file.
+
For best consistency with cvs , it is probably best to override the
defaults by setting gitcvs.usecrlfattr to true,
-and gitcvs.allbinary to "guess".
+and
gitcvs.allbinary to "guess".
-Dependencies
+Dependencies
-
git-cvsserver depends on DBD::SQLite.
+
git-cvsserver depends on DBD::SQLite.
-Copyright and Authors
+Copyright and Authors
-
This program is copyright The Open University UK - 2006.
-
Authors:
-
+This program is copyright The Open University UK - 2006.
+
+
-
with ideas and patches from participants of the git-list <git@vger.kernel.org>.
+
+with ideas and patches from participants of the git-list <git@vger.kernel.org>.
-Documentation
+Documentation
-
Documentation by Martyn Smith <martyn@catalyst.net.nz>, Martin Langhoff <martin@catalyst.net.nz>, and Matthias Urlichs <smurf@smurf.noris.de>.
+
Documentation by Martyn Smith <martyn@catalyst.net.nz>, Martin Langhoff <martin@catalyst.net.nz>, and Matthias Urlichs <smurf@smurf.noris.de>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-cvsserver.txt b/git-cvsserver.txt
index e0e35dbbb..c2d3c90d2 100644
--- a/git-cvsserver.txt
+++ b/git-cvsserver.txt
@@ -77,7 +77,7 @@ over pserver for anonymous CVS access.
CVS clients cannot tag, branch or perform GIT merges.
-`git-cvsserver` maps GIT branches to CVS modules. This is very different
+'git-cvsserver' maps GIT branches to CVS modules. This is very different
from what most CVS users would expect since in CVS modules usually represent
one or more directories.
@@ -103,7 +103,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`.
+environment variable, you can rename 'git-cvsserver' to `cvs`.
Note: Newer CVS versions (>= 1.12.11) also support specifying
CVS_SERVER directly in CVSROOT like
@@ -113,9 +113,9 @@ cvs -d ":ext;CVS_SERVER=git-cvsserver:user@server/path/repo.git" co
------
This has the advantage that it will be saved in your 'CVS/Root' files and
you don't need to worry about always setting the correct environment
-variable. SSH users restricted to `git-shell` don't need to override the default
-with CVS_SERVER (and shouldn't) as `git-shell` understands `cvs` to mean
-`git-cvsserver` and pretends that the other end runs the real `cvs` better.
+variable. SSH users restricted to 'git-shell' don't need to override the default
+with CVS_SERVER (and shouldn't) as 'git-shell' understands `cvs` to mean
+'git-cvsserver' and pretends that the other end runs the real 'cvs' better.
--
2. For each repo that you want accessible from CVS you need to edit config in
the repo and add the following section.
@@ -128,11 +128,14 @@ with CVS_SERVER (and shouldn't) as `git-shell` understands `cvs` to mean
logfile=/path/to/logfile
------
-Note: you need to ensure each user that is going to invoke `git-cvsserver` has
+Note: you need to ensure each user that is going to invoke 'git-cvsserver' has
write access to the log file and to the database (see
<>. If you want to offer write access over
SSH, the users of course also need write access to the git repository itself.
+You also need to ensure that each repository is "bare" (without a git index
+file) for `cvs commit` to work. See linkgit:gitcvs-migration[7].
+
[[configaccessmethod]]
All configuration variables can also be overridden for a specific method of
access. Valid method names are "ext" (for SSH access) and "pserver". The
@@ -150,7 +153,7 @@ allowing access over SSH.
automatically saving it in your 'CVS/Root' files, then you need to set them
explicitly in your environment. CVSROOT should be set as per normal, but the
directory should point at the appropriate git repo. As above, for SSH clients
- _not_ restricted to `git-shell`, CVS_SERVER should be set to `git-cvsserver`.
+ _not_ restricted to 'git-shell', CVS_SERVER should be set to 'git-cvsserver'.
+
--
------
@@ -178,27 +181,27 @@ allowing access over SSH.
Database Backend
----------------
-`git-cvsserver` uses one database per git head (i.e. CVS module) to
+'git-cvsserver' uses one database per git head (i.e. CVS module) to
store information about the repository for faster access. The
database doesn't contain any persistent data and can be completely
regenerated from the git repository at any time. The database
needs to be updated (i.e. written to) after every commit.
If the commit is done directly by using `git` (as opposed to
-using `git-cvsserver`) the update will need to happen on the
-next repository access by `git-cvsserver`, independent of
+using 'git-cvsserver') the update will need to happen on the
+next repository access by 'git-cvsserver', independent of
access method and requested operation.
That means that even if you offer only read access (e.g. by using
-the pserver method), `git-cvsserver` should have write access to
+the pserver method), 'git-cvsserver' should have write access to
the database to work reliably (otherwise you need to make sure
-that the database is up-to-date any time `git-cvsserver` is executed).
+that the database is up-to-date any time 'git-cvsserver' is executed).
By default it uses SQLite databases in the git directory, named
`gitcvs..sqlite`. Note that the SQLite backend creates
temporary files in the same directory as the database file on
write so it might not be enough to grant the users using
-`git-cvsserver` write access to the database file without granting
+'git-cvsserver' write access to the database file without granting
them write access to the directory, too.
You can configure the database backend with the following
@@ -207,7 +210,7 @@ configuration variables:
Configuring database backend
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-`git-cvsserver` uses the Perl DBI module. Please also read
+'git-cvsserver' uses the Perl DBI module. Please also read
its documentation if changing these variables, especially
about `DBI->connect()`.
@@ -259,7 +262,7 @@ In `dbdriver` and `dbuser` you can use the following variables:
%a::
access method (one of "ext" or "pserver")
%u::
- Name of the user running `git-cvsserver`.
+ Name of the user running 'git-cvsserver'.
If no name can be determined, the
numeric uid is used.
@@ -280,13 +283,13 @@ To get a checkout with the Eclipse CVS client:
Protocol notes: If you are using anonymous access via pserver, just select that.
Those using SSH access should choose the 'ext' protocol, and configure 'ext'
access on the Preferences->Team->CVS->ExtConnection pane. Set CVS_SERVER to
-`git-cvsserver`. Note that password support is not good when using 'ext',
+'git-cvsserver'. Note that password support is not good when using 'ext',
you will definitely want to have SSH keys setup.
Alternatively, you can just use the non-standard extssh protocol that Eclipse
offer. In that case CVS_SERVER is ignored, and you will have to replace
-the cvs utility on the server with `git-cvsserver` or manipulate your `.bashrc`
-so that calling 'cvs' effectively calls `git-cvsserver`.
+the cvs utility on the server with 'git-cvsserver' or manipulate your `.bashrc`
+so that calling 'cvs' effectively calls 'git-cvsserver'.
Clients known to work
---------------------
@@ -328,13 +331,13 @@ is left blank. But if `gitcvs.allbinary` is set to "guess", then
the correct '-k' mode will be guessed based on the contents of
the file.
-For best consistency with `cvs`, it is probably best to override the
+For best consistency with 'cvs', it is probably best to override the
defaults by setting `gitcvs.usecrlfattr` to true,
and `gitcvs.allbinary` to "guess".
Dependencies
------------
-`git-cvsserver` depends on DBD::SQLite.
+'git-cvsserver' depends on DBD::SQLite.
Copyright and Authors
---------------------
diff --git a/git-daemon.html b/git-daemon.html
index dd8450564..ab2813389 100644
--- a/git-daemon.html
+++ b/git-daemon.html
@@ -3,7 +3,7 @@
-
+
git-daemon(1)
@@ -283,26 +331,26 @@ git-daemon(1) Manual Page
[--inetd | [--listen=host_or_ipaddr] [--port=n] [--user=user [--group=group]]
[directory…]
-DESCRIPTION
+DESCRIPTION
-
A really simple TCP git daemon that normally listens on port "DEFAULT_GIT_PORT"
+
A really simple TCP git daemon that normally listens on port "DEFAULT_GIT_PORT"
aka 9418. It waits for a connection asking for a service, and will serve
-that service if it is enabled.
-
It verifies that the directory has the magic file "git-daemon-export-ok", and
+that service if it is enabled.
+
It verifies that the directory has the magic file "git-daemon-export-ok", and
it will refuse to export any git directory that hasn't explicitly been marked
for export this way (unless the --export-all parameter is specified). If you
-pass some directory paths as git-daemon arguments, you can further restrict
-the offers to a whitelist comprising of those.
-
By default, only upload-pack service is enabled, which serves
-git-fetch-pack and git-ls-remote clients, which are invoked
-from git-fetch , git-pull , and git-clone .
-
This is ideally suited for read-only updates, i.e., pulling from
-git repositories.
-
An upload-archive also exists to serve git-archive .
+pass some directory paths as
git-daemon arguments, you can further restrict
+the offers to a whitelist comprising of those.
+
By default, only upload-pack service is enabled, which serves
+git-fetch-pack and git-ls-remote clients, which are invoked
+from git-fetch , git-pull , and git-clone .
+
This is ideally suited for read-only updates, i.e., pulling from
+git repositories.
+
An upload-archive also exists to serve git-archive .
-OPTIONS
+OPTIONS
-
+
--strict-paths
@@ -310,7 +358,7 @@ git repositories.
Match paths exactly (i.e. don't allow "/foo/repo" when the real path is
"/foo/repo.git" or "/foo/repo/.git") and don't do user-relative paths.
- git-daemon will refuse to start when this option is enabled and no
+ git-daemon will refuse to start when this option is enabled and no
whitelist is specified.
@@ -320,9 +368,9 @@ git repositories.
Remap all the path requests as relative to the given path.
- This is sort of "GIT root" - if you run git-daemon with
+ This is sort of "GIT root" - if you run git-daemon with
--base-path=/srv/git on example.com, then if you later try to pull
- git://example.com/hello.git , git-daemon will interpret the path
+ git://example.com/hello.git , git-daemon will interpret the path
as /srv/git/hello.git .
@@ -332,7 +380,7 @@ git repositories.
If --base-path is enabled and repo lookup fails, with this option
- git-daemon will attempt to lookup without prefixing the base path.
+ git-daemon will attempt to lookup without prefixing the base path.
This is useful for switching to --base-path usage, while still
allowing the old paths.
@@ -428,9 +476,9 @@ git repositories.
- Allow ~user notation to be used in requests. When
+ Allow user notation to be used in requests. When
specified with no parameter, requests to
- git://host/~alice/foo is taken as a request to access
+ git://host/ alice/foo is taken as a request to access
foo repository in the home directory of user alice .
If --user-path=path is specified, the same request is
taken as a request to access path/foo repository in
@@ -486,9 +534,9 @@ git repositories.
the option are given to getpwnam(3) and getgrnam(3)
and numeric IDs are not supported.
-Giving these options is an error when used with --inetd ; use
+
Giving these options is an error when used with --inetd ; use
the facility of inet daemon to achieve the same before spawning
-git-daemon if needed.
+
git-daemon if needed.
--enable=service
@@ -528,23 +576,23 @@ the facility of inet daemon to achieve the same before spawning
of each named directory.
-
+
-SERVICES
+SERVICES
-
These services can be globally enabled/disabled using the
+
These services can be globally enabled/disabled using the
command line options of this command. If a finer-grained
-control is desired (e.g. to allow git-archive to be run
+control is desired (e.g. to allow git-archive to be run
against only in a few selected repositories the daemon serves),
the per-repository configuration file can be used to enable or
-disable them.
-
+disable them.
+
upload-pack
- This serves git-fetch-pack and git-ls-remote
+ This serves git-fetch-pack and git-ls-remote
clients. It is enabled by default, but a repository can
disable it by setting daemon.uploadpack configuration
item to false .
@@ -555,7 +603,7 @@ upload-archive
- This serves git-archive --remote . It is disabled by
+ This serves git-archive --remote . It is disabled by
default, but a repository can enable it by setting
daemon.uploadarch configuration item to true .
@@ -565,8 +613,8 @@ receive-pack
- This serves git-send-pack clients, allowing anonymous
- push. It is disabled by default, as there is _no_
+ This serves git-send-pack clients, allowing anonymous
+ push. It is disabled by default, as there is no
authentication in the protocol (in other words, anybody
can push anything into the repository, including removal
of refs). This is solely meant for a closed LAN setting
@@ -575,11 +623,11 @@ receive-pack
true .
-
+
-EXAMPLES
+EXAMPLES
-
+
We assume the following in /etc/services
@@ -591,11 +639,11 @@ git 9418/tcp # Git Version Control System
-git-daemon as inetd server
+git-daemon as inetd server
- To set up git-daemon as an inetd service that handles any
+ To set up git-daemon as an inetd service that handles any
repository under the whitelisted set of directories, /pub/foo
and /pub/bar, place an entry like the following into
/etc/inetd all on one line:
@@ -608,11 +656,11 @@ git 9418/tcp # Git Version Control System
-git-daemon as inetd server for virtual hosts
+git-daemon as inetd server for virtual hosts
- To set up git-daemon as an inetd service that handles
+ To set up git-daemon as an inetd service that handles
repositories for different virtual hosts, www.example.com
and www.example.org , place an entry like the following into
/etc/inetd all on one line:
@@ -626,19 +674,19 @@ git 9418/tcp # Git Version Control System
/pub/www.example.com/software
/software
-
In this example, the root-level directory /pub will contain
+
In this example, the root-level directory /pub will contain
a subdirectory for each virtual host name supported.
Further, both hosts advertise repositories simply as
git://www.example.com/software/repo.git . For pre-1.4.0
clients, a symlink from /software into the appropriate
-default repository could be made as well.
+default repository could be made as well.
-git-daemon as regular daemon for virtual hosts
+git-daemon as regular daemon for virtual hosts
- To set up git-daemon as a regular, non-inetd service that
+ To set up git-daemon as a regular, non-inetd service that
handles repositories for multiple virtual hosts based on
their IP addresses, start the daemon like this:
@@ -649,17 +697,17 @@ default repository could be made as well.
/pub/192.168.1.200/software
/pub/10.10.220.23/software
-In this example, the root-level directory /pub will contain
+
In this example, the root-level directory /pub will contain
a subdirectory for each virtual host IP address supported.
Repositories can still be accessed by hostname though, assuming
-they correspond to these IP addresses.
+they correspond to these IP addresses.
selectively enable/disable services per repository
- To enable git-archive --remote and disable git-fetch against
+ To enable git-archive --remote and disable git-fetch against
a repository, have the following in the configuration file in the
repository (that is the file config next to HEAD , refs and
objects ).
@@ -671,24 +719,24 @@ selectively enable/disable services per repository
uploadarch = true
-
+
-Author
+Author
-
Written by Linus Torvalds <torvalds@osdl.org>, YOSHIFUJI Hideaki
-<yoshfuji@linux-ipv6.org> and the git-list <git@vger.kernel.org>
+
Written by Linus Torvalds <torvalds@osdl.org>, YOSHIFUJI Hideaki
+<yoshfuji@linux-ipv6.org> and the git-list <git@vger.kernel.org>
-Documentation
+Documentation
-
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-daemon.txt b/git-daemon.txt
index 3cf2d3b3d..4ba4b75c1 100644
--- a/git-daemon.txt
+++ b/git-daemon.txt
@@ -27,36 +27,36 @@ that service if it is enabled.
It verifies that the directory has the magic file "git-daemon-export-ok", and
it will refuse to export any git directory that hasn't explicitly been marked
for export this way (unless the '--export-all' parameter is specified). If you
-pass some directory paths as `git-daemon` arguments, you can further restrict
+pass some directory paths as 'git-daemon' arguments, you can further restrict
the offers to a whitelist comprising of those.
By default, only `upload-pack` service is enabled, which serves
-`git-fetch-pack` and `git-ls-remote` clients, which are invoked
-from `git-fetch`, `git-pull`, and `git-clone`.
+'git-fetch-pack' and 'git-ls-remote' clients, which are invoked
+from 'git-fetch', 'git-pull', and 'git-clone'.
This is ideally suited for read-only updates, i.e., pulling from
git repositories.
-An `upload-archive` also exists to serve `git-archive`.
+An `upload-archive` also exists to serve 'git-archive'.
OPTIONS
-------
--strict-paths::
Match paths exactly (i.e. don't allow "/foo/repo" when the real path is
"/foo/repo.git" or "/foo/repo/.git") and don't do user-relative paths.
- `git-daemon` will refuse to start when this option is enabled and no
+ 'git-daemon' will refuse to start when this option is enabled and no
whitelist is specified.
--base-path::
Remap all the path requests as relative to the given path.
- This is sort of "GIT root" - if you run `git-daemon` with
+ This is sort of "GIT root" - if you run 'git-daemon' with
'--base-path=/srv/git' on example.com, then if you later try to pull
- 'git://example.com/hello.git', `git-daemon` will interpret the path
+ 'git://example.com/hello.git', 'git-daemon' will interpret the path
as '/srv/git/hello.git'.
--base-path-relaxed::
If --base-path is enabled and repo lookup fails, with this option
- `git-daemon` will attempt to lookup without prefixing the base path.
+ 'git-daemon' will attempt to lookup without prefixing the base path.
This is useful for switching to --base-path usage, while still
allowing the old paths.
@@ -138,7 +138,7 @@ OPTIONS
+
Giving these options is an error when used with `--inetd`; use
the facility of inet daemon to achieve the same before spawning
-`git-daemon` if needed.
+'git-daemon' if needed.
--enable=service::
--disable=service::
@@ -164,24 +164,24 @@ SERVICES
These services can be globally enabled/disabled using the
command line options of this command. If a finer-grained
-control is desired (e.g. to allow `git-archive` to be run
+control is desired (e.g. to allow 'git-archive' to be run
against only in a few selected repositories the daemon serves),
the per-repository configuration file can be used to enable or
disable them.
upload-pack::
- This serves `git-fetch-pack` and `git-ls-remote`
+ This serves 'git-fetch-pack' and 'git-ls-remote'
clients. It is enabled by default, but a repository can
disable it by setting `daemon.uploadpack` configuration
item to `false`.
upload-archive::
- This serves `git-archive --remote`. It is disabled by
+ This serves 'git-archive --remote'. It is disabled by
default, but a repository can enable it by setting
`daemon.uploadarch` configuration item to `true`.
receive-pack::
- This serves `git-send-pack` clients, allowing anonymous
+ This serves 'git-send-pack' clients, allowing anonymous
push. It is disabled by default, as there is _no_
authentication in the protocol (in other words, anybody
can push anything into the repository, including removal
@@ -199,8 +199,8 @@ $ grep 9418 /etc/services
git 9418/tcp # Git Version Control System
------------
-`git-daemon` as inetd server::
- To set up `git-daemon` as an inetd service that handles any
+'git-daemon' as inetd server::
+ To set up 'git-daemon' as an inetd service that handles any
repository under the whitelisted set of directories, /pub/foo
and /pub/bar, place an entry like the following into
/etc/inetd all on one line:
@@ -212,8 +212,8 @@ git 9418/tcp # Git Version Control System
------------------------------------------------
-`git-daemon` as inetd server for virtual hosts::
- To set up `git-daemon` as an inetd service that handles
+'git-daemon' as inetd server for virtual hosts::
+ To set up 'git-daemon' as an inetd service that handles
repositories for different virtual hosts, `www.example.com`
and `www.example.org`, place an entry like the following into
`/etc/inetd` all on one line:
@@ -235,8 +235,8 @@ clients, a symlink from `/software` into the appropriate
default repository could be made as well.
-`git-daemon` as regular daemon for virtual hosts::
- To set up `git-daemon` as a regular, non-inetd service that
+'git-daemon' as regular daemon for virtual hosts::
+ To set up 'git-daemon' as a regular, non-inetd service that
handles repositories for multiple virtual hosts based on
their IP addresses, start the daemon like this:
+
@@ -253,7 +253,7 @@ Repositories can still be accessed by hostname though, assuming
they correspond to these IP addresses.
selectively enable/disable services per repository::
- To enable `git-archive --remote` and disable `git-fetch` against
+ To enable 'git-archive --remote' and disable 'git-fetch' against
a repository, have the following in the configuration file in the
repository (that is the file 'config' next to 'HEAD', 'refs' and
'objects').
diff --git a/git-describe.html b/git-describe.html
index d5b85a72b..3ea45a471 100644
--- a/git-describe.html
+++ b/git-describe.html
@@ -3,7 +3,7 @@
-
+
git-describe(1)
@@ -272,19 +320,19 @@ git-describe(1) Manual Page
SYNOPSIS
-
git describe [--all] [--tags] [--contains] [--abbrev=<n>] <committish>…
+
git describe [--all] [--tags] [--contains] [--abbrev=<n>] <committish>…
-DESCRIPTION
+DESCRIPTION
-
The command finds the most recent tag that is reachable from a
+
The command finds the most recent tag that is reachable from a
commit. If the tag points to the commit, then only the tag is
shown. Otherwise, it suffixes the tag name with the number of
additional commits on top of the tagged object and the
-abbreviated object name of the most recent commit.
+abbreviated object name of the most recent commit.
-OPTIONS
+OPTIONS
-
+
<committish>
@@ -392,33 +440,33 @@ abbreviated object name of the most recent commit.
Show uniquely abbreviated commit object as fallback.
-
+
-EXAMPLES
+EXAMPLES
-
With something like git.git current tree, I get:
+
With something like git.git current tree, I get:
[torvalds@g5 git]$ git describe parent
v1.0.4-14-g2414721
-
i.e. the current head of my "parent" branch is based on v1.0.4,
+
i.e. the current head of my "parent" branch is based on v1.0.4,
but since it has a handful commits on top of that,
describe has added the number of additional commits ("14") and
an abbreviated object name for the commit itself ("2414721")
-at the end.
-
The number of additional commits is the number
+at the end.
+
The number of additional commits is the number
of commits which would be displayed by "git log v1.0.4..parent".
The hash suffix is "-g" + 7-char abbreviation for the tip commit
-of parent (which was 2414721b194453f058079d897d13c4e377f92dc6 ).
-
Doing a git-describe on a tag-name will just show the tag name:
+of parent (which was
2414721b194453f058079d897d13c4e377f92dc6 ).
+
Doing a git-describe on a tag-name will just show the tag name:
[torvalds@g5 git]$ git describe v1.0.4
v1.0.4
-
With --all, the command can use branch heads as references, so
-the output shows the reference path as well:
+
With --all, the command can use branch heads as references, so
+the output shows the reference path as well:
[torvalds@g5 git]$ git describe --all --abbrev=4 v1.0.5^2
@@ -429,48 +477,48 @@ tags/v1.0.0-21-g975b
[torvalds@g5 git]$ git describe --all HEAD^
heads/lt/describe-7-g975b
-
With --abbrev set to 0, the command can be used to find the
-closest tagname without any suffix:
+
With --abbrev set to 0, the command can be used to find the
+closest tagname without any suffix:
[torvalds@g5 git]$ git describe --abbrev=0 v1.0.5^2
tags/v1.0.0
-SEARCH STRATEGY
+SEARCH STRATEGY
-
For each committish supplied, git-describe will first look for
+
For each committish supplied, git-describe will first look for
a tag which tags exactly that commit. Annotated tags will always
be preferred over lightweight tags, and tags with newer dates will
always be preferred over tags with older dates. If an exact match
-is found, its name will be output and searching will stop.
-
If an exact match was not found, git-describe will walk back
+is found, its name will be output and searching will stop.
+
If an exact match was not found, git-describe will walk back
through the commit history to locate an ancestor commit which
has been tagged. The ancestor's tag will be output along with an
-abbreviation of the input committish's SHA1.
-
If multiple tags were found during the walk then the tag which
+abbreviation of the input committish's SHA1.
+
If multiple tags were found during the walk then the tag which
has the fewest commits different from the input committish will be
selected and output. Here fewest commits different is defined as
the number of commits which would be shown by git log tag..input
-will be the smallest number of commits possible.
+will be the smallest number of commits possible.
-Author
+Author
-
Written by Linus Torvalds <torvalds@osdl.org>, but somewhat
+
Written by Linus Torvalds <torvalds@osdl.org>, but somewhat
butchered by Junio C Hamano <junkio@cox.net>. Later significantly
-updated by Shawn Pearce <spearce@spearce.org>.
+updated by Shawn Pearce <spearce@spearce.org>.
-Documentation
+Documentation
-
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-describe.txt b/git-describe.txt
index 51a0cc044..44b166888 100644
--- a/git-describe.txt
+++ b/git-describe.txt
@@ -92,7 +92,7 @@ of commits which would be displayed by "git log v1.0.4..parent".
The hash suffix is "-g" + 7-char abbreviation for the tip commit
of parent (which was `2414721b194453f058079d897d13c4e377f92dc6`).
-Doing a `git-describe` on a tag-name will just show the tag name:
+Doing a 'git-describe' on a tag-name will just show the tag name:
[torvalds@g5 git]$ git describe v1.0.4
v1.0.4
@@ -115,13 +115,13 @@ closest tagname without any suffix:
SEARCH STRATEGY
---------------
-For each committish supplied, `git-describe` will first look for
+For each committish supplied, 'git-describe' will first look for
a tag which tags exactly that commit. Annotated tags will always
be preferred over lightweight tags, and tags with newer dates will
always be preferred over tags with older dates. If an exact match
is found, its name will be output and searching will stop.
-If an exact match was not found, `git-describe` will walk back
+If an exact match was not found, 'git-describe' will walk back
through the commit history to locate an ancestor commit which
has been tagged. The ancestor's tag will be output along with an
abbreviation of the input committish's SHA1.
diff --git a/git-diff-files.html b/git-diff-files.html
index 993785da0..fb9ca3474 100644
--- a/git-diff-files.html
+++ b/git-diff-files.html
@@ -3,7 +3,7 @@
-
+
git-diff-files(1)
@@ -272,18 +320,18 @@ git-diff-files(1) Manual Page
SYNOPSIS
-
git diff-files [-q] [-0|-1|-2|-3|-c|--cc] [<common diff options>] [<path>…]
+
git diff-files [-q] [-0|-1|-2|-3|-c|--cc] [<common diff options>] [<path>…]
-DESCRIPTION
+DESCRIPTION
-
Compares the files in the working tree and the index. When paths
+
Compares the files in the working tree and the index. When paths
are specified, compares only those named paths. Otherwise all
entries in the index are compared. The output format is the
-same as for git-diff-index and git-diff-tree .
+same as for
git-diff-index and
git-diff-tree .
-OPTIONS
+OPTIONS
-
+
-p
@@ -755,10 +803,10 @@ same as for git-diff-index and git-diff-tree .
Do not show any source or destination prefix.
-
-
For more detailed explanation on these common options, see also
-gitdiffcore(7) .
-
+
+For more detailed explanation on these common options, see also
+gitdiffcore(7) .
+
-1 -2 -3 or --base --ours --theirs, and -0
@@ -768,9 +816,9 @@ same as for git-diff-index and git-diff-tree .
branch" respectively. With these options, diffs for
merged entries are not shown.
-The default is to diff against our branch (-2) and the
+
The default is to diff against our branch (-2) and the
cleanly resolved paths. The option -0 can be given to
-omit diff output for unmerged entries and just show "Unmerged".
+omit diff output for unmerged entries and just show "Unmerged".
-c
@@ -794,15 +842,15 @@ omit diff output for unmerged entries and just show "Unmerged".
Remain silent even on nonexistent files
-
+
-Output format
+
-
The output format from "git-diff-index", "git-diff-tree",
-"git-diff-files" and "git diff --raw" are very similar.
-
These commands all compare two sets of things; what is
-compared differs:
-
+The output format from "git-diff-index", "git-diff-tree",
+"git-diff-files" and "git diff --raw" are very similar.
+These commands all compare two sets of things; what is
+compared differs:
+
git-diff-index <tree-ish>
@@ -835,8 +883,8 @@ git-diff-files [<pattern>…]
compares the index and the files on the filesystem.
-
-
An output line is formatted this way:
+
+An output line is formatted this way:
in-place edit :100644 100644 bcd1234... 0123456... M file0
@@ -846,8 +894,8 @@ create :000000 100644 0000000... 1234567... A file4
delete :100644 000000 1234567... 0000000... D file5
unmerged :000000 000000 0000000... 0000000... U file6
-That is, from the left to the right:
-
+That is, from the left to the right:
+
a colon.
@@ -923,25 +971,25 @@ path for "dst"; only exists for C or R.
an LF or a NUL when -z option is used, to terminate the record.
-
-
<sha1> is shown as all 0's if a file is new on the filesystem
-and it is out of sync with the index.
-
Example:
+
+<sha1> is shown as all 0's if a file is new on the filesystem
+and it is out of sync with the index.
+
:100644 100644 5be4a4...... 000000...... M file.c
-When -z option is not used, TAB, LF, and backslash characters
+
When -z option is not used, TAB, LF, and backslash characters
in pathnames are represented as \t , \n , and \\ ,
-respectively.
+respectively.
-diff format for merges
+
-
"git-diff-tree", "git-diff-files" and "git-diff --raw"
+
"git-diff-tree", "git-diff-files" and "git-diff --raw"
can take -c or --cc option
to generate diff output also for merge commits. The output differs
-from the format described above in the following way:
-
+from the format described above in the following way:
+
there is a colon for each parent
@@ -967,26 +1015,26 @@ no optional "score" number
single path, only for "dst"
-
-
Example:
+
+
::100644 100644 100644 fabadb8... cc95eb0... 4866510... MM describe.c
-
Note that combined diff lists only files which were modified from
-all parents.
+
Note that combined diff lists only files which were modified from
+all parents.
-Generating patches with -p
+Generating patches with -p
-
When "git-diff-index", "git-diff-tree", or "git-diff-files" are run
+
When "git-diff-index", "git-diff-tree", or "git-diff-files" are run
with a -p option, "git diff" without the --raw option, or
"git log" with the "-p" option, they
do not produce the output described above; instead they produce a
patch file. You can customize the creation of such patches via the
-GIT_EXTERNAL_DIFF and the GIT_DIFF_OPTS environment variables.
-
What the -p option produces is slightly different from the traditional
-diff format.
-
+GIT_EXTERNAL_DIFF and the GIT_DIFF_OPTS environment variables.
+
What the -p option produces is slightly different from the traditional
+diff format.
+
It is preceded with a "git diff" header, that looks like
@@ -996,12 +1044,12 @@ It is preceded with a "git diff" header, that looks like
diff --git a/file1 b/file2
-
The a/ and b/ filenames are the same unless rename/copy is
+
The a/ and b/ filenames are the same unless rename/copy is
involved. Especially, even for a creation or a deletion,
-/dev/null is _not_ used in place of a/ or b/ filenames.
-
When rename/copy is involved, file1 and file2 show the
+/dev/null is not used in place of a/ or b/ filenames.
+
When rename/copy is involved, file1 and file2 show the
name of the source file of the rename/copy and the name of
-the file that rename/copy produces, respectively.
+the file that rename/copy produces, respectively.
@@ -1030,20 +1078,20 @@ TAB, LF, double quote and backslash characters in pathnames
pathname is put in double quotes.
-
-
The similarity index is the percentage of unchanged lines, and
+
+The similarity index is the percentage of unchanged lines, and
the dissimilarity index is the percentage of changed lines. It
is a rounded down integer, followed by a percent sign. The
similarity index value of 100% is thus reserved for two equal
files, while 100% dissimilarity means that no line from the old
-file made it into the new one.
+file made it into the new one.
-combined diff format
+
-
"git-diff-tree", "git-diff-files" and "git-diff" can take -c or
+
"git-diff-tree", "git-diff-files" and "git-diff" can take -c or
--cc option to produce combined diff . For showing a merge commit
with "git log -p", this is the default format.
-A combined diff format looks like this:
+A
combined diff format looks like this:
diff --combined describe.c
@@ -1074,7 +1122,7 @@ index fabadb8,cc95eb0..4866510
initialized = 1;
for_each_ref(get_name);
-
+
It is preceded with a "git diff" header, that looks like
@@ -1084,7 +1132,7 @@ It is preceded with a "git diff" header, that looks like
-or like this (when --cc option is used):
+or like this (when --cc option is used):
diff --c file
@@ -1102,11 +1150,11 @@ mode <mode>,<mode>..<mode>
new file mode <mode>
deleted file mode <mode>,<mode>
-The mode <mode>,<mode>..<mode> line appears only if at least one of
+
The mode <mode>,<mode>..<mode> line appears only if at least one of
the <mode> is different from the rest. Extended headers with
information about detected contents movement (renames and
copying detection) are designed to work with diff of two
-<tree-ish> and are not used by combined diff format.
+<tree-ish> and are not used by combined diff format.
@@ -1117,9 +1165,9 @@ It is followed by two-line from-file/to-file header
--- a/file
+++ b/file
-Similar to two-line header for traditional unified diff
+
Similar to two-line header for traditional unified diff
format, /dev/null is used to signal created or deleted
-files.
+files.
@@ -1133,59 +1181,59 @@ Chunk header format is modified to prevent people from
@@@ <from-file-range> <from-file-range> <to-file-range> @@@
-There are (number of parents + 1) @ characters in the chunk
-header for combined diff format.
+There are (number of parents + 1) @ characters in the chunk
+header for combined diff format.
-
-Unlike the traditional unified diff format, which shows two
+
+
Unlike the traditional unified diff format, which shows two
files A and B with a single column that has - (minus —
appears in A but removed in B), + (plus — missing in A but
added to B), or " " (space — unchanged) prefix, this format
compares two or more files file1, file2,… with one file X, and
shows how X differs from each of fileN. One column for each of
fileN is prepended to the output line to note how X's line is
-different from it.
-
A - character in the column N means that the line appears in
+different from it.
+A - character in the column N means that the line appears in
fileN but it does not appear in the result. A + character
in the column N means that the line appears in the last file,
and fileN does not have that line (in other words, the line was
-added, from the point of view of that parent).
-
In the above example output, the function signature was changed
+added, from the point of view of that parent).
+In the above example output, the function signature was changed
from both files (hence two - removals from both file1 and
-file2, plus ++ to mean one line that was added does not appear
+file2, plus + to mean one line that was added does not appear
in either file1 nor file2). Also two other lines are the same
-from file1 but do not appear in file2 (hence prefixed with + ).
-
When shown by git diff-tree -c , it compares the parents of a
+from file1 but do not appear in file2 (hence prefixed with ).
+When shown by git diff-tree -c , it compares the parents of a
merge commit with the merge result (i.e. file1..fileN are the
parents). When shown by git diff-files -c , it compares the
two unresolved merge parents with the working tree file
(i.e. file1 is stage 2 aka "our version", file2 is stage 3 aka
-"their version").
+"their version").
-other diff formats
+
-
The --summary option describes newly added, deleted, renamed and
+
The --summary option describes newly added, deleted, renamed and
copied files. The --stat option adds diffstat(1) graph to the
output. These options can be combined with other options, such as
--p , and are meant for human consumption.
-
When showing a change that involves a rename or a copy, --stat output
+-p , and are meant for human consumption.
+
When showing a change that involves a rename or a copy, --stat output
formats the pathnames compactly by combining common prefix and suffix of
the pathnames. For example, a change that moves arch/i386/Makefile to
-arch/x86/Makefile while modifying 4 lines will be shown like this:
+
arch/x86/Makefile while modifying 4 lines will be shown like this:
arch/{i386 => x86}/Makefile | 4 +--
-
The --numstat option gives the diffstat(1) information but is designed
+
The --numstat option gives the diffstat(1) information but is designed
for easier machine consumption. An entry in --numstat output looks
-like this:
+like this:
1 2 README
3 1 arch/{i386 => x86}/Makefile
-
That is, from left to right:
-
+That is, from left to right:
+
the number of added lines;
@@ -1216,15 +1264,15 @@ pathname (possibly with rename/copy information);
a newline.
-
-
When -z output option is in effect, the output is formatted this way:
+
+When -z output option is in effect, the output is formatted this way:
1 2 README NUL
3 1 NUL arch/i386/Makefile NUL arch/x86/Makefile NUL
-That is:
-
+
+
the number of added lines;
@@ -1270,28 +1318,28 @@ pathname in postimage (only exists if renamed/copied);
a NUL.
-
-
The extra NUL before the preimage path in renamed case is to allow
+
+The extra NUL before the preimage path in renamed case is to allow
scripts that read the output to tell if the current record being read is
a single-path record or a rename/copy record without reading ahead.
After reading added and deleted lines, reading up to NUL would yield
-the pathname, but if that is NUL , the record will show two paths.
+the pathname, but if that is
NUL , the record will show two paths.
-Author
+Author
-
Written by Linus Torvalds <torvalds@osdl.org>
+
Written by Linus Torvalds <torvalds@osdl.org>
-Documentation
+Documentation
-
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-diff-files.txt b/git-diff-files.txt
index 6c65757ea..5c8c1d95a 100644
--- a/git-diff-files.txt
+++ b/git-diff-files.txt
@@ -15,7 +15,7 @@ DESCRIPTION
Compares the files in the working tree and the index. When paths
are specified, compares only those named paths. Otherwise all
entries in the index are compared. The output format is the
-same as for `git-diff-index` and `git-diff-tree`.
+same as for 'git-diff-index' and 'git-diff-tree'.
OPTIONS
-------
diff --git a/git-diff-index.html b/git-diff-index.html
index 7ca898202..83f7c15ae 100644
--- a/git-diff-index.html
+++ b/git-diff-index.html
@@ -3,7 +3,7 @@
-
+
git-diff-index(1)
@@ -272,19 +320,19 @@ git-diff-index(1) Manual Page
SYNOPSIS
-
git diff-index [-m] [--cached] [<common diff options>] <tree-ish> [<path>…]
+
git diff-index [-m] [--cached] [<common diff options>] <tree-ish> [<path>…]
-DESCRIPTION
+DESCRIPTION
-
Compares the content and mode of the blobs found via a tree
+
Compares the content and mode of the blobs found via a tree
object with the content of the current index and, optionally
ignoring the stat state of the file on disk. When paths are
specified, compares only those named paths. Otherwise all
-entries in the index are compared.
+entries in the index are compared.
-OPTIONS
+OPTIONS
-
+
-p
@@ -756,10 +804,10 @@ entries in the index are compared.
Do not show any source or destination prefix.
-
-
For more detailed explanation on these common options, see also
-gitdiffcore(7) .
-
+
+For more detailed explanation on these common options, see also
+gitdiffcore(7) .
+
<tree-ish>
@@ -783,19 +831,19 @@ entries in the index are compared.
By default, files recorded in the index but not checked
out are reported as deleted. This flag makes
- git-diff-index say that all non-checked-out files are up
+ git-diff-index say that all non-checked-out files are up
to date.
-
+
-Output format
+
-
The output format from "git-diff-index", "git-diff-tree",
-"git-diff-files" and "git diff --raw" are very similar.
-
These commands all compare two sets of things; what is
-compared differs:
-
+The output format from "git-diff-index", "git-diff-tree",
+"git-diff-files" and "git diff --raw" are very similar.
+These commands all compare two sets of things; what is
+compared differs:
+
git-diff-index <tree-ish>
@@ -828,8 +876,8 @@ git-diff-files [<pattern>…]
compares the index and the files on the filesystem.
-
-
An output line is formatted this way:
+
+An output line is formatted this way:
in-place edit :100644 100644 bcd1234... 0123456... M file0
@@ -839,8 +887,8 @@ create :000000 100644 0000000... 1234567... A file4
delete :100644 000000 1234567... 0000000... D file5
unmerged :000000 000000 0000000... 0000000... U file6
-That is, from the left to the right:
-
+That is, from the left to the right:
+
a colon.
@@ -916,25 +964,25 @@ path for "dst"; only exists for C or R.
an LF or a NUL when -z option is used, to terminate the record.
-
-
<sha1> is shown as all 0's if a file is new on the filesystem
-and it is out of sync with the index.
-
Example:
+
+<sha1> is shown as all 0's if a file is new on the filesystem
+and it is out of sync with the index.
+
:100644 100644 5be4a4...... 000000...... M file.c
-When -z option is not used, TAB, LF, and backslash characters
+
When -z option is not used, TAB, LF, and backslash characters
in pathnames are represented as \t , \n , and \\ ,
-respectively.
+respectively.
-diff format for merges
+
-
"git-diff-tree", "git-diff-files" and "git-diff --raw"
+
"git-diff-tree", "git-diff-files" and "git-diff --raw"
can take -c or --cc option
to generate diff output also for merge commits. The output differs
-from the format described above in the following way:
-
+from the format described above in the following way:
+
there is a colon for each parent
@@ -960,26 +1008,26 @@ no optional "score" number
single path, only for "dst"
-
-
Example:
+
+
::100644 100644 100644 fabadb8... cc95eb0... 4866510... MM describe.c
-
Note that combined diff lists only files which were modified from
-all parents.
+
Note that combined diff lists only files which were modified from
+all parents.
-Generating patches with -p
+Generating patches with -p
-
When "git-diff-index", "git-diff-tree", or "git-diff-files" are run
+
When "git-diff-index", "git-diff-tree", or "git-diff-files" are run
with a -p option, "git diff" without the --raw option, or
"git log" with the "-p" option, they
do not produce the output described above; instead they produce a
patch file. You can customize the creation of such patches via the
-GIT_EXTERNAL_DIFF and the GIT_DIFF_OPTS environment variables.
-
What the -p option produces is slightly different from the traditional
-diff format.
-
+GIT_EXTERNAL_DIFF and the GIT_DIFF_OPTS environment variables.
+
What the -p option produces is slightly different from the traditional
+diff format.
+
It is preceded with a "git diff" header, that looks like
@@ -989,12 +1037,12 @@ It is preceded with a "git diff" header, that looks like
diff --git a/file1 b/file2
-
The a/ and b/ filenames are the same unless rename/copy is
+
The a/ and b/ filenames are the same unless rename/copy is
involved. Especially, even for a creation or a deletion,
-/dev/null is _not_ used in place of a/ or b/ filenames.
-
When rename/copy is involved, file1 and file2 show the
+/dev/null is not used in place of a/ or b/ filenames.
+
When rename/copy is involved, file1 and file2 show the
name of the source file of the rename/copy and the name of
-the file that rename/copy produces, respectively.
+the file that rename/copy produces, respectively.
@@ -1023,20 +1071,20 @@ TAB, LF, double quote and backslash characters in pathnames
pathname is put in double quotes.
-
-
The similarity index is the percentage of unchanged lines, and
+
+The similarity index is the percentage of unchanged lines, and
the dissimilarity index is the percentage of changed lines. It
is a rounded down integer, followed by a percent sign. The
similarity index value of 100% is thus reserved for two equal
files, while 100% dissimilarity means that no line from the old
-file made it into the new one.
+file made it into the new one.
-combined diff format
+
-
"git-diff-tree", "git-diff-files" and "git-diff" can take -c or
+
"git-diff-tree", "git-diff-files" and "git-diff" can take -c or
--cc option to produce combined diff . For showing a merge commit
with "git log -p", this is the default format.
-A combined diff format looks like this:
+A
combined diff format looks like this:
diff --combined describe.c
@@ -1067,7 +1115,7 @@ index fabadb8,cc95eb0..4866510
initialized = 1;
for_each_ref(get_name);
-
+
It is preceded with a "git diff" header, that looks like
@@ -1077,7 +1125,7 @@ It is preceded with a "git diff" header, that looks like
-or like this (when --cc option is used):
+or like this (when --cc option is used):
diff --c file
@@ -1095,11 +1143,11 @@ mode <mode>,<mode>..<mode>
new file mode <mode>
deleted file mode <mode>,<mode>
-The mode <mode>,<mode>..<mode> line appears only if at least one of
+
The mode <mode>,<mode>..<mode> line appears only if at least one of
the <mode> is different from the rest. Extended headers with
information about detected contents movement (renames and
copying detection) are designed to work with diff of two
-<tree-ish> and are not used by combined diff format.
+<tree-ish> and are not used by combined diff format.
@@ -1110,9 +1158,9 @@ It is followed by two-line from-file/to-file header
--- a/file
+++ b/file
-Similar to two-line header for traditional unified diff
+
Similar to two-line header for traditional unified diff
format, /dev/null is used to signal created or deleted
-files.
+files.
@@ -1126,59 +1174,59 @@ Chunk header format is modified to prevent people from
@@@ <from-file-range> <from-file-range> <to-file-range> @@@
-There are (number of parents + 1) @ characters in the chunk
-header for combined diff format.
+There are (number of parents + 1) @ characters in the chunk
+header for combined diff format.
-
-Unlike the traditional unified diff format, which shows two
+
+
Unlike the traditional unified diff format, which shows two
files A and B with a single column that has - (minus —
appears in A but removed in B), + (plus — missing in A but
added to B), or " " (space — unchanged) prefix, this format
compares two or more files file1, file2,… with one file X, and
shows how X differs from each of fileN. One column for each of
fileN is prepended to the output line to note how X's line is
-different from it.
-
A - character in the column N means that the line appears in
+different from it.
+A - character in the column N means that the line appears in
fileN but it does not appear in the result. A + character
in the column N means that the line appears in the last file,
and fileN does not have that line (in other words, the line was
-added, from the point of view of that parent).
-
In the above example output, the function signature was changed
+added, from the point of view of that parent).
+In the above example output, the function signature was changed
from both files (hence two - removals from both file1 and
-file2, plus ++ to mean one line that was added does not appear
+file2, plus + to mean one line that was added does not appear
in either file1 nor file2). Also two other lines are the same
-from file1 but do not appear in file2 (hence prefixed with + ).
-
When shown by git diff-tree -c , it compares the parents of a
+from file1 but do not appear in file2 (hence prefixed with ).
+When shown by git diff-tree -c , it compares the parents of a
merge commit with the merge result (i.e. file1..fileN are the
parents). When shown by git diff-files -c , it compares the
two unresolved merge parents with the working tree file
(i.e. file1 is stage 2 aka "our version", file2 is stage 3 aka
-"their version").
+"their version").
-other diff formats
+
-
The --summary option describes newly added, deleted, renamed and
+
The --summary option describes newly added, deleted, renamed and
copied files. The --stat option adds diffstat(1) graph to the
output. These options can be combined with other options, such as
--p , and are meant for human consumption.
-
When showing a change that involves a rename or a copy, --stat output
+-p , and are meant for human consumption.
+
When showing a change that involves a rename or a copy, --stat output
formats the pathnames compactly by combining common prefix and suffix of
the pathnames. For example, a change that moves arch/i386/Makefile to
-arch/x86/Makefile while modifying 4 lines will be shown like this:
+
arch/x86/Makefile while modifying 4 lines will be shown like this:
arch/{i386 => x86}/Makefile | 4 +--
-
The --numstat option gives the diffstat(1) information but is designed
+
The --numstat option gives the diffstat(1) information but is designed
for easier machine consumption. An entry in --numstat output looks
-like this:
+like this:
1 2 README
3 1 arch/{i386 => x86}/Makefile
-
That is, from left to right:
-
+That is, from left to right:
+
the number of added lines;
@@ -1209,15 +1257,15 @@ pathname (possibly with rename/copy information);
a newline.
-
-
When -z output option is in effect, the output is formatted this way:
+
+When -z output option is in effect, the output is formatted this way:
1 2 README NUL
3 1 NUL arch/i386/Makefile NUL arch/x86/Makefile NUL
-That is:
-
+
+
the number of added lines;
@@ -1263,92 +1311,92 @@ pathname in postimage (only exists if renamed/copied);
a NUL.
-
-
The extra NUL before the preimage path in renamed case is to allow
+
+The extra NUL before the preimage path in renamed case is to allow
scripts that read the output to tell if the current record being read is
a single-path record or a rename/copy record without reading ahead.
After reading added and deleted lines, reading up to NUL would yield
-the pathname, but if that is NUL , the record will show two paths.
+the pathname, but if that is
NUL , the record will show two paths.
-Operating Modes
+Operating Modes
-
You can choose whether you want to trust the index file entirely
+
You can choose whether you want to trust the index file entirely
(using the --cached flag) or ask the diff logic to show any files
that don't match the stat state as being "tentatively changed". Both
-of these operations are very useful indeed.
+of these operations are very useful indeed.
-Cached Mode
+Cached Mode
-
If --cached is specified, it allows you to ask:
+
If --cached is specified, it allows you to ask:
show me the differences between HEAD and the current index
-contents (the ones I'd write using `git-write-tree`)
+contents (the ones I'd write using 'git-write-tree')
-
For example, let's say that you have worked on your working directory, updated
+
For example, let's say that you have worked on your working directory, updated
some files in the index and are ready to commit. You want to see exactly
what you are going to commit, without having to write a new tree
-object and compare it that way, and to do that, you just do
+object and compare it that way, and to do that, you just do
git diff-index --cached HEAD
-
Example: let's say I had renamed commit.c to git-commit.c , and I had
+
Example: let's say I had renamed commit.c to git-commit.c , and I had
done an update-index to make that effective in the index file.
git diff-files wouldn't show anything at all, since the index file
-matches my working directory. But doing a git-diff-index does:
+matches my working directory. But doing a
git-diff-index does:
torvalds@ppc970:~/git> git diff-index --cached HEAD
-100644 blob 4161aecc6700a2eb579e842af0b7f22b98443f74 commit.c
+100644 blob 4161aecc6700a2eb579e842af0b7f22b98443f74 git-commit.c
-
You can see easily that the above is a rename.
-
In fact, git diff-index --cached should always be entirely equivalent to
-actually doing a git-write-tree and comparing that. Except this one is much
-nicer for the case where you just want to check where you are.
-
So doing a git-diff-index --cached is basically very useful when you are
+
You can see easily that the above is a rename.
+
In fact, git diff-index --cached should always be entirely equivalent to
+actually doing a git-write-tree and comparing that. Except this one is much
+nicer for the case where you just want to check where you are.
+
So doing a git-diff-index --cached is basically very useful when you are
asking yourself "what have I already marked for being committed, and
-what's the difference to a previous tree".
+what's the difference to a previous tree".
-Non-cached Mode
+Non-cached Mode
-
The "non-cached" mode takes a different approach, and is potentially
+
The "non-cached" mode takes a different approach, and is potentially
the more useful of the two in that what it does can't be emulated with
-a git-write-tree + git-diff-tree . Thus that's the default mode.
-The non-cached version asks the question:
+a
git-write-tree +
git-diff-tree . Thus that's the default mode.
+The non-cached version asks the question:
show me the differences between HEAD and the currently checked out
tree - index contents _and_ files that aren't up-to-date
-
which is obviously a very useful question too, since that tells you what
-you could commit. Again, the output matches the git-diff-tree -r
-output to a tee, but with a twist.
-
The twist is that if some file doesn't match the index, we don't have
+
which is obviously a very useful question too, since that tells you what
+you could commit. Again, the output matches the git-diff-tree -r
+output to a tee, but with a twist.
+
The twist is that if some file doesn't match the index, we don't have
a backing store thing for it, and we use the magic "all-zero" sha1 to
show that. So let's say that you have edited kernel/sched.c , but
-have not actually done a git-update-index on it yet - there is no
-"object" associated with the new state, and you get:
+have not actually done a
git-update-index on it yet - there is no
+"object" associated with the new state, and you get:
torvalds@ppc970:~/v2.6/linux> git diff-index HEAD
*100644->100664 blob 7476bb......->000000...... kernel/sched.c
-
i.e., it shows that the tree has changed, and that kernel/sched.c has is
+
i.e., it shows that the tree has changed, and that kernel/sched.c has is
not up-to-date and may contain new stuff. The all-zero sha1 means that to
get the real diff, you need to look at the object in the working directory
-directly rather than do an object-to-object diff.
+directly rather than do an object-to-object diff.
Note
-As with other commands of this type, git-diff-index does not
+ As with other commands of this type, git-diff-index does not
actually look at the contents of the file at all. So maybe
kernel/sched.c hasn't actually changed, and it's just that you
touched it. In either case, it's a note that you need to
-git-update-index it to make the index be in sync.
+git-update-index it to make the index be in sync.
@@ -1364,21 +1412,21 @@ always have the special all-zero sha1.
-Author
+Author
-
Written by Linus Torvalds <torvalds@osdl.org>
+
Written by Linus Torvalds <torvalds@osdl.org>
-Documentation
+Documentation
-
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-diff-index.txt b/git-diff-index.txt
index 784bbf3b0..26920d4f6 100644
--- a/git-diff-index.txt
+++ b/git-diff-index.txt
@@ -31,7 +31,7 @@ include::diff-options.txt[]
-m::
By default, files recorded in the index but not checked
out are reported as deleted. This flag makes
- `git-diff-index` say that all non-checked-out files are up
+ 'git-diff-index' say that all non-checked-out files are up
to date.
Output format
@@ -50,7 +50,7 @@ Cached Mode
If '--cached' is specified, it allows you to ask:
show me the differences between HEAD and the current index
- contents (the ones I'd write using `git-write-tree`)
+ contents (the ones I'd write using 'git-write-tree')
For example, let's say that you have worked on your working directory, updated
some files in the index and are ready to commit. You want to see exactly
@@ -62,7 +62,7 @@ object and compare it that way, and to do that, you just do
Example: let's say I had renamed `commit.c` to `git-commit.c`, and I had
done an `update-index` to make that effective in the index file.
`git diff-files` wouldn't show anything at all, since the index file
-matches my working directory. But doing a `git-diff-index` does:
+matches my working directory. But doing a 'git-diff-index' does:
torvalds@ppc970:~/git> git diff-index --cached HEAD
-100644 blob 4161aecc6700a2eb579e842af0b7f22b98443f74 commit.c
@@ -71,10 +71,10 @@ matches my working directory. But doing a `git-diff-index` does:
You can see easily that the above is a rename.
In fact, `git diff-index --cached` *should* always be entirely equivalent to
-actually doing a `git-write-tree` and comparing that. Except this one is much
+actually doing a 'git-write-tree' and comparing that. Except this one is much
nicer for the case where you just want to check where you are.
-So doing a `git-diff-index --cached` is basically very useful when you are
+So doing a 'git-diff-index --cached' is basically very useful when you are
asking yourself "what have I already marked for being committed, and
what's the difference to a previous tree".
@@ -82,20 +82,20 @@ Non-cached Mode
---------------
The "non-cached" mode takes a different approach, and is potentially
the more useful of the two in that what it does can't be emulated with
-a `git-write-tree` + `git-diff-tree`. Thus that's the default mode.
+a 'git-write-tree' + 'git-diff-tree'. Thus that's the default mode.
The non-cached version asks the question:
show me the differences between HEAD and the currently checked out
tree - index contents _and_ files that aren't up-to-date
which is obviously a very useful question too, since that tells you what
-you *could* commit. Again, the output matches the `git-diff-tree -r`
+you *could* commit. Again, the output matches the 'git-diff-tree -r'
output to a tee, but with a twist.
The twist is that if some file doesn't match the index, we don't have
a backing store thing for it, and we use the magic "all-zero" sha1 to
show that. So let's say that you have edited `kernel/sched.c`, but
-have not actually done a `git-update-index` on it yet - there is no
+have not actually done a 'git-update-index' on it yet - there is no
"object" associated with the new state, and you get:
torvalds@ppc970:~/v2.6/linux> git diff-index HEAD
@@ -106,11 +106,11 @@ not up-to-date and may contain new stuff. The all-zero sha1 means that to
get the real diff, you need to look at the object in the working directory
directly rather than do an object-to-object diff.
-NOTE: As with other commands of this type, `git-diff-index` does not
+NOTE: As with other commands of this type, 'git-diff-index' does not
actually look at the contents of the file at all. So maybe
`kernel/sched.c` hasn't actually changed, and it's just that you
touched it. In either case, it's a note that you need to
-`git-update-index` it to make the index be in sync.
+'git-update-index' it to make the index be in sync.
NOTE: You can have a mixture of files show up as "has been updated"
and "is still dirty in the working directory" together. You can always
diff --git a/git-diff-tree.html b/git-diff-tree.html
index e9b55a989..931e3a2ea 100644
--- a/git-diff-tree.html
+++ b/git-diff-tree.html
@@ -3,7 +3,7 @@
-
+
git-diff-tree(1)
@@ -277,16 +325,16 @@ git-diff-tree(1) Manual Page
[-t] [-r] [-c | --cc] [--root] [<common diff options>]
<tree-ish> [<tree-ish>] [<path>…]
-DESCRIPTION
+DESCRIPTION
-
Compares the content and mode of the blobs found via two tree objects.
-
If there is only one <tree-ish> given, the commit is compared with its parents
-(see --stdin below).
-
Note that git-diff-tree can use the tree encapsulated in a commit object.
+
Compares the content and mode of the blobs found via two tree objects.
+
If there is only one <tree-ish> given, the commit is compared with its parents
+(see --stdin below).
+
Note that git-diff-tree can use the tree encapsulated in a commit object.
-OPTIONS
+OPTIONS
-
+
-p
@@ -758,10 +806,10 @@ git-diff-tree(1) Manual Page
Do not show any source or destination prefix.
-
-
For more detailed explanation on these common options, see also
-gitdiffcore(7) .
-
+
+For more detailed explanation on these common options, see also
+gitdiffcore(7) .
+
<tree-ish>
@@ -817,17 +865,17 @@ git-diff-tree(1) Manual Page
reads either one <commit> or a pair of <tree-ish>
separated with a single space from its standard input.
-When a single commit is given on one line of such input, it compares
+
When a single commit is given on one line of such input, it compares
the commit with its parents. The following flags further affects its
behavior. This does not apply to the case where two <tree-ish>
-separated with a single space are given.
+separated with a single space are given.
-m
- By default, git-diff-tree --stdin does not show
+ By default, git-diff-tree --stdin does not show
differences for merge commits. With this flag, it shows
differences to that commit from all of its parents. See
also -c .
@@ -838,7 +886,7 @@ separated with a single space are given.
- By default, git-diff-tree --stdin shows differences,
+ By default, git-diff-tree --stdin shows differences,
either in machine-readable form (without -p ) or in patch
form (with -p ). This output can be suppressed. It is
only useful with -v flag.
@@ -849,7 +897,7 @@ separated with a single space are given.
- This flag causes git-diff-tree --stdin to also show
+ This flag causes git-diff-tree --stdin to also show
the commit message before the differences.
@@ -863,8 +911,8 @@ separated with a single space are given.
full , fuller , email , raw and format:<string> .
When omitted, the format defaults to medium .
-Note: you can specify the default pretty format in the repository
-configuration (see git-config(1) ).
+Note: you can specify the default pretty format in the repository
+configuration (see git-config(1) ).
--abbrev-commit
@@ -876,8 +924,8 @@ configuration (see git-config(1) ).
digits can be specified with "--abbrev=<n>" (which also modifies
diff output, if it is displayed).
-This should make "--pretty=oneline" a whole lot more readable for
-people using 80-column terminals.
+This should make "--pretty=oneline" a whole lot more readable for
+people using 80-column terminals.
--encoding[=<encoding>]
@@ -896,7 +944,7 @@ people using 80-column terminals.
- git-diff-tree outputs a line with the commit ID when
+ git-diff-tree outputs a line with the commit ID when
applicable. This flag suppressed the commit ID output.
@@ -939,11 +987,11 @@ people using 80-column terminals.
if the diff itself is empty.
-
+
-PRETTY FORMATS
+
-
If the commit is a merge, and if the pretty-format
+
If the commit is a merge, and if the pretty-format
is not oneline , email or raw , an additional line is
inserted before the Author: line. This line begins with
"Merge: " and the sha1s of ancestral commits are printed,
@@ -951,9 +999,9 @@ separated by spaces. Note that the listed commits may not
necessarily be the list of the direct parent commits if you
have limited your view of history: for example, if you are
only interested in changes related to a certain directory or
-file.
-
Here are some additional details for each format:
-
+
Here are some additional details for each format:
+
-
This is designed to be as compact as possible.
+
This is designed to be as compact as possible.
@@ -986,7 +1034,7 @@ Author: <author>
commit <sha1>
Author: <author>
-Date: <date>
+Date: <author date>
@@ -1024,9 +1072,9 @@ Commit: <committer>
commit <sha1>
Author: <author>
-AuthorDate: <date & time>
+AuthorDate: <author date>
Commit: <committer>
-CommitDate: <date & time>
+CommitDate: <committer date>
@@ -1045,7 +1093,7 @@ CommitDate: <date & time>
From <sha1> <date>
From: <author>
-Date: <date & time>
+Date: <author date>
Subject: [PATCH] <title line>
@@ -1057,31 +1105,31 @@ Subject: [PATCH] <title line>
raw
-
The raw format shows the entire commit exactly as
+
The raw format shows the entire commit exactly as
stored in the commit object. Notably, the SHA1s are
displayed in full, regardless of whether --abbrev or
--no-abbrev are used, and parents information show the
true parent commits, without taking grafts nor history
-simplification into account.
+simplification into account.
format:
-The format: format allows you to specify which information
+
The format: format allows you to specify which information
you want to show. It works a little bit like printf format,
with the notable exception that you get a newline with %n
-instead of \n .
-
E.g, format:"The author of %h was %an, %ar%nThe title was >>%s<<%n"
-would show something like this:
+instead of
\n .
+E.g, format:"The author of %h was %an, %ar%nThe title was >>%s<<%n"
+would show something like this:
The author of fe6e0ee was Junio C Hamano, 23 hours ago
The title was >>t4119: test autocomputing -p<n> for traditional diff input.<<
-The placeholders are:
-
tformat:
-The tformat: format works exactly like format: , except that it
+
The tformat: format works exactly like format: , except that it
provides "terminator" semantics instead of "separator" semantics. In
other words, each commit has the message terminator character (usually a
newline) appended, rather than a separator placed between entries.
This means that the final entry of a single-line format will be properly
terminated with a new line, just as the "oneline" format does.
-For example:
+For example:
$ git log -2 --pretty=format:%h 4da45bef \
@@ -1258,35 +1306,35 @@ $ git log -2 --pretty=tformat:%h 4da45bef \
7134973
-
+
-
Limiting Output
+
Limiting Output
-
If you're only interested in differences in a subset of files, for
-example some architecture-specific files, you might do:
+
If you're only interested in differences in a subset of files, for
+example some architecture-specific files, you might do:
git diff-tree -r <tree-ish> <tree-ish> arch/ia64 include/asm-ia64
-
and it will only show you what changed in those two directories.
-
Or if you are searching for what changed in just kernel/sched.c , just do
+
and it will only show you what changed in those two directories.
+
Or if you are searching for what changed in just kernel/sched.c , just do
git diff-tree -r <tree-ish> <tree-ish> kernel/sched.c
-
and it will ignore all differences to other files.
-
The pattern is always the prefix, and is matched exactly. There are no
+
and it will ignore all differences to other files.
+
The pattern is always the prefix, and is matched exactly. There are no
wildcards. Even stricter, it has to match a complete path component.
I.e. "foo" does not pick up foobar.h . "foo" does match foo/bar.h
-so it can be used to name subdirectories.
-
An example of normal usage is:
+so it can be used to name subdirectories.
+
An example of normal usage is:
torvalds@ppc970:~/git> git diff-tree 5319e4......
*100664->100664 blob ac348b.......->a01513....... git-fsck-objects.c
-
which tells you that the last commit changed just one file (it's from
-this one:
+
which tells you that the last commit changed just one file (it's from
+this one:
commit 3c6f7ca19ad4043e9e72fa94106f352897e651a8
@@ -1300,15 +1348,15 @@ Make "git-fsck-objects" print out all the root commits it finds.
Once I do the reference tracking, I'll also make it print out all the
HEAD commits it finds, which is even more interesting.
-
in case you care).
+
-
Output format
+
-
The output format from "git-diff-index", "git-diff-tree",
-"git-diff-files" and "git diff --raw" are very similar.
-
These commands all compare two sets of things; what is
-compared differs:
-
+The output format from "git-diff-index", "git-diff-tree",
+"git-diff-files" and "git diff --raw" are very similar.
+These commands all compare two sets of things; what is
+compared differs:
+
git-diff-index <tree-ish>
@@ -1341,8 +1389,8 @@ git-diff-files [<pattern>…]
compares the index and the files on the filesystem.
-
-
An output line is formatted this way:
+
+An output line is formatted this way:
in-place edit :100644 100644 bcd1234... 0123456... M file0
@@ -1352,8 +1400,8 @@ create :000000 100644 0000000... 1234567... A file4
delete :100644 000000 1234567... 0000000... D file5
unmerged :000000 000000 0000000... 0000000... U file6
-That is, from the left to the right:
-
+That is, from the left to the right:
+
a colon.
@@ -1429,25 +1477,25 @@ path for "dst"; only exists for C or R.
an LF or a NUL when -z option is used, to terminate the record.
-
-
<sha1> is shown as all 0's if a file is new on the filesystem
-and it is out of sync with the index.
-
Example:
+
+<sha1> is shown as all 0's if a file is new on the filesystem
+and it is out of sync with the index.
+
:100644 100644 5be4a4...... 000000...... M file.c
-When -z option is not used, TAB, LF, and backslash characters
+
When -z option is not used, TAB, LF, and backslash characters
in pathnames are represented as \t , \n , and \\ ,
-respectively.
+respectively.
-
diff format for merges
+
-
"git-diff-tree", "git-diff-files" and "git-diff --raw"
+
"git-diff-tree", "git-diff-files" and "git-diff --raw"
can take -c or --cc option
to generate diff output also for merge commits. The output differs
-from the format described above in the following way:
-
+from the format described above in the following way:
+
there is a colon for each parent
@@ -1473,26 +1521,26 @@ no optional "score" number
single path, only for "dst"
-
-
Example:
+
+
::100644 100644 100644 fabadb8... cc95eb0... 4866510... MM describe.c
-
Note that combined diff lists only files which were modified from
-all parents.
+
Note that combined diff lists only files which were modified from
+all parents.
-
Generating patches with -p
+
Generating patches with -p
-
When "git-diff-index", "git-diff-tree", or "git-diff-files" are run
+
When "git-diff-index", "git-diff-tree", or "git-diff-files" are run
with a -p option, "git diff" without the --raw option, or
"git log" with the "-p" option, they
do not produce the output described above; instead they produce a
patch file. You can customize the creation of such patches via the
-GIT_EXTERNAL_DIFF and the GIT_DIFF_OPTS environment variables.
-
What the -p option produces is slightly different from the traditional
-diff format.
-
+GIT_EXTERNAL_DIFF and the GIT_DIFF_OPTS environment variables.
+
What the -p option produces is slightly different from the traditional
+diff format.
+
It is preceded with a "git diff" header, that looks like
@@ -1502,12 +1550,12 @@ It is preceded with a "git diff" header, that looks like
diff --git a/file1 b/file2
-
The a/ and b/ filenames are the same unless rename/copy is
+
The a/ and b/ filenames are the same unless rename/copy is
involved. Especially, even for a creation or a deletion,
-/dev/null is _not_ used in place of a/ or b/ filenames.
-
When rename/copy is involved, file1 and file2 show the
+/dev/null is not used in place of a/ or b/ filenames.
+
When rename/copy is involved, file1 and file2 show the
name of the source file of the rename/copy and the name of
-the file that rename/copy produces, respectively.
+the file that rename/copy produces, respectively.
@@ -1536,20 +1584,20 @@ TAB, LF, double quote and backslash characters in pathnames
pathname is put in double quotes.
-
-
The similarity index is the percentage of unchanged lines, and
+
+
The similarity index is the percentage of unchanged lines, and
the dissimilarity index is the percentage of changed lines. It
is a rounded down integer, followed by a percent sign. The
similarity index value of 100% is thus reserved for two equal
files, while 100% dissimilarity means that no line from the old
-file made it into the new one.
+file made it into the new one.
-combined diff format
+
-
"git-diff-tree", "git-diff-files" and "git-diff" can take -c or
+
"git-diff-tree", "git-diff-files" and "git-diff" can take -c or
--cc option to produce combined diff . For showing a merge commit
with "git log -p", this is the default format.
-A combined diff format looks like this:
+A
combined diff format looks like this:
diff --combined describe.c
@@ -1580,7 +1628,7 @@ index fabadb8,cc95eb0..4866510
initialized = 1;
for_each_ref(get_name);
-
+
It is preceded with a "git diff" header, that looks like
@@ -1590,7 +1638,7 @@ It is preceded with a "git diff" header, that looks like
-or like this (when --cc option is used):
+or like this (when --cc option is used):
diff --c file
@@ -1608,11 +1656,11 @@ mode <mode>,<mode>..<mode>
new file mode <mode>
deleted file mode <mode>,<mode>
-The mode <mode>,<mode>..<mode> line appears only if at least one of
+
The mode <mode>,<mode>..<mode> line appears only if at least one of
the <mode> is different from the rest. Extended headers with
information about detected contents movement (renames and
copying detection) are designed to work with diff of two
-<tree-ish> and are not used by combined diff format.
+<tree-ish> and are not used by combined diff format.
@@ -1623,9 +1671,9 @@ It is followed by two-line from-file/to-file header
--- a/file
+++ b/file
-Similar to two-line header for traditional unified diff
+
Similar to two-line header for traditional unified diff
format, /dev/null is used to signal created or deleted
-files.
+files.
@@ -1639,59 +1687,59 @@ Chunk header format is modified to prevent people from
@@@ <from-file-range> <from-file-range> <to-file-range> @@@
-There are (number of parents + 1) @ characters in the chunk
-header for combined diff format.
+There are (number of parents + 1) @ characters in the chunk
+header for combined diff format.
-
-Unlike the traditional unified diff format, which shows two
+
+
Unlike the traditional unified diff format, which shows two
files A and B with a single column that has - (minus —
appears in A but removed in B), + (plus — missing in A but
added to B), or " " (space — unchanged) prefix, this format
compares two or more files file1, file2,… with one file X, and
shows how X differs from each of fileN. One column for each of
fileN is prepended to the output line to note how X's line is
-different from it.
-
A - character in the column N means that the line appears in
+different from it.
+A - character in the column N means that the line appears in
fileN but it does not appear in the result. A + character
in the column N means that the line appears in the last file,
and fileN does not have that line (in other words, the line was
-added, from the point of view of that parent).
-
In the above example output, the function signature was changed
+added, from the point of view of that parent).
+In the above example output, the function signature was changed
from both files (hence two - removals from both file1 and
-file2, plus ++ to mean one line that was added does not appear
+file2, plus + to mean one line that was added does not appear
in either file1 nor file2). Also two other lines are the same
-from file1 but do not appear in file2 (hence prefixed with + ).
-
When shown by git diff-tree -c , it compares the parents of a
+from file1 but do not appear in file2 (hence prefixed with ).
+When shown by git diff-tree -c , it compares the parents of a
merge commit with the merge result (i.e. file1..fileN are the
parents). When shown by git diff-files -c , it compares the
two unresolved merge parents with the working tree file
(i.e. file1 is stage 2 aka "our version", file2 is stage 3 aka
-"their version").
+"their version").
-other diff formats
+
-
The --summary option describes newly added, deleted, renamed and
+
The --summary option describes newly added, deleted, renamed and
copied files. The --stat option adds diffstat(1) graph to the
output. These options can be combined with other options, such as
--p , and are meant for human consumption.
-
When showing a change that involves a rename or a copy, --stat output
+-p , and are meant for human consumption.
+
When showing a change that involves a rename or a copy, --stat output
formats the pathnames compactly by combining common prefix and suffix of
the pathnames. For example, a change that moves arch/i386/Makefile to
-arch/x86/Makefile while modifying 4 lines will be shown like this:
+
arch/x86/Makefile while modifying 4 lines will be shown like this:
arch/{i386 => x86}/Makefile | 4 +--
-
The --numstat option gives the diffstat(1) information but is designed
+
The --numstat option gives the diffstat(1) information but is designed
for easier machine consumption. An entry in --numstat output looks
-like this:
+like this:
1 2 README
3 1 arch/{i386 => x86}/Makefile
-
That is, from left to right:
-
+That is, from left to right:
+
the number of added lines;
@@ -1722,15 +1770,15 @@ pathname (possibly with rename/copy information);
a newline.
-
-
When -z output option is in effect, the output is formatted this way:
+
+When -z output option is in effect, the output is formatted this way:
1 2 README NUL
3 1 NUL arch/i386/Makefile NUL arch/x86/Makefile NUL
-That is:
-
+
+
the number of added lines;
@@ -1776,28 +1824,28 @@ pathname in postimage (only exists if renamed/copied);
a NUL.
-
-
The extra NUL before the preimage path in renamed case is to allow
+
+The extra NUL before the preimage path in renamed case is to allow
scripts that read the output to tell if the current record being read is
a single-path record or a rename/copy record without reading ahead.
After reading added and deleted lines, reading up to NUL would yield
-the pathname, but if that is NUL , the record will show two paths.
+the pathname, but if that is
NUL , the record will show two paths.
-Author
+Author
-
Written by Linus Torvalds <torvalds@osdl.org>
+
Written by Linus Torvalds <torvalds@osdl.org>
-Documentation
+Documentation
-
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-diff-tree.txt b/git-diff-tree.txt
index 68feb0817..0e45b58d8 100644
--- a/git-diff-tree.txt
+++ b/git-diff-tree.txt
@@ -20,7 +20,7 @@ Compares the content and mode of the blobs found via two tree objects.
If there is only one given, the commit is compared with its parents
(see --stdin below).
-Note that `git-diff-tree` can use the tree encapsulated in a commit object.
+Note that 'git-diff-tree' can use the tree encapsulated in a commit object.
OPTIONS
-------
@@ -58,25 +58,25 @@ behavior. This does not apply to the case where two
separated with a single space are given.
-m::
- By default, `git-diff-tree --stdin` does not show
+ By default, 'git-diff-tree --stdin' does not show
differences for merge commits. With this flag, it shows
differences to that commit from all of its parents. See
also '-c'.
-s::
- By default, `git-diff-tree --stdin` shows differences,
+ By default, 'git-diff-tree --stdin' shows differences,
either in machine-readable form (without '-p') or in patch
form (with '-p'). This output can be suppressed. It is
only useful with '-v' flag.
-v::
- This flag causes `git-diff-tree --stdin` to also show
+ This flag causes 'git-diff-tree --stdin' to also show
the commit message before the differences.
include::pretty-options.txt[]
--no-commit-id::
- `git-diff-tree` outputs a line with the commit ID when
+ 'git-diff-tree' outputs a line with the commit ID when
applicable. This flag suppressed the commit ID output.
-c::
diff --git a/git-fast-export.html b/git-fast-export.html
index 003af0a6e..717496097 100644
--- a/git-fast-export.html
+++ b/git-fast-export.html
@@ -3,7 +3,7 @@
-
+
git-fast-export(1)
@@ -272,26 +320,26 @@ git-fast-export(1) Manual Page
SYNOPSIS
-
git fast-export [options] | git fast-import
+
git fast-export [options] | git fast-import
-DESCRIPTION
+DESCRIPTION
-
This program dumps the given revisions in a form suitable to be piped
-into git-fast-import .
-
You can use it as a human readable bundle replacement (see
+
This program dumps the given revisions in a form suitable to be piped
+into git-fast-import .
+
You can use it as a human readable bundle replacement (see
git-bundle(1) ), or as a kind of an interactive
-git-filter-branch .
+
git-filter-branch .
-OPTIONS
+OPTIONS
-
+
--progress=<n>
Insert progress statements every <n> objects, to be shown by
- git-fast-import during import.
+ git-fast-import during import.
@@ -303,10 +351,10 @@ into git-fast-import .
after the export can change the tag names (which can also happen
when excluding revisions) the signatures will not match.
-When asking to abort (which is the default), this program will die
+
When asking to abort (which is the default), this program will die
when encountering a signed tag. With strip , the tags will be made
unsigned, with verbatim , they will be silently exported
-and with warn , they will be exported, but you will see a warning.
+and with
warn , they will be exported, but you will see a warning.
--export-marks=<file>
@@ -332,55 +380,55 @@ and with warn , they will be exported, but you will see a warning.
<file>. The input file must exist, must be readable, and
must use the same format as produced by --export-marks.
-Any commits that have already been marked will not be exported again.
+
Any commits that have already been marked will not be exported again.
If the backend uses a similar --import-marks file, this allows for
incremental bidirectional exporting of the repository by keeping the
-marks the same across runs.
+marks the same across runs.
-
+
-EXAMPLES
+EXAMPLES
$ git fast-export --all | (cd /empty/repository && git fast-import)
-
This will export the whole repository and import it into the existing
+
This will export the whole repository and import it into the existing
empty repository. Except for reencoding commits that are not in
-UTF-8, it would be a one-to-one mirror.
+UTF-8, it would be a one-to-one mirror.
$ git fast-export master~5..master |
sed "s|refs/heads/master|refs/heads/other|" |
git fast-import
-
This makes a new branch called other from master~5..master
-(i.e. if master has linear history, it will take the last 5 commits).
-
Note that this assumes that none of the blobs and commit messages
+
This makes a new branch called other from master~5..master
+(i.e. if master has linear history, it will take the last 5 commits).
+
Note that this assumes that none of the blobs and commit messages
referenced by that revision range contains the string
-refs/heads/master .
+
refs/heads/master .
-Limitations
+Limitations
-
Since git-fast-import cannot tag trees, you will not be
+
Since git-fast-import cannot tag trees, you will not be
able to export the linux-2.6.git repository completely, as it contains
-a tag referencing a tree instead of a commit.
+a tag referencing a tree instead of a commit.
-Author
+Author
-
Written by Johannes E. Schindelin <johannes.schindelin@gmx.de>.
+
Written by Johannes E. Schindelin <johannes.schindelin@gmx.de>.
-Documentation
+Documentation
-
Documentation by Johannes E. Schindelin <johannes.schindelin@gmx.de>.
+
Documentation by Johannes E. Schindelin <johannes.schindelin@gmx.de>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-fast-export.txt b/git-fast-export.txt
index dbc2b190e..4956964d8 100644
--- a/git-fast-export.txt
+++ b/git-fast-export.txt
@@ -13,18 +13,18 @@ SYNOPSIS
DESCRIPTION
-----------
This program dumps the given revisions in a form suitable to be piped
-into `git-fast-import`.
+into 'git-fast-import'.
You can use it as a human readable bundle replacement (see
linkgit:git-bundle[1]), or as a kind of an interactive
-`git-filter-branch`.
+'git-filter-branch'.
OPTIONS
-------
--progress=::
Insert 'progress' statements every objects, to be shown by
- `git-fast-import` during import.
+ 'git-fast-import' during import.
--signed-tags=(verbatim|warn|strip|abort)::
Specify how to handle signed tags. Since any transformation
@@ -85,7 +85,7 @@ referenced by that revision range contains the string
Limitations
-----------
-Since `git-fast-import` cannot tag trees, you will not be
+Since 'git-fast-import' cannot tag trees, you will not be
able to export the linux-2.6.git repository completely, as it contains
a tag referencing a tree instead of a commit.
diff --git a/git-fast-import.html b/git-fast-import.html
index 3a52e701a..5b0932dbf 100644
--- a/git-fast-import.html
+++ b/git-fast-import.html
@@ -3,7 +3,7 @@
-
+
git-fast-import(1)
@@ -272,28 +320,28 @@ git-fast-import(1) Manual Page
SYNOPSIS
-
frontend | git fast-import [options]
+
frontend | git fast-import [options]
-DESCRIPTION
+DESCRIPTION
-
This program is usually not what the end user wants to run directly.
+
This program is usually not what the end user wants to run directly.
Most end users want to use one of the existing frontend programs,
which parses a specific type of foreign source and feeds the contents
-stored there to git-fast-import .
-
fast-import reads a mixed command/data stream from standard input and
+stored there to git-fast-import .
+
fast-import reads a mixed command/data stream from standard input and
writes one or more packfiles directly into the current repository.
When EOF is received on standard input, fast import writes out
updated branch and tag refs, fully updating the current repository
-with the newly imported data.
-
The fast-import backend itself can import into an empty repository (one that
-has already been initialized by git-init ) or incrementally
+with the newly imported data.
+
The fast-import backend itself can import into an empty repository (one that
+has already been initialized by git-init ) or incrementally
update an existing populated repository. Whether or not incremental
imports are supported from a particular foreign source depends on
-the frontend program in use.
+the frontend program in use.
-OPTIONS
+OPTIONS
-
+
--date-format=<fmt>
@@ -383,7 +431,7 @@ the frontend program in use.
This information may be useful after importing projects
whose total object set exceeds the 4 GiB packfile limit,
as these commits can be used as edge points during calls
- to git-pack-objects .
+ to git-pack-objects .
@@ -407,91 +455,91 @@ the frontend program in use.
is currently the default, but can be disabled with --quiet.
-
+
-Performance
+
-
The design of fast-import allows it to import large projects in a minimum
+
The design of fast-import allows it to import large projects in a minimum
amount of memory usage and processing time. Assuming the frontend
is able to keep up with fast-import and feed it a constant stream of data,
import times for projects holding 10+ years of history and containing
100,000+ individual commits are generally completed in just 1-2
-hours on quite modest (~$2,000 USD) hardware.
-
Most bottlenecks appear to be in foreign source data access (the
+hours on quite modest (~$2,000 USD) hardware.
+
Most bottlenecks appear to be in foreign source data access (the
source just cannot extract revisions fast enough) or disk IO (fast-import
writes as fast as the disk will take the data). Imports will run
faster if the source data is stored on a different drive than the
-destination Git repository (due to less IO contention).
+destination Git repository (due to less IO contention).
-Development Cost
+Development Cost
-
A typical frontend for fast-import tends to weigh in at approximately 200
+
A typical frontend for fast-import tends to weigh in at approximately 200
lines of Perl/Python/Ruby code. Most developers have been able to
create working importers in just a couple of hours, even though it
is their first exposure to fast-import, and sometimes even to Git. This is
an ideal situation, given that most conversion tools are throw-away
-(use once, and never look back).
+(use once, and never look back).
-Parallel Operation
+Parallel Operation
-
Like git-push or git-fetch , imports handled by fast-import are safe to
+
Like git-push or git-fetch , imports handled by fast-import are safe to
run alongside parallel git repack -a -d or git gc invocations,
-or any other Git operation (including git-prune , as loose objects
-are never used by fast-import).
-
fast-import does not lock the branch or tag refs it is actively importing.
+or any other Git operation (including git-prune , as loose objects
+are never used by fast-import).
+
fast-import does not lock the branch or tag refs it is actively importing.
After the import, during its ref update phase, fast-import tests each
existing branch ref to verify the update will be a fast-forward
update (the commit stored in the ref is contained in the new
history of the commit to be written). If the update is not a
fast-forward update, fast-import will skip updating that ref and instead
prints a warning message. fast-import will always attempt to update all
-branch refs, and does not stop on the first failure.
-
Branch updates can be forced with --force, but its recommended that
+branch refs, and does not stop on the first failure.
+
Branch updates can be forced with --force, but its recommended that
this only be used on an otherwise quiet repository. Using --force
-is not necessary for an initial import into an empty repository.
+is not necessary for an initial import into an empty repository.
-Technical Discussion
+Technical Discussion
-
fast-import tracks a set of branches in memory. Any branch can be created
+
fast-import tracks a set of branches in memory. Any branch can be created
or modified at any point during the import process by sending a
commit command on the input stream. This design allows a frontend
program to process an unlimited number of branches simultaneously,
generating commits in the order they are available from the source
-data. It also simplifies the frontend programs considerably.
-
fast-import does not use or alter the current working directory, or any
+data. It also simplifies the frontend programs considerably.
+
fast-import does not use or alter the current working directory, or any
file within it. (It does however update the current Git repository,
as referenced by GIT_DIR .) Therefore an import frontend may use
the working directory for its own purposes, such as extracting file
revisions from the foreign source. This ignorance of the working
directory also allows fast-import to run very quickly, as it does not
need to perform any costly file update operations when switching
-between branches.
+between branches.
-Input Format
+
-
With the exception of raw file data (which Git does not interpret)
+
With the exception of raw file data (which Git does not interpret)
the fast-import input format is text (ASCII) based. This text based
format simplifies development and debugging of frontend programs,
especially when a higher level language such as Perl, Python or
-Ruby is being used.
-
fast-import is very strict about its input. Where we say SP below we mean
+Ruby is being used.
+
fast-import is very strict about its input. Where we say SP below we mean
exactly one space. Likewise LF means one (and only one) linefeed.
Supplying additional whitespace characters will cause unexpected
results, such as branch names or file names with leading or trailing
spaces in their name, or early termination of fast-import when it encounters
-unexpected input.
-
Stream Comments
-
To aid in debugging frontends fast-import ignores any line that
+unexpected input.
+
+
To aid in debugging frontends fast-import ignores any line that
begins with # (ASCII pound/hash) up to and including the line
ending LF . A comment line may contain any sequence of bytes
that does not contain an LF and therefore may be used to include
any detailed debugging information that might be specific to the
-frontend and useful when inspecting a fast-import data stream.
-
Date Formats
-
The following date formats are supported. A frontend should select
+frontend and useful when inspecting a fast-import data stream.
+
+
The following date formats are supported. A frontend should select
the format it will use for this import by passing the format name
-in the --date-format=<fmt> command line option.
-
+in the --date-format=<fmt> command line option.
+
raw
@@ -501,21 +549,21 @@ in the --date-format=<fmt> command line option.
It is also fast-import's default format, if --date-format was
not specified.
-The time of the event is specified by <time> as the number of
+
The time of the event is specified by <time> as the number of
seconds since the UNIX epoch (midnight, Jan 1, 1970, UTC) and is
-written as an ASCII decimal integer.
-
The local offset is specified by <offutc> as a positive or negative
+written as an ASCII decimal integer.
+The local offset is specified by <offutc> as a positive or negative
offset from UTC. For example EST (which is 5 hours behind UTC)
would be expressed in <tz> by “-0500” while UTC is “+0000”.
The local offset does not affect <time> ; it is used only as an
-advisement to help formatting routines display the timestamp.
-
If the local offset is not available in the source material, use
+advisement to help formatting routines display the timestamp.
+If the local offset is not available in the source material, use
“+0000”, or the most common local offset. For example many
organizations have a CVS repository which has only ever been accessed
by users who are located in the same location and timezone. In this
-case a reasonable offset from UTC could be assumed.
-
Unlike the rfc2822 format, this format is very strict. Any
-variation in formatting will cause fast-import to reject the value.
+case a reasonable offset from UTC could be assumed.
+Unlike the rfc2822 format, this format is very strict. Any
+variation in formatting will cause fast-import to reject the value.
rfc2822
@@ -524,27 +572,27 @@ variation in formatting will cause fast-import to reject the value.
This is the standard email format as described by RFC 2822.
-An example value is “Tue Feb 6 11:22:18 2007 -0500”. The Git
+
An example value is “Tue Feb 6 11:22:18 2007 -0500”. The Git
parser is accurate, but a little on the lenient side. It is the
-same parser used by git-am when applying patches
-received from email.
-
Some malformed strings may be accepted as valid dates. In some of
+same parser used by git-am when applying patches
+received from email.
+Some malformed strings may be accepted as valid dates. In some of
these cases Git will still be able to obtain the correct date from
the malformed string. There are also some types of malformed
strings which Git will parse wrong, and yet consider valid.
-Seriously malformed strings will be rejected.
-
Unlike the raw format above, the timezone/UTC offset information
+Seriously malformed strings will be rejected.
+Unlike the raw format above, the timezone/UTC offset information
contained in an RFC 2822 date string is used to adjust the date
value to UTC prior to storage. Therefore it is important that
-this information be as accurate as possible.
-
If the source material uses RFC 2822 style dates,
+this information be as accurate as possible.
+If the source material uses RFC 2822 style dates,
the frontend should let fast-import handle the parsing and conversion
(rather than attempting to do it itself) as the Git parser has
-been well tested in the wild.
-
Frontends should prefer the raw format if the source material
+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 easily convertible to it, as there is no
-ambiguity in parsing.
+ambiguity in parsing.
now
@@ -554,27 +602,27 @@ ambiguity in parsing.
Always use the current time and timezone. The literal
now must always be supplied for <when> .
-This is a toy format. The current time and timezone of this system
+
This is a toy format. The current time and timezone of this system
is always copied into the identity string at the time it is being
created by fast-import. There is no way to specify a different time or
-timezone.
-
This particular format is supplied as its short to implement and
+timezone.
+This particular format is supplied as its short to implement and
may be useful to a process that wants to create a new commit
right now, without needing to use a working directory or
-git-update-index .
-
If separate author and committer commands are used in a commit
+git-update-index .
+If separate author and committer commands are used in a commit
the timestamps may not match, as the system clock will be polled
twice (once for each command). The only way to ensure that both
author and committer identity information has the same timestamp
is to omit author (thus copying from committer ) or to use a
-date format other than now .
+date format other than
now .
-
-
Commands
-
fast-import accepts several commands to update the current repository
+
+
Commands
+
fast-import accepts several commands to update the current repository
and control the current import process. More detailed discussion
-(with examples) of each command follows later.
-
+(with examples) of each command follows later.
+
commit
@@ -637,10 +685,10 @@ and control the current import process. More detailed discussion
to perform an import.
-
-
commit
-
Create or update a branch with a new commit, recording one logical
-change to the project.
+
+
commit
+
Create or update a branch with a new commit, recording one logical
+change to the project.
'commit' SP <ref> LF
@@ -653,56 +701,56 @@ change to the project.
(filemodify | filedelete | filecopy | filerename | filedeleteall)*
LF?
-
where <ref> is the name of the branch to make the commit on.
+
where <ref> is the name of the branch to make the commit on.
Typically branch names are prefixed with refs/heads/ in
Git, so importing the CVS branch symbol RELENG-1_0 would use
refs/heads/RELENG-1_0 for the value of <ref> . The value of
<ref> must be a valid refname in Git. As LF is not valid in
-a Git refname, no quoting or escaping syntax is supported here.
-
A mark command may optionally appear, requesting fast-import to save a
+a Git refname, no quoting or escaping syntax is supported here.
+
A mark command may optionally appear, requesting fast-import to save a
reference to the newly created commit for future use by the frontend
(see below for format). It is very common for frontends to mark
every commit they create, thereby allowing future branch creation
-from any imported commit.
-
The data command following committer must supply the commit
+from any imported commit.
+
The data command following committer must supply the commit
message (see below for data command syntax). To import an empty
commit message use a 0 length data. Commit messages are free-form
and are not interpreted by Git. Currently they must be encoded in
-UTF-8, as fast-import does not permit other encodings to be specified.
-
Zero or more filemodify , filedelete , filecopy , filerename
+UTF-8, as fast-import does not permit other encodings to be specified.
+
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 precede
all filemodify , filecopy and filerename commands in the same
commit, as filedeleteall
-wipes the branch clean (see below).
-
The LF after the command is optional (it used to be required).
-
author
-
An author command may optionally appear, if the author information
+wipes the branch clean (see below).
+
The LF after the command is optional (it used to be required).
+
author
+
An author command may optionally appear, if the author information
might differ from the committer information. If author is omitted
then fast-import will automatically use the committer's information for
the author portion of the commit. See below for a description of
-the fields in author , as they are identical to committer .
-
committer
-
The committer command indicates who made this commit, and when
-they made it.
-
Here <name> is the person's display name (for example
+the fields in author , as they are identical to committer .
+
committer
+
The committer command indicates who made this commit, and when
+they made it.
+
Here <name> is the person's display name (for example
“Com M Itter”) and <email> is the person's email address
(“cm@example.com”). LT and GT are the literal less-than (\x3c)
and greater-than (\x3e) symbols. These are required to delimit
the email address from the other fields in the line. Note that
<name> is free-form and may contain any sequence of bytes, except
-LT and LF . It is typically UTF-8 encoded.
-
The time of the change is specified by <when> using the date format
+LT and LF . It is typically UTF-8 encoded.
+
The time of the change is specified by <when> using the date format
that was selected by the --date-format=<fmt> command line option.
See “Date Formats” above for the set of supported formats, and
-their syntax.
-
from
-
The from command is used to specify the commit to initialize
+their syntax.
+
from
+
The from command is used to specify the commit to initialize
this branch from. This revision will be the first ancestor of the
-new commit.
-
Omitting the from command in the first commit of a new branch
+new commit.
+
Omitting the from command in the first commit of a new branch
will cause fast-import to create that commit with no ancestor. This
tends to be desired only for the initial commit of a project.
If the frontend creates all files from scratch when making a new
@@ -710,11 +758,11 @@ branch, a merge command may be used instead of from to start
the commit with an empty tree.
Omitting the from command on existing branches is usually desired,
as the current commit on that branch is automatically assumed to
-be the first ancestor of the new commit.
-
As LF is not valid in a Git refname or SHA-1 expression, no
-quoting or escaping syntax is supported within <committish> .
-
Here <committish> is any of the following:
-
+be the first ancestor of the new commit.
+
As LF is not valid in a Git refname or SHA-1 expression, no
+quoting or escaping syntax is supported within <committish> .
+
Here <committish> is any of the following:
+
The name of an existing branch already in fast-import's internal branch
@@ -726,12 +774,12 @@ The name of an existing branch already in fast-import's internal branch
A mark reference, :<idnum> , where <idnum> is the mark number.
-The reason fast-import uses : to denote a mark reference is this character
+
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 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.
+consist only of base-10 digits.
+Marks must be declared (via mark ) before they can be used.
@@ -744,21 +792,21 @@ Any valid Git SHA-1 expression that resolves to a commit. See
“SPECIFYING REVISIONS” in git-rev-parse(1) for details.
-
-
The special case of restarting an incremental import from the
-current branch value should be written as:
+
+
The special case of restarting an incremental import from the
+current branch value should be written as:
-
The ^0 suffix is necessary as fast-import does not permit a branch to
+
The ^0 suffix is necessary as fast-import does not permit a branch to
start from itself, and the branch is created in memory before the
from command is even read from the input. Adding ^0 will force
fast-import to resolve the commit through Git's revision parsing library,
rather than its internal branch table, thereby loading in the
-existing value of the branch.
-
merge
-
Includes one additional ancestor commit. If the from command is
+existing value of the branch.
+
merge
+
Includes one additional ancestor commit. If the from command is
omitted when creating a new branch, the first merge commit will be
the first ancestor of the current commit, and the branch will start
out with no files. An unlimited number of merge commands per
@@ -766,14 +814,14 @@ commit are permitted by fast-import, thereby establishing an n-way merge.
However Git's other tools never create commits with more than 15
additional ancestors (forming a 16-way merge). For this reason
it is suggested that frontends do not use more than 15 merge
-commands per commit; 16, if starting a new, empty branch.
-
Here <committish> is any of the commit specification expressions
-also accepted by from (see above).
-
filemodify
-
Included in a commit command to add a new file or change the
+commands per commit; 16, if starting a new, empty branch.
+
Here <committish> is any of the commit specification expressions
+also accepted by from (see above).
+
filemodify
+
Included in a commit command to add a new file or change the
content of an existing file. This command has two different means
-of specifying the content of the file.
-
+of specifying the content of the file.
+
External data format
@@ -786,9 +834,9 @@ External data format
'M' SP <mode> SP <dataref> SP <path> LF
-
Here <dataref> can be either a mark reference (:<idnum> )
+
Here <dataref> can be either a mark reference (:<idnum> )
set by a prior blob command, or a full 40-byte SHA-1 of an
-existing Git blob object.
+existing Git blob object.
Inline data format
@@ -804,12 +852,12 @@ Inline data format
'M' SP <mode> SP 'inline' SP <path> LF
data
-See below for a detailed description of the data command.
+See below for a detailed description of the data command.
-
-In both formats <mode> is the type of file entry, specified
-in octal. Git only supports the following modes:
-
+
+In both formats <mode> is the type of file entry, specified
+in octal. Git only supports the following modes:
+
-
In both formats <path> is the complete path of the file to be added
-(if not already existing) or modified (if already existing).
-
A <path> string must use UNIX-style directory separators (forward
+
+In both formats <path> is the complete path of the file to be added
+(if not already existing) or modified (if already existing).
+A <path> string must use UNIX-style directory separators (forward
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 canonical form. That is it 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 canonical form. That is it must not:
+
contain an empty directory component (e.g. foo//bar is invalid),
@@ -858,102 +906,102 @@ contain the special component . or .. (e.g. foo/./bar
foo/../bar are invalid).
-
-
It is recommended that <path> always be encoded using UTF-8.
-
filedelete
-
Included in a commit command to remove a file or recursively
+
+It is recommended that <path> always be encoded using UTF-8.
+filedelete
+Included in a commit command to remove a file or recursively
delete an entire directory from the branch. If the file or directory
removal makes its parent directory empty, the parent directory will
be automatically removed too. This cascades up the tree until the
-first non-empty directory or the root is reached.
+first non-empty directory or the root is reached.
-here <path> is the complete path of the file or subdirectory to
+
here <path> is the complete path of the file or subdirectory to
be removed from the branch.
-See filemodify above for a detailed description of <path> .
-
filecopy
-
Recursively copies an existing file or subdirectory to a different
+See filemodify above for a detailed description of <path> .
+filecopy
+Recursively copies an existing file or subdirectory to a different
location within the branch. The existing file or directory must
exist. If the destination exists it will be completely replaced
-by the content copied from the source.
+by the content copied from the source.
'C' SP <path> SP <path> LF
-here the first <path> is the source location and the second
+
here the first <path> is the source location and the second
<path> is the destination. See filemodify above for a detailed
description of what <path> may look like. To use a source path
-that contains SP the path must be quoted.
-
A filecopy command takes effect immediately. Once the source
+that contains SP the path must be quoted.
+A filecopy command takes effect immediately. Once the source
location has been copied to the destination any future commands
applied to the source location will not impact the destination of
-the copy.
-
filerename
-
Renames an existing file or subdirectory to a different location
+the copy.
+filerename
+Renames an existing file or subdirectory to a different location
within the branch. The existing file or directory must exist. If
-the destination exists it will be replaced by the source directory.
+the destination exists it will be replaced by the source directory.
'R' SP <path> SP <path> LF
-here the first <path> is the source location and the second
+
here the first <path> is the source location and the second
<path> is the destination. See filemodify above for a detailed
description of what <path> may look like. To use a source path
-that contains SP the path must be quoted.
-
A filerename command takes effect immediately. Once the source
+that contains SP the path must be quoted.
+A filerename command takes effect immediately. Once the source
location has been renamed to the destination any future commands
applied to the source location will create new files there and not
-impact the destination of the rename.
-
Note that a filerename is the same as a filecopy followed by a
+impact the destination of the rename.
+Note that a filerename is the same as a filecopy followed by a
filedelete of the source location. There is a slight performance
advantage to using filerename , but the advantage is so small
that it is never worth trying to convert a delete/add pair in
source material into a rename for fast-import. This filerename
command is provided just to simplify frontends that already have
rename information and don't want bother with decomposing it into a
-filecopy followed by a filedelete .
-
filedeleteall
-
Included in a commit command to remove all files (and also all
+filecopy followed by a filedelete .
+filedeleteall
+Included in a commit command to remove all files (and also all
directories) from the branch. This command resets the internal
branch structure to have no files in it, allowing the frontend
-to subsequently add all interesting files from scratch.
+to subsequently add all interesting files from scratch.
-This command is extremely useful if the frontend does not know
+
This command is extremely useful if the frontend does not know
(or does not care to know) what files are currently on the branch,
and therefore cannot generate the proper filedelete commands to
-update the content.
-
Issuing a filedeleteall followed by the needed filemodify
+update the content.
+Issuing a filedeleteall followed by the needed filemodify
commands to set the correct content will produce the same results
as sending only the needed filemodify and filedelete commands.
The filedeleteall approach may however require fast-import to use slightly
more memory per active branch (less than 1 MiB for even most large
projects); so frontends that can easily obtain only the affected
-paths for a commit are encouraged to do so.
-
mark
-
Arranges for fast-import to save a reference to the current object, allowing
+paths for a commit are encouraged to do so.
+mark
+Arranges for fast-import to save a reference to the current object, allowing
the frontend to recall this object at a future point in time, without
knowing its SHA-1. Here the current object is the object creation
command the mark command appears within. This can be commit ,
-tag , and blob , but commit is the most common usage.
+
tag , and
blob , but
commit is the most common usage.
-where <idnum> is the number assigned by the frontend to this mark.
+
where <idnum> is the number assigned by the frontend to this mark.
The value of <idnum> is expressed as an ASCII decimal integer.
The value 0 is reserved and cannot be used as
-a mark. Only values greater than or equal to 1 may be used as marks.
-
New marks are created automatically. Existing marks can be moved
+a mark. Only values greater than or equal to 1 may be used as marks.
+New marks are created automatically. Existing marks can be moved
to another object simply by reusing the same <idnum> in another
-mark command.
-
tag
-
Creates an annotated tag referring to a specific commit. To create
-lightweight (non-annotated) tags see the reset command below.
+
mark command.
+tag
+Creates an annotated tag referring to a specific commit. To create
+lightweight (non-annotated) tags see the reset command below.
'tag' SP <name> LF
@@ -961,46 +1009,46 @@ lightweight (non-annotated) tags see the reset command below.
'tagger' SP <name> SP LT <email> GT SP <when> LF
data
-where <name> is the name of the tag to create.
-Tag names are automatically prefixed with refs/tags/ when stored
+
where <name> is the name of the tag to create.
+Tag names are automatically prefixed with refs/tags/ when stored
in Git, so importing the CVS branch symbol RELENG-1_0-FINAL would
use just RELENG-1_0-FINAL for <name> , and fast-import will write the
-corresponding ref as refs/tags/RELENG-1_0-FINAL .
-
The value of <name> must be a valid refname in Git and therefore
+corresponding ref as refs/tags/RELENG-1_0-FINAL .
+The value of <name> must be a valid refname in Git and therefore
may contain forward slashes. As LF is not valid in a Git refname,
-no quoting or escaping syntax is supported here.
-
The from command is the same as in the commit command; see
-above for details.
-
The tagger command uses the same format as committer within
-commit ; again see above for details.
-
The data command following tagger must supply the annotated tag
+no quoting or escaping syntax is supported here.
+The from command is the same as in the commit command; see
+above for details.
+The tagger command uses the same format as committer within
+commit ; again see above for details.
+The data command following tagger must supply the annotated tag
message (see below for data command syntax). To import an empty
tag message use a 0 length data. Tag messages are free-form and are
not interpreted by Git. Currently they must be encoded in UTF-8,
-as fast-import does not permit other encodings to be specified.
-
Signing annotated tags during import from within fast-import is not
+as fast-import does not permit other encodings to be specified.
+Signing annotated tags during import from within fast-import is not
supported. Trying to include your own PGP/GPG signature is not
recommended, as the frontend does not (easily) have access to the
complete set of bytes which normally goes into such a signature.
If signing is required, create lightweight tags from within fast-import with
reset , then create the annotated versions of those tags offline
-with the standard git-tag process.
-
reset
-
Creates (or recreates) the named branch, optionally starting from
+with the standard git-tag process.
+reset
+Creates (or recreates) the named branch, optionally starting from
a specific revision. The reset command allows a frontend to issue
a new from command for an existing branch, or to create a new
-branch from an existing commit without creating a new commit.
+branch from an existing commit without creating a new commit.
'reset' SP <ref> LF
('from' SP <committish> LF)?
LF?
-For a detailed description of <ref> and <committish> see above
-under commit and from .
-The LF after the command is optional (it used to be required).
-The reset command can also be used to create lightweight
-(non-annotated) tags. For example:
+For a detailed description of <ref> and <committish> see above
+under commit and from .
+The LF after the command is optional (it used to be required).
+The reset command can also be used to create lightweight
+(non-annotated) tags. For example:
@@ -1009,35 +1057,35 @@ under commit and from .
from :938
-would create the lightweight tag refs/tags/938 referring to
-whatever commit mark :938 references.
-blob
-Requests writing one file revision to the packfile. The revision
+
would create the lightweight tag refs/tags/938 referring to
+whatever commit mark :938 references.
+blob
+Requests writing one file revision to the packfile. The revision
is not connected to any commit; this connection must be formed in
a subsequent commit command by referencing the blob through an
-assigned mark.
+assigned mark.
-The mark command is optional here as some frontends have chosen
+
The mark command is optional here as some frontends have chosen
to generate the Git SHA-1 for the blob on their own, and feed that
directly to commit . This is typically more work than its worth
-however, as marks are inexpensive to store and easy to use.
-
data
-
Supplies raw data (for use as blob/file content, commit messages, or
+however, as marks are inexpensive to store and easy to use.
+data
+Supplies raw data (for use as blob/file content, commit messages, or
annotated tag messages) to fast-import. Data can be supplied using an exact
byte count or delimited with a terminating line. Real frontends
intended for production-quality conversions should always use the
exact byte count format, as it is more robust and performs better.
-The delimited format is intended primarily for testing fast-import.
-
Comment lines appearing within the <raw> part of data commands
+The delimited format is intended primarily for testing fast-import.
+Comment lines appearing within the <raw> part of data commands
are always taken to be part of the body of the data and are therefore
never ignored by fast-import. This makes it safe to import any
-file/message content whose lines might start with # .
-
+file/message content whose lines might start with # .
+
Exact byte count format
@@ -1050,14 +1098,14 @@ Exact byte count format
'data' SP <count> LF
<raw> LF?
-where <count> is the exact number of bytes appearing within
+
where <count> is the exact number of bytes appearing within
<raw> . The value of <count> is expressed as an ASCII decimal
integer. The LF on either side of <raw> is not
-included in <count> and will not be included in the imported data.
-
The LF after <raw> is optional (it used to be required) but
+included in <count> and will not be included in the imported data.
+The LF after <raw> is optional (it used to be required) but
recommended. Always including it makes debugging a fast-import
stream easier as the next command always starts in column 0
-of the next line, even if <raw> did not end with an LF .
+of the next line, even if
<raw> did not end with an
LF .
Delimited format
@@ -1076,51 +1124,51 @@ Delimited format
<delim> LF
LF?
-where <delim> is the chosen delimiter string. The string <delim>
+
where <delim> is the chosen delimiter string. The string <delim>
must not appear on a line by itself within <raw> , as otherwise
fast-import will think the data ends earlier than it really does. The LF
immediately trailing <raw> is part of <raw> . This is one of
the limitations of the delimited format, it is impossible to supply
-a data chunk which does not have an LF as its last byte.
-
The LF after <delim> LF is optional (it used to be required).
+a data chunk which does not have an LF as its last byte.
+The LF after <delim> LF is optional (it used to be required).
-
-checkpoint
-Forces fast-import to close the current packfile, start a new one, and to
-save out all current branch refs, tags and marks.
+
+checkpoint
+Forces fast-import to close the current packfile, start a new one, and to
+save out all current branch refs, tags and marks.
-Note that fast-import automatically switches packfiles when the current
+
Note that fast-import automatically switches packfiles when the current
packfile reaches --max-pack-size, or 4 GiB, whichever limit is
smaller. During an automatic packfile switch fast-import does not update
-the branch refs, tags or marks.
-
As a checkpoint can require a significant amount of CPU time and
+the branch refs, tags or marks.
+As a checkpoint can require a significant amount of CPU time and
disk IO (to compute the overall pack SHA-1 checksum, generate the
corresponding index file, and update the refs) it can easily take
-several minutes for a single checkpoint command to complete.
-
Frontends may choose to issue checkpoints during extremely large
+several minutes for a single checkpoint command to complete.
+Frontends may choose to issue checkpoints during extremely large
and long running imports, or when they need to allow another Git
process access to a branch. However given that a 30 GiB Subversion
repository can be loaded into Git through fast-import in about 3 hours,
-explicit checkpointing may not be necessary.
-
The LF after the command is optional (it used to be required).
-
progress
-
Causes fast-import to print the entire progress line unmodified to
+explicit checkpointing may not be necessary.
+The LF after the command is optional (it used to be required).
+progress
+Causes fast-import to print the entire progress line unmodified to
its standard output channel (file descriptor 1) when the command is
processed from the input stream. The command otherwise has no impact
-on the current import, or on any of fast-import's internal state.
+on the current import, or on any of fast-import's internal state.
'progress' SP <any> LF
LF?
-The <any> part of the command may contain any sequence of bytes
+
The <any> part of the command may contain any sequence of bytes
that does not contain LF . The LF after the command is optional.
Callers may wish to process the output through a tool such as sed to
-remove the leading part of the line, for example:
+remove the leading part of the line, for example:
@@ -1128,31 +1176,31 @@ remove the leading part of the line, for example:
frontend | git fast-import | sed 's/^progress //'
-Placing a progress command immediately after a checkpoint will
+
Placing a progress command immediately after a checkpoint will
inform the reader when the checkpoint has been completed and it
-can safely access the refs that fast-import updated.
+can safely access the refs that fast-import updated.
-Crash Reports
+Crash Reports
-
If fast-import is supplied invalid input it will terminate with a
+
If fast-import is supplied invalid input it will terminate with a
non-zero exit status and create a crash report in the top level of
the Git repository it was importing into. Crash reports contain
a snapshot of the internal fast-import state as well as the most
-recent commands that lead up to the crash.
-
All recent commands (including stream comments, file changes and
+recent commands that lead up to the crash.
+
All recent commands (including stream comments, file changes and
progress commands) are shown in the command history within the crash
report, but raw file data and commit messages are excluded from the
crash report. This exclusion saves space within the report file
and reduces the amount of buffering that fast-import must perform
-during execution.
-
After writing a crash report fast-import will close the current
+during execution.
+
After writing a crash report fast-import will close the current
packfile and export the marks table. This allows the frontend
developer to inspect the repository state and resume the import from
the point where it crashed. The modified branches and tags are not
updated during a crash, as the import did not complete successfully.
Branch and tag information can be found in the crash report and
-must be applied manually if the update is needed.
-
An example crash:
+must be applied manually if the update is needed.
+
@@ -1234,189 +1282,189 @@ END OF CRASH REPORT
-Tips and Tricks
+Tips and Tricks
-
The following tips and tricks have been collected from various
-users of fast-import, and are offered here as suggestions.
-
Use One Mark Per Commit
-
When doing a repository conversion, use a unique mark per commit
+
The following tips and tricks have been collected from various
+users of fast-import, and are offered here as suggestions.
+
Use One Mark Per Commit
+
When doing a repository conversion, use a unique mark per commit
(mark :<n> ) and supply the --export-marks option on the command
line. fast-import will dump a file which lists every mark and the Git
object SHA-1 that corresponds to it. If the frontend can tie
the marks back to the source repository, it is easy to verify the
accuracy and completeness of the import by comparing each Git
-commit to the corresponding source revision.
-
Coming from a system such as Perforce or Subversion this should be
+commit to the corresponding source revision.
+
Coming from a system such as Perforce or Subversion this should be
quite simple, as the fast-import mark can also be the Perforce changeset
-number or the Subversion revision number.
-
Freely Skip Around Branches
-
Don't bother trying to optimize the frontend to stick to one branch
+number or the Subversion revision number.
+
Freely Skip Around Branches
+
Don't bother trying to optimize the frontend to stick to one branch
at a time during an import. Although doing so might be slightly
faster for fast-import, it tends to increase the complexity of the frontend
-code considerably.
-
The branch LRU builtin to fast-import tends to behave very well, and the
+code considerably.
+
The branch LRU builtin to fast-import tends to behave very well, and the
cost of activating an inactive branch is so low that bouncing around
-between branches has virtually no impact on import performance.
-
Handling Renames
-
When importing a renamed file or directory, simply delete the old
+between branches has virtually no impact on import performance.
+
Handling Renames
+
When importing a renamed file or directory, simply delete the old
name(s) and modify the new name(s) during the corresponding commit.
Git performs rename detection after-the-fact, rather than explicitly
-during a commit.
-
Use Tag Fixup Branches
-
Some other SCM systems let the user create a tag from multiple
+during a commit.
+
Use Tag Fixup Branches
+
Some other SCM systems let the user create a tag from multiple
files which are not from the same commit/changeset. Or to create
-tags which are a subset of the files available in the repository.
-
Importing these tags as-is in Git is impossible without making at
+tags which are a subset of the files available in the repository.
+
Importing these tags as-is in Git is impossible without making at
least one commit which “fixes up” the files to match the content
of the tag. Use fast-import's reset command to reset a dummy branch
outside of your normal branch space to the base commit for the tag,
then commit one or more file fixup commits, and finally tag the
-dummy branch.
-
For example since all normal branches are stored under refs/heads/
+dummy branch.
+
For example since all normal branches are stored under refs/heads/
name the tag fixup branch TAG_FIXUP . This way it is impossible for
the fixup branch used by the importer to have namespace conflicts
with real branches imported from the source (the name TAG_FIXUP
-is not refs/heads/TAG_FIXUP ).
-
When committing fixups, consider using merge to connect the
+is not refs/heads/TAG_FIXUP ).
+
When committing fixups, consider using merge to connect the
commit(s) which are supplying file revisions to the fixup branch.
-Doing so will allow tools such as git-blame to track
+Doing so will allow tools such as git-blame to track
through the real commit history and properly annotate the source
-files.
-
After fast-import terminates the frontend will need to do rm .git/TAG_FIXUP
-to remove the dummy branch.
-
Import Now, Repack Later
-
As soon as fast-import completes the Git repository is completely valid
+files.
+
After fast-import terminates the frontend will need to do rm .git/TAG_FIXUP
+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. 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
+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
large projects (especially if -f and a large --window parameter is
used). Since repacking is safe to run alongside readers and writers,
run the repack in the background and let it finish when it finishes.
-There is no reason to wait to explore your new Git project!
-
If you choose to wait for the repack, don't try to run benchmarks
+There is no reason to wait to explore your new Git project!
+
If you choose to wait for the repack, don't try to run benchmarks
or performance tests until repacking is completed. fast-import outputs
suboptimal packfiles that are simply never seen in real use
-situations.
-
Repacking Historical Data
-
If you are repacking very old imported data (e.g. older than the
+situations.
+
Repacking Historical Data
+
If you are repacking very old imported data (e.g. older than the
last year), consider expending some extra CPU time and supplying
---window=50 (or higher) when you run git-repack .
+--window=50 (or higher) when you run git-repack .
This will take longer, but will also produce a smaller packfile.
You only need to expend the effort once, and everyone using your
-project will benefit from the smaller repository.
-
Include Some Progress Messages
-
Every once in a while have your frontend emit a progress message
+project will benefit from the smaller repository.
+
Include Some Progress Messages
+
Every once in a while have your frontend emit a progress message
to fast-import. The contents of the messages are entirely free-form,
so one suggestion would be to output the current month and year
each time the current commit date moves into the next month.
Your users will feel better knowing how much of the data stream
-has been processed.
+has been processed.
-Packfile Optimization
+Packfile Optimization
-
When packing a blob fast-import always attempts to deltify against the last
+
When packing a blob fast-import always attempts to deltify against the last
blob written. Unless specifically arranged for by the frontend,
this will probably not be a prior version of the same file, so the
generated delta will not be the smallest possible. The resulting
-packfile will be compressed, but will not be optimal.
-
Frontends which have efficient access to all revisions of a
+packfile will be compressed, but will not be optimal.
+
Frontends which have efficient access to all revisions of a
single file (for example reading an RCS/CVS ,v file) can choose
to supply all revisions of that file as a sequence of consecutive
blob commands. This allows fast-import to deltify the different file
revisions against each other, saving space in the final packfile.
Marks can be used to later identify individual file revisions during
-a sequence of commit commands.
-
The packfile(s) created by fast-import do not encourage good disk access
+a sequence of commit commands.
+
The packfile(s) created by fast-import do not encourage good disk access
patterns. This is caused by fast-import writing the data in the order
it is received on standard input, while Git typically organizes
data within packfiles to make the most recent (current tip) data
appear before historical data. Git also clusters commits together,
-speeding up revision traversal through better cache locality.
-
For this reason it is strongly recommended that users repack the
+speeding up revision traversal through better cache locality.
+
For this reason it is strongly recommended that users repack the
repository with git repack -a -d after fast-import completes, allowing
Git to reorganize the packfiles for faster data access. If blob
deltas are suboptimal (see above) then also adding the -f option
to force recomputation of all deltas can significantly reduce the
-final packfile size (30-50% smaller can be quite typical).
+final packfile size (30-50% smaller can be quite typical).
-Memory Utilization
+Memory Utilization
-
There are a number of factors which affect how much memory fast-import
+
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 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
+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
this execution. On a 32 bit system the structure is 32 bytes,
on a 64 bit system the structure is 40 bytes (due to the larger
pointer sizes). Objects in the table are not deallocated until
fast-import terminates. Importing 2 million objects on a 32 bit system
-will require approximately 64 MiB of memory.
-
The object table is actually a hashtable keyed on the object name
+will require approximately 64 MiB of memory.
+
The object table is actually a hashtable keyed on the object name
(the unique SHA-1). This storage configuration allows fast-import to reuse
an existing or already written object and avoid writing duplicates
to the output packfile. Duplicate blobs are surprisingly common
-in an import, typically due to branch merges in the source.
-
per mark
-
Marks are stored in a sparse array, using 1 pointer (4 bytes or 8
+in an import, typically due to branch merges in the source.
+
per mark
+
Marks are stored in a sparse array, using 1 pointer (4 bytes or 8
bytes, depending on pointer size) per mark. Although the array
is sparse, frontends are still strongly encouraged to use marks
between 1 and n, where n is the total number of marks required for
-this import.
-
per branch
-
Branches are classified as active and inactive. The memory usage
-of the two classes is significantly different.
-
Inactive branches are stored in a structure which uses 96 or 120
+this import.
+
per branch
+
Branches are classified as active and inactive. The memory usage
+of the two classes is significantly different.
+
Inactive branches are stored in a structure which uses 96 or 120
bytes (32 bit or 64 bit systems, respectively), plus the length of
the branch name (typically under 200 bytes), per branch. fast-import will
easily handle as many as 10,000 inactive branches in under 2 MiB
-of memory.
-
Active branches have the same overhead as inactive branches, but
+of memory.
+
Active branches have the same overhead as inactive branches, but
also contain copies of every tree that has been recently modified on
that branch. If subtree include has not been modified since the
branch became active, its contents will not be loaded into memory,
but if subtree src has been modified by a commit since the branch
-became active, then its contents will be loaded in memory.
-
As active branches store metadata about the files contained on that
+became active, then its contents will be loaded in memory.
+
As active branches store metadata about the files contained on that
branch, their in-memory storage size can grow to a considerable size
-(see below).
-
fast-import automatically moves active branches to inactive status based on
+(see below).
+
fast-import automatically moves active branches to inactive status based on
a simple least-recently-used algorithm. The LRU chain is updated on
each commit command. The maximum number of active branches can be
-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
+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 amortizes out
-over the individual file entries.
-
per active file entry
-
Files (and pointers to subtrees) within active trees require 52 or 64
+over the individual file entries.
+
per active file entry
+
Files (and pointers to subtrees) within active trees require 52 or 64
bytes (32/64 bit platforms) per entry. To conserve space, file and
tree names are pooled in a common string table, allowing the filename
“Makefile” to use just 16 bytes (after including the string header
-overhead) no matter how many times it occurs within the project.
-
The active branch LRU, when coupled with the filename string pool
+overhead) no matter how many times it occurs within the project.
+
The active branch LRU, when coupled with the filename string pool
and lazy loading of subtrees, allows fast-import to efficiently import
projects with 2,000+ branches and 45,114+ files in a very limited
-memory footprint (less than 2.7 MiB per active branch).
+memory footprint (less than 2.7 MiB per active branch).
-Author
+Author
-
Written by Shawn O. Pearce <spearce@spearce.org>.
+
Written by Shawn O. Pearce <spearce@spearce.org>.
-Documentation
+Documentation
-
Documentation by Shawn O. Pearce <spearce@spearce.org>.
+
Documentation by Shawn O. Pearce <spearce@spearce.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-fast-import.txt b/git-fast-import.txt
index 70cc8e831..2d01d0d10 100644
--- a/git-fast-import.txt
+++ b/git-fast-import.txt
@@ -15,7 +15,7 @@ DESCRIPTION
This program is usually not what the end user wants to run directly.
Most end users want to use one of the existing frontend programs,
which parses a specific type of foreign source and feeds the contents
-stored there to `git-fast-import`.
+stored there to 'git-fast-import'.
fast-import reads a mixed command/data stream from standard input and
writes one or more packfiles directly into the current repository.
@@ -24,7 +24,7 @@ updated branch and tag refs, fully updating the current repository
with the newly imported data.
The fast-import backend itself can import into an empty repository (one that
-has already been initialized by `git-init`) or incrementally
+has already been initialized by 'git-init') or incrementally
update an existing populated repository. Whether or not incremental
imports are supported from a particular foreign source depends on
the frontend program in use.
@@ -82,11 +82,11 @@ OPTIONS
This information may be useful after importing projects
whose total object set exceeds the 4 GiB packfile limit,
as these commits can be used as edge points during calls
- to `git-pack-objects`.
+ to 'git-pack-objects'.
--quiet::
Disable all non-fatal output, making fast-import silent when it
- is successful. This option disables the output shown by
+ is successful. This option disables the output shown by
\--stats.
--stats::
@@ -124,9 +124,9 @@ an ideal situation, given that most conversion tools are throw-away
Parallel Operation
------------------
-Like `git-push` or `git-fetch`, imports handled by fast-import are safe to
+Like 'git-push' or 'git-fetch', imports handled by fast-import are safe to
run alongside parallel `git repack -a -d` or `git gc` invocations,
-or any other Git operation (including `git-prune`, as loose objects
+or any other Git operation (including 'git-prune', as loose objects
are never used by fast-import).
fast-import does not lock the branch or tag refs it is actively importing.
@@ -220,7 +220,7 @@ variation in formatting will cause fast-import to reject the value.
+
An example value is ``Tue Feb 6 11:22:18 2007 -0500''. The Git
parser is accurate, but a little on the lenient side. It is the
-same parser used by `git-am` when applying patches
+same parser used by 'git-am' when applying patches
received from email.
+
Some malformed strings may be accepted as valid dates. In some of
@@ -256,7 +256,7 @@ timezone.
This particular format is supplied as its short to implement and
may be useful to a process that wants to create a new commit
right now, without needing to use a working directory or
-`git-update-index`.
+'git-update-index'.
+
If separate `author` and `committer` commands are used in a `commit`
the timestamps may not match, as the system clock will be polled
@@ -654,7 +654,7 @@ recommended, as the frontend does not (easily) have access to the
complete set of bytes which normally goes into such a signature.
If signing is required, create lightweight tags from within fast-import with
`reset`, then create the annotated versions of those tags offline
-with the standard `git-tag` process.
+with the standard 'git-tag' process.
`reset`
~~~~~~~
@@ -955,7 +955,7 @@ is not `refs/heads/TAG_FIXUP`).
When committing fixups, consider using `merge` to connect the
commit(s) which are supplying file revisions to the fixup branch.
-Doing so will allow tools such as `git-blame` to track
+Doing so will allow tools such as 'git-blame' to track
through the real commit history and properly annotate the source
files.
@@ -984,7 +984,7 @@ Repacking Historical Data
~~~~~~~~~~~~~~~~~~~~~~~~~
If you are repacking very old imported data (e.g. older than the
last year), consider expending some extra CPU time and supplying
-\--window=50 (or higher) when you run `git-repack`.
+\--window=50 (or higher) when you run 'git-repack'.
This will take longer, but will also produce a smaller packfile.
You only need to expend the effort once, and everyone using your
project will benefit from the smaller repository.
diff --git a/git-fetch-pack.html b/git-fetch-pack.html
index eaf2afc8c..fa2057c67 100644
--- a/git-fetch-pack.html
+++ b/git-fetch-pack.html
@@ -3,7 +3,7 @@
-
+
git-fetch-pack(1)
@@ -272,24 +320,24 @@ git-fetch-pack(1) Manual Page
SYNOPSIS
-
git fetch-pack [--all] [--quiet|-q] [--keep|-k] [--thin] [--include-tag] [--upload-pack=<git-upload-pack>] [--depth=<n>] [--no-progress] [-v] [<host>:]<directory> [<refs>…]
+
git fetch-pack [--all] [--quiet|-q] [--keep|-k] [--thin] [--include-tag] [--upload-pack=<git-upload-pack>] [--depth=<n>] [--no-progress] [-v] [<host>:]<directory> [<refs>…]
-DESCRIPTION
+DESCRIPTION
-
Usually you would want to use git-fetch , which is a
-higher level wrapper of this command, instead.
-
Invokes git-upload-pack on a possibly remote repository
+
Usually you would want to use git-fetch , which is a
+higher level wrapper of this command, instead.
+
Invokes git-upload-pack on a possibly remote repository
and asks it to send objects missing from this repository, to
update the named heads. The list of commits available locally
is found out by scanning local $GIT_DIR/refs/ and sent to
-git-upload-pack running on the other end.
-
This command degenerates to download everything to complete the
+git-upload-pack running on the other end.
+
This command degenerates to download everything to complete the
asked refs from the remote side when the local side does not
-have a common ancestor commit.
+have a common ancestor commit.
-OPTIONS
+OPTIONS
-
+
--all
@@ -306,7 +354,7 @@ have a common ancestor commit.
- Pass -q flag to git-unpack-objects ; this makes the
+ Pass -q flag to git-unpack-objects ; this makes the
cloning process less verbose.
@@ -318,7 +366,7 @@ have a common ancestor commit.
- Do not invoke git-unpack-objects on received data, but
+ Do not invoke git-unpack-objects on received data, but
create a single packfile out of it instead, and store it
in the object database. If provided twice then the pack is
locked against repacking.
@@ -349,7 +397,7 @@ have a common ancestor commit.
- Use this to specify the path to git-upload-pack on the
+ Use this to specify the path to git-upload-pack on the
remote side, if is not found on your $PATH.
Installations of sshd ignores the user's environment
setup scripts for login shells (e.g. .bash_profile) and
@@ -399,7 +447,7 @@ have a common ancestor commit.
A remote host that houses the repository. When this
- part is specified, git-upload-pack is invoked via
+ part is specified, git-upload-pack is invoked via
ssh.
@@ -421,23 +469,23 @@ have a common ancestor commit.
unspecified, update from all heads the remote side has.
-
+
-Author
+Author
-
Written by Linus Torvalds <torvalds@osdl.org>
+
Written by Linus Torvalds <torvalds@osdl.org>
-Documentation
+Documentation
-
Documentation by Junio C Hamano.
+
Documentation by Junio C Hamano.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-fetch-pack.txt b/git-fetch-pack.txt
index a069f8d9a..47448da22 100644
--- a/git-fetch-pack.txt
+++ b/git-fetch-pack.txt
@@ -12,14 +12,14 @@ SYNOPSIS
DESCRIPTION
-----------
-Usually you would want to use `git-fetch`, which is a
+Usually you would want to use 'git-fetch', which is a
higher level wrapper of this command, instead.
-Invokes `git-upload-pack` on a possibly remote repository
+Invokes 'git-upload-pack' on a possibly remote repository
and asks it to send objects missing from this repository, to
update the named heads. The list of commits available locally
is found out by scanning local $GIT_DIR/refs/ and sent to
-`git-upload-pack` running on the other end.
+'git-upload-pack' running on the other end.
This command degenerates to download everything to complete the
asked refs from the remote side when the local side does not
@@ -33,12 +33,12 @@ OPTIONS
-q::
--quiet::
- Pass '-q' flag to `git-unpack-objects`; this makes the
+ Pass '-q' flag to 'git-unpack-objects'; this makes the
cloning process less verbose.
-k::
--keep::
- Do not invoke `git-unpack-objects` on received data, but
+ Do not invoke 'git-unpack-objects' on received data, but
create a single packfile out of it instead, and store it
in the object database. If provided twice then the pack is
locked against repacking.
@@ -54,7 +54,7 @@ OPTIONS
otherwise determine the tags this option made available.
--upload-pack=::
- Use this to specify the path to `git-upload-pack` on the
+ Use this to specify the path to 'git-upload-pack' on the
remote side, if is not found on your $PATH.
Installations of sshd ignores the user's environment
setup scripts for login shells (e.g. .bash_profile) and
@@ -79,7 +79,7 @@ OPTIONS
::
A remote host that houses the repository. When this
- part is specified, `git-upload-pack` is invoked via
+ part is specified, 'git-upload-pack' is invoked via
ssh.
::
diff --git a/git-fetch.html b/git-fetch.html
index 2f4cf69ee..7f656d1f5 100644
--- a/git-fetch.html
+++ b/git-fetch.html
@@ -3,7 +3,7 @@
-
+
git-fetch(1)
@@ -272,26 +320,26 @@ git-fetch(1) Manual Page
SYNOPSIS
-
git fetch <options> <repository> <refspec>…
+
git fetch <options> <repository> <refspec>…
-DESCRIPTION
+DESCRIPTION
-
Fetches named heads or tags from another repository, along with
-the objects necessary to complete them.
-
The ref names and their object names of fetched refs are stored
+
Fetches named heads or tags from another repository, along with
+the objects necessary to complete them.
+
The ref names and their object names of fetched refs are stored
in .git/FETCH_HEAD . This information is left for a later merge
-operation done by git-merge .
-
When <refspec> stores the fetched result in tracking branches,
+operation done by git-merge .
+
When <refspec> stores the fetched result in tracking branches,
the tags that point at these branches are automatically
followed. This is done by first fetching from the remote using
the given <refspec>s, and if the repository has objects that are
pointed by remote tags that it does not yet have, then fetch
those missing tags. If the other end has tags that point at
-branches you are not interested in, you will not get them.
+branches you are not interested in, you will not get them.
-OPTIONS
+OPTIONS
-
+
-q
@@ -347,7 +395,7 @@ branches you are not interested in, you will not get them.
- When git-fetch is used with <rbranch>:<lbranch>
+ When git-fetch is used with <rbranch>:<lbranch>
refspec, it refuses to update the local branch
<lbranch> unless the remote branch <rbranch> it
fetches is a descendant of <lbranch> . This option
@@ -402,10 +450,10 @@ branches you are not interested in, you will not get them.
- By default git-fetch refuses to update the head which
+ By default git-fetch refuses to update the head which
corresponds to the current branch. This flag disables the
- check. This is purely for the internal use for git-pull
- to communicate with git-fetch , and unless you are
+ check. This is purely for the internal use for git-pull
+ to communicate with git-fetch , and unless you are
implementing your own Porcelain you are not supposed to
use it.
@@ -437,16 +485,16 @@ 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.
-The remote ref that matches <src>
+
The remote ref that matches <src>
is fetched, and if <dst> is not empty string, the local
ref that matches it is fast forwarded using <src>.
Again, if the optional plus + is used, the local ref
is updated even if it does not result in a fast forward
-update.
+update.
@@ -471,7 +519,7 @@ must know this is the expected usage pattern for a branch.
You never do your own development on branches that appear
on the right hand side of a <refspec> colon on Pull: lines;
-they are to be updated by git-fetch . If you intend to do
+they are to be updated by git-fetch . If you intend to do
development derived from a remote branch B , have a Pull:
line to track it (i.e. Pull: B:remote-B ), and have a separate
branch my-B to do your development on top of it. The latter
@@ -488,13 +536,13 @@ on the remote branch, merge it into your development branch with
Note
There is a difference between listing multiple <refspec>
-directly on git-pull command line and having multiple
+directly on git-pull command line and having multiple
Pull: <refspec> lines for a <repository> and running
-git-pull command without any explicit <refspec> parameters.
+git-pull command without any explicit <refspec> parameters.
<refspec> listed explicitly on the command line are always
merged into the current branch after fetching. In other words,
if you list more than one remote refs, you would be making
-an Octopus. While git-pull run without any explicit <refspec>
+an Octopus. While git-pull run without any explicit <refspec>
parameter takes default <refspec>s from Pull: lines, it
merges only the first <refspec> found into the current branch,
after fetching all the remote refs. This is because making an
@@ -503,8 +551,8 @@ of multiple remote heads in one-go by fetching more than one
is often useful.
-Some short-cut notations are also supported.
-
-
+
-GIT URLS
+GIT URLS
-
One of the following notations can be used
-to name the remote repository:
+
One of the following notations can be used
+to name the remote repository:
-
SSH is the default transport protocol over the network. You can
+
SSH is the default transport protocol over the network. You can
optionally specify which user to log-in as, and an alternate,
scp-like syntax is also supported. Both syntaxes support
username expansion, as does the native git protocol, but
only the former supports port specification. The following
-three are identical to the last three above, respectively:
+three are identical to the last three above, respectively:
-
+
[user@]host.xz:/path/to/repo.git/
@@ -600,12 +648,12 @@ three are identical to the last three above, respectively:
[user@]host.xz:path/to/repo.git
-
+
-
To sync with a local directory, you can use:
+
To sync with a local directory, you can use:
-
They are mostly equivalent, except when cloning. See
-git-clone(1) for details.
-
If there are a large number of similarly-named remote repositories and
+
They are mostly equivalent, except when cloning. See
+git-clone(1) for details.
+
If there are a large number of similarly-named remote repositories and
you want to use a different format for them (such that the URLs you
use will be rewritten into URLs that work), you can create a
-configuration section of the form:
+configuration section of the form:
[url "<actual url base>"]
insteadOf = <other url base>
-
For example, with this:
+
[url "git://git.host.xz/"]
insteadOf = host.xz:/path/to/
insteadOf = work:
-
a URL like "work:repo.git" or like "host.xz:/path/to/repo.git" will be
-rewritten in any context that takes a URL to be "git://git.host.xz/repo.git".
+
a URL like "work:repo.git" or like "host.xz:/path/to/repo.git" will be
+rewritten in any context that takes a URL to be "git://git.host.xz/repo.git".
-REMOTES
+REMOTES
-
The name of one of the following can be used instead
-of a URL as <repository> argument:
-
+The name of one of the following can be used instead
+of a URL as <repository> argument:
+
a remote in the git configuration file: $GIT_DIR/config ,
@@ -659,17 +707,17 @@ a file in the $GIT_DIR/remotes directory, or
a file in the $GIT_DIR/branches directory.
-
-
All of these also allow you to omit the refspec from the command line
-because they each contain a refspec which git will use by default.
-
Named remote in configuration file
-
You can choose to provide the name of a remote which you had previously
+
+All of these also allow you to omit the refspec from the command line
+because they each contain a refspec which git will use by default.
+Named remote in configuration file
+You can choose to provide the name of a remote which you had previously
configured using git-remote(1) , git-config(1)
or even by a manual edit to the $GIT_DIR/config file. The URL of
this remote will be used to access the repository. The refspec
of this remote will be used by default when you do
not provide a refspec on the command line. The entry in the
-config file would appear like this:
+config file would appear like this:
[remote "<name>"]
@@ -677,13 +725,13 @@ config file would appear like this:
push = <refspec>
fetch = <refspec>
-Named file in $GIT_DIR/remotes
-You can choose to provide the name of a
+
Named file in $GIT_DIR/remotes
+You can choose to provide the name of a
file in $GIT_DIR/remotes . The URL
in this file will be used to access the repository. The refspec
in this file will be used as default when you do not
provide a refspec on the command line. This file should have the
-following format:
+following format:
URL: one of the above URL format
@@ -691,49 +739,49 @@ following format:
Pull: <refspec>
-Push: lines are used by git-push and
-Pull: lines are used by git-pull and git-fetch .
+
Push: lines are used by git-push and
+Pull: lines are used by git-pull and git-fetch .
Multiple Push: and Pull: lines may
-be specified for additional branch mappings.
-
Named file in $GIT_DIR/branches
-
You can choose to provide the name of a
+be specified for additional branch mappings.
+Named file in $GIT_DIR/branches
+You can choose to provide the name of a
file in $GIT_DIR/branches .
The URL in this file will be used to access the repository.
-This file should have the following format:
+This file should have the following format:
-<url> is required; #<head> is optional.
+
<url> is required; #<head> is optional.
When you do not provide a refspec on the command line,
git will use the following refspec, where <head> defaults to master ,
and <repository> is the name of this file
-you provided in the command line.
+you provided in the command line.
refs/heads/<head>:<repository>
-SEE ALSO
+SEE ALSO
-Author
+Author
-
Written by Linus Torvalds <torvalds@osdl.org> and
-Junio C Hamano <junkio@cox.net>
+
Written by Linus Torvalds <torvalds@osdl.org> and
+Junio C Hamano <junkio@cox.net>
-Documentation
+Documentation
-
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-fetch.txt b/git-fetch.txt
index b22556641..9e048a8a2 100644
--- a/git-fetch.txt
+++ b/git-fetch.txt
@@ -18,7 +18,7 @@ the objects necessary to complete them.
The ref names and their object names of fetched refs are stored
in `.git/FETCH_HEAD`. This information is left for a later merge
-operation done by `git-merge`.
+operation done by 'git-merge'.
When stores the fetched result in tracking branches,
the tags that point at these branches are automatically
diff --git a/git-filter-branch.html b/git-filter-branch.html
index 7cb33fa67..9e255390c 100644
--- a/git-filter-branch.html
+++ b/git-filter-branch.html
@@ -3,7 +3,7 @@
-
+
git-filter-branch(1)
@@ -280,34 +328,34 @@ git-filter-branch(1) Manual Page
[--original <namespace>] [-d <directory>] [-f | --force]
[<rev-list options>…]
-DESCRIPTION
+DESCRIPTION
-
Lets you rewrite git revision history by rewriting the branches mentioned
+
Lets you rewrite git revision history by rewriting the branches mentioned
in the <rev-list options>, applying custom filters on each revision.
Those filters can modify each tree (e.g. removing a file or running
a perl rewrite on all files) or information about each commit.
Otherwise, all information (including original commit times or merge
-information) will be preserved.
-
The command will only rewrite the _positive_ refs mentioned in the
+information) will be preserved.
+
The command will only rewrite the positive refs mentioned in the
command line (e.g. if you pass a..b , only b will be rewritten).
If you specify no filters, the commits will be recommitted without any
changes, which would normally have no effect. Nevertheless, this may be
useful in the future for compensating for some git bugs or such,
-therefore such a usage is permitted.
-
WARNING ! The rewritten history will have different object names for all
+therefore such a usage is permitted.
+
WARNING ! The rewritten history will have different object names for all
the objects and will not converge with the original branch. You will not
be able to easily push and distribute the rewritten branch on top of the
original branch. Please do not use this command if you do not know the
full implications, and avoid using it anyway, if a simple single commit
-would suffice to fix your problem.
-
Always verify that the rewritten version is correct: The original refs,
+would suffice to fix your problem.
+
Always verify that the rewritten version is correct: The original refs,
if different from the rewritten ones, will be stored in the namespace
-refs/original/ .
-
Note that since this operation is very I/O expensive, it might
+refs/original/ .
+
Note that since this operation is very I/O expensive, it might
be a good idea to redirect the temporary directory off-disk with the
--d option, e.g. on tmpfs. Reportedly the speedup is very noticeable.
-
Filters
-
The filters are applied in the order as listed below. The <command>
+-d option, e.g. on tmpfs. Reportedly the speedup is very noticeable.
+
Filters
+
The filters are applied in the order as listed below. The <command>
argument is always evaluated in the shell context using the eval command
(with the notable exception of the commit filter, for technical reasons).
Prior to that, the $GIT_COMMIT environment variable will be set to contain
@@ -316,16 +364,16 @@ GIT_AUTHOR_EMAIL, GIT_AUTHOR_DATE, GIT_COMMITTER_NAME, GIT_COMMITTER_EMAIL,
and GIT_COMMITTER_DATE are set according to the current commit. The values
of these variables after the filters have run, are used for the new commit.
If any evaluation of <command> returns a non-zero exit status, the whole
-operation will be aborted.
-
A map function is available that takes an "original sha1 id" argument
+operation will be aborted.
+
A map function is available that takes an "original sha1 id" argument
and outputs a "rewritten sha1 id" if the commit has been already
rewritten, and "original sha1 id" otherwise; the map function can
return several ids on separate lines if your commit filter emitted
-multiple commits.
+multiple commits.
-OPTIONS
+OPTIONS
-
+
--env-filter <command>
@@ -392,17 +440,17 @@ multiple commits.
This is the filter for performing the commit.
If this filter is specified, it will be called instead of the
- git-commit-tree command, with arguments of the form
+ git-commit-tree command, with arguments of the form
"<TREE_ID> [-p <PARENT_COMMIT_ID>]…" and the log message on
stdin. The commit id is expected on stdout.
-As a special extension, the commit filter may emit multiple
+
As a special extension, the commit filter may emit multiple
commit ids; in that case, the rewritten children of the original commit will
-have all of them as parents.
-
You can use the map convenience function in this filter, and other
+have all of them as parents.
+You can use the map convenience function in this filter, and other
convenience functions, too. For example, calling skip_commit "$@"
will leave out the current commit (but not its changes! If you want
-that, use git-rebase instead).
+that, use
git-rebase instead).
--tag-name-filter <command>
@@ -415,11 +463,11 @@ that, use git-rebase instead).
The original tag name is passed via standard input, and the new
tag name is expected on standard output.
-The original tags are not deleted, but can be overwritten;
+
The original tags are not deleted, but can be overwritten;
use "--tag-name-filter cat" to simply update the tags. In this
case, be very careful and make sure you have the old tags
-backed up in case the conversion has run afoul.
-
Nearly proper rewriting of tag objects is supported. If the tag has
+backed up in case the conversion has run afoul.
+Nearly proper rewriting of tag objects is supported. If the tag has
a message attached, a new tag object will be created with the same message,
author, and timestamp. If the tag has a signature attached, the
signature will be stripped. It is by definition impossible to preserve
@@ -428,7 +476,7 @@ the tag did not change (points to the same object, has the same name, etc.)
it should retain any signature. That is not the case, signatures will always
be removed, buyer beware. There is also no support for changing the
author or timestamp (or the tag message for that matter). Tags which point
-to other tags will be rewritten to point to the underlying commit.
+to other tags will be rewritten to point to the underlying commit.
--subdirectory-filter <directory>
@@ -470,7 +518,7 @@ to other tags will be rewritten to point to the underlying commit.
- git filter-branch refuses to start with an existing temporary
+ git-filter-branch refuses to start with an existing temporary
directory or when there are already refs starting with
refs/original/ , unless forced.
@@ -481,53 +529,53 @@ 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
+ 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.
-
+
-Examples
+Examples
-
Suppose you want to remove a file (containing confidential information
-or copyright violation) from all commits:
+
Suppose you want to remove a file (containing confidential information
+or copyright violation) from all commits:
git filter-branch --tree-filter 'rm filename' HEAD
-
However, if the file is absent from the tree of some commit,
+
However, if the file is absent from the tree of some commit,
a simple rm filename will fail for that tree and commit.
-Thus you may instead want to use rm -f filename as the script.
-
A significantly faster version:
+Thus you may instead want to use
rm -f filename as the script.
+
A significantly faster version:
git filter-branch --index-filter 'git update-index --remove filename' HEAD
-
Now, you will get the rewritten history saved in HEAD.
-
To set a commit (which typically is at the tip of another
+
Now, you will get the rewritten history saved in HEAD.
+
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:
+order to paste the other history behind the current history:
git filter-branch --parent-filter 'sed "s/^\$/-p <graft-id>/"' HEAD
-
(if the parent string is empty - which happens when we are dealing with
+
(if the parent string is empty - which happens when we are dealing with
the initial commit - add graftcommit as a parent). Note that this assumes
history with a single root (that is, no merge without common ancestors
-happened). If this is not the case, use:
+happened). If this is not the case, use:
git filter-branch --parent-filter \
'test $GIT_COMMIT = <commit-id> && echo "-p <graft-id>" || cat' HEAD
-
or even simpler:
+
echo "$commit-id $graft-id" >> .git/info/grafts
git filter-branch $graft-id..HEAD
-
To remove commits authored by "Darl McBribe" from the history:
+
To remove commits authored by "Darl McBribe" from the history:
git filter-branch --commit-filter '
@@ -538,7 +586,7 @@ git filter-branch $graft-id..HEAD
git commit-tree "$@";
fi' HEAD
-
The function skip_commit is defined as follows:
+
The function skip_commit is defined as follows:
skip_commit()
@@ -552,47 +600,47 @@ git filter-branch $graft-id..HEAD
done;
}
-
The shift magic first throws away the tree id and then the -p
+
The shift magic first throws away the tree id and then the -p
parameters. Note that this handles merges properly! In case Darl
committed a merge between P1 and P2, it will be propagated properly
and all children of the merge will become merge commits with P1,P2
-as their parents instead of the merge commit.
-
You can rewrite the commit log messages using --msg-filter . For
-example, git-svn-id strings in a repository created by git-svn can
-be removed this way:
+as their parents instead of the merge commit.
+
You can rewrite the commit log messages using --msg-filter . For
+example, git-svn-id strings in a repository created by git-svn can
+be removed this way:
git filter-branch --msg-filter '
sed -e "/^git-svn-id:/d"
'
-
To restrict rewriting to only part of the history, specify a revision
+
To restrict rewriting to only part of the history, specify a revision
range in addition to the new branch name. The new branch name will
-point to the top-most revision that a git-rev-list of this range
-will print.
-
NOTE the changes introduced by the commits, and which are not reverted
+point to the top-most revision that a git-rev-list of this range
+will print.
+
NOTE the changes introduced by the commits, and which are not reverted
by subsequent commits, will still be in the rewritten branch. If you want
-to throw out _changes_ together with the commits, you should use the
-interactive mode of git-rebase .
-
Consider this history:
+to throw out
changes together with the commits, you should use the
+interactive mode of
git-rebase .
+
D--E--F--G--H
/ /
A--B-----C
-
To rewrite only commits D,E,F,G,H, but leave A, B and C alone, use:
+
To rewrite only commits D,E,F,G,H, but leave A, B and C alone, use:
git filter-branch ... C..H
-
To rewrite commits E,F,G,H, use one of these:
+
To rewrite commits E,F,G,H, use one of these:
git filter-branch ... C..H --not D
git filter-branch ... D..H --not C
-
To move the whole tree into a subdirectory, or remove it from there:
+
To move the whole tree into a subdirectory, or remove it from there:
git filter-branch --index-filter \
@@ -602,22 +650,22 @@ git filter-branch ... D..H --not C
mv $GIT_INDEX_FILE.new $GIT_INDEX_FILE' HEAD
-Author
+Author
-
Written by Petr "Pasky" Baudis <pasky@suse.cz>,
-and the git list <git@vger.kernel.org>
+
Written by Petr "Pasky" Baudis <pasky@suse.cz>,
+and the git list <git@vger.kernel.org>
-Documentation
+Documentation
-
Documentation by Petr Baudis and the git list.
+
Documentation by Petr Baudis and the git list.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-filter-branch.txt b/git-filter-branch.txt
index a9388e0e2..a3edc0024 100644
--- a/git-filter-branch.txt
+++ b/git-filter-branch.txt
@@ -108,7 +108,7 @@ OPTIONS
--commit-filter ::
This is the filter for performing the commit.
If this filter is specified, it will be called instead of the
- `git-commit-tree` command, with arguments of the form
+ 'git-commit-tree' command, with arguments of the form
" [-p ]..." and the log message on
stdin. The commit id is expected on stdout.
+
@@ -119,7 +119,7 @@ have all of them as parents.
You can use the 'map' convenience function in this filter, and other
convenience functions, too. For example, calling 'skip_commit "$@"'
will leave out the current commit (but not its changes! If you want
-that, use `git-rebase` instead).
+that, use 'git-rebase' instead).
--tag-name-filter ::
This is the filter for rewriting tag names. When passed,
@@ -163,13 +163,13 @@ to other tags will be rewritten to point to the underlying commit.
-f::
--force::
- `git filter-branch` refuses to start with an existing temporary
+ 'git-filter-branch' refuses to start with an existing temporary
directory or when there are already refs starting with
'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
+ 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.
@@ -255,7 +255,7 @@ and all children of the merge will become merge commits with P1,P2
as their parents instead of the merge commit.
You can rewrite the commit log messages using `--msg-filter`. For
-example, `git-svn-id` strings in a repository created by `git-svn` can
+example, 'git-svn-id' strings in a repository created by 'git-svn' can
be removed this way:
-------------------------------------------------------
@@ -266,13 +266,13 @@ git filter-branch --msg-filter '
To restrict rewriting to only part of the history, specify a revision
range in addition to the new branch name. The new branch name will
-point to the top-most revision that a `git-rev-list` of this range
+point to the top-most revision that a 'git-rev-list' of this range
will print.
*NOTE* the changes introduced by the commits, and which are not reverted
by subsequent commits, will still be in the rewritten branch. If you want
to throw out _changes_ together with the commits, you should use the
-interactive mode of `git-rebase`.
+interactive mode of 'git-rebase'.
Consider this history:
diff --git a/git-fmt-merge-msg.html b/git-fmt-merge-msg.html
index a9f27032c..3e1905a91 100644
--- a/git-fmt-merge-msg.html
+++ b/git-fmt-merge-msg.html
@@ -3,7 +3,7 @@
-
+
git-fmt-merge-msg(1)
@@ -276,17 +324,17 @@ git-fmt-merge-msg(1) Manual Page
git fmt-merge-msg [--log | --no-log] <$GIT_DIR/FETCH_HEAD
git fmt-merge-msg [--log | --no-log] -F <file>
-DESCRIPTION
+DESCRIPTION
-
Takes the list of merged objects on stdin and produces a suitable
+
Takes the list of merged objects on stdin and produces a suitable
commit message to be used for the merge commit, usually to be
-passed as the <merge-message> argument of git-merge .
-
This script is intended mostly for internal use by scripts
-automatically invoking git-merge .
+passed as the
<merge-message> argument of
git-merge .
+
This script is intended mostly for internal use by scripts
+automatically invoking git-merge .
-OPTIONS
+OPTIONS
-
+
--log
@@ -330,11 +378,11 @@ automatically invoking git-merge .
stdin.
-
+
-CONFIGURATION
+CONFIGURATION
-
+
merge.log
@@ -353,27 +401,27 @@ merge.summary
the future.
-
+
-SEE ALSO
+SEE ALSO
-Author
+Author
-
Written by Junio C Hamano <junkio@cox.net>
+
Written by Junio C Hamano <junkio@cox.net>
-Documentation
+Documentation
-
Documentation by Petr Baudis, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
Documentation by Petr Baudis, Junio C Hamano and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-fmt-merge-msg.txt b/git-fmt-merge-msg.txt
index ddb89f8d6..885edf005 100644
--- a/git-fmt-merge-msg.txt
+++ b/git-fmt-merge-msg.txt
@@ -16,10 +16,10 @@ DESCRIPTION
-----------
Takes the list of merged objects on stdin and produces a suitable
commit message to be used for the merge commit, usually to be
-passed as the '' argument of `git-merge`.
+passed as the '' argument of 'git-merge'.
This script is intended mostly for internal use by scripts
-automatically invoking `git-merge`.
+automatically invoking 'git-merge'.
OPTIONS
-------
diff --git a/git-for-each-ref.html b/git-for-each-ref.html
index 4b0a174b7..1d6986992 100644
--- a/git-for-each-ref.html
+++ b/git-for-each-ref.html
@@ -3,7 +3,7 @@
-
+
git-for-each-ref(1)
@@ -276,18 +324,18 @@ git-for-each-ref(1) Manual Page
git for-each-ref [--count=<count>] [--shell|--perl|--python|--tcl]
[--sort=<key>]* [--format=<format>] [<pattern>…]
-DESCRIPTION
+DESCRIPTION
-
Iterate over all refs that match <pattern> and show them
+
Iterate over all refs that match <pattern> and show them
according to the given <format> , after sorting them according
to the given set of <key> . If <max> is given, stop after
showing that many refs. The interpolated values in <format>
can optionally be quoted as string literals in the specified
-host language allowing their direct evaluation in that language.
+host language allowing their direct evaluation in that language.
-OPTIONS
+OPTIONS
-
+
<count>
@@ -358,15 +406,15 @@ host language allowing their direct evaluation in that language.
a scriptlet that can directly be `eval`ed.
-
+
-FIELD NAMES
+FIELD NAMES
-
Various values from structured fields in referenced objects can
+
Various values from structured fields in referenced objects can
be used to interpolate into the resulting output, or as sort
-keys.
-
For all objects, the following names can be used:
-
+keys.
+
For all objects, the following names can be used:
+
refname
@@ -388,7 +436,7 @@ objectsize
- The size of the object (the same as git-cat-file -s reports).
+ The size of the object (the same as git-cat-file -s reports).
@@ -399,31 +447,31 @@ objectname
The object name (aka SHA-1).
-
-
In addition to the above, for commit and tag objects, the header
+
+
In addition to the above, for commit and tag objects, the header
field names (tree , parent , object , type , and tag ) can
-be used to specify the value in the header field.
-
Fields that have name-email-date tuple as its value (author ,
+be used to specify the value in the header field.
+
Fields that have name-email-date tuple as its value (author ,
committer , and tagger ) can be suffixed with name , email ,
-and date to extract the named component.
-
The first line of the message in a commit and tag object is
+and date to extract the named component.
+
The first line of the message in a commit and tag object is
subject , the remaining lines are body . The whole message
-is contents .
-
For sorting purposes, fields with numeric values sort in numeric
+is contents .
+
For sorting purposes, fields with numeric values sort in numeric
order (objectsize , authordate , committerdate , taggerdate ).
-All other fields are used to sort in their byte-value order.
-
In any case, a field name that refers to a field inapplicable to
+All other fields are used to sort in their byte-value order.
+
In any case, a field name that refers to a field inapplicable to
the object referred by the ref does not cause an error. It
-returns an empty string instead.
-
As a special case for the date-type fields, you may specify a format for
+returns an empty string instead.
+
As a special case for the date-type fields, you may specify a format for
the date by adding one of :default , :relative , :short , :local ,
:iso8601 or :rfc2822 to the end of the fieldname; e.g.
-%(taggerdate:relative) .
+
%(taggerdate:relative) .
-EXAMPLES
+EXAMPLES
-
An example directly producing formatted text. Show the most recent
-3 tagged commits::
+
An example directly producing formatted text. Show the most recent
+3 tagged commits::
#!/bin/sh
@@ -437,8 +485,8 @@ Ref: %(*refname)
%(*body)
' 'refs/tags'
-
A simple example showing the use of shell eval on the output,
-demonstrating the use of --shell. List the prefixes of all heads::
+
A simple example showing the use of shell eval on the output,
+demonstrating the use of --shell. List the prefixes of all heads::
#!/bin/sh
@@ -450,8 +498,8 @@ do
echo `dirname $ref`
done
-
A bit more elaborate report on tags, demonstrating that the format
-may be an entire script::
+
A bit more elaborate report on tags, demonstrating that the format
+may be an entire script::
#!/bin/sh
@@ -505,7 +553,7 @@ eval "$eval"
diff --git a/git-for-each-ref.txt b/git-for-each-ref.txt
index 29c29f883..727d84e67 100644
--- a/git-for-each-ref.txt
+++ b/git-for-each-ref.txt
@@ -79,7 +79,7 @@ objecttype::
The type of the object (`blob`, `tree`, `commit`, `tag`).
objectsize::
- The size of the object (the same as `git-cat-file -s` reports).
+ The size of the object (the same as 'git-cat-file -s' reports).
objectname::
The object name (aka SHA-1).
diff --git a/git-format-patch.html b/git-format-patch.html
index b4131ca91..cabd928c4 100644
--- a/git-format-patch.html
+++ b/git-format-patch.html
@@ -3,7 +3,7 @@
-
+
git-format-patch(1)
@@ -285,14 +333,14 @@ git-format-patch(1) Manual Page
[--cover-letter]
[ <since> | <revision range> ]
-DESCRIPTION
+DESCRIPTION
-
Prepare each commit with its patch in
+
Prepare each commit with its patch in
one file per commit, formatted to resemble UNIX mailbox format.
The output of this command is convenient for e-mail submission or
-for use with git-am .
-
There are two ways to specify which commits to operate on.
-
+for use with git-am .
+
There are two ways to specify which commits to operate on.
+
A single commit, <since>, specifies that the commits leading
@@ -307,33 +355,33 @@ Generic <revision range> expression (see "SPECIFYING
commits in the specified range.
-
-
A single commit, when interpreted as a <revision range>
+
+
A single commit, when interpreted as a <revision range>
expression, means "everything that leads to that commit", but
if you write git format-patch <commit> , the previous rule
applies to that command line and you do not get "everything
since the beginning of the time". If you want to format
everything since project inception to one commit, say "git
format-patch --root <commit>" to make it clear that it is the
-latter case.
-
By default, each output file is numbered sequentially from 1, and uses the
+latter case.
+
By default, each output file is numbered sequentially from 1, and uses the
first line of the commit message (massaged for pathname safety) as
the filename. With the --numbered-files option, the output file names
will only be numbers, without the first line of the commit appended.
The names of the output files are printed to standard
-output, unless the --stdout option is specified.
-
If -o is specified, output files are created in <dir>. Otherwise
-they are created in the current working directory.
-
If -n is specified, instead of "[PATCH] Subject", the first line
-is formatted as "[PATCH n/m] Subject".
-
If given --thread, git-format-patch will generate In-Reply-To and
+output, unless the --stdout option is specified.
+
If -o is specified, output files are created in <dir>. Otherwise
+they are created in the current working directory.
+
If -n is specified, instead of "[PATCH] Subject", the first line
+is formatted as "[PATCH n/m] Subject".
+
If given --thread, git-format-patch will generate In-Reply-To and
References headers to make the second and subsequent patch mails appear
as replies to the first mail; this also generates a Message-Id header to
-reference.
+reference.
-OPTIONS
+OPTIONS
-
+
-p
@@ -804,10 +852,10 @@ reference.
Do not show any source or destination prefix.
-
-
For more detailed explanation on these common options, see also
-gitdiffcore(7) .
-
+
+For more detailed explanation on these common options, see also
+gitdiffcore(7) .
+
-<n>
@@ -992,10 +1040,10 @@ reference.
filenames, use specified suffix. A common alternative is
--suffix=.txt .
-Note that you would need to include the leading dot . if you
+
Note that you would need to include the leading dot . if you
want a filename like 0001-description-of-my-change.patch , and
the first letter does not have to be a dot. Leaving it empty would
-not add any suffix.
+not add any suffix.
--no-binary
@@ -1008,13 +1056,13 @@ not add any suffix.
encoded in the patch.
-
+
-CONFIGURATION
+CONFIGURATION
-
You can specify extra mail header lines to be added to each message
+
You can specify extra mail header lines to be added to each message
in the repository configuration, new defaults for the subject prefix
-and file suffix, and number patches when outputting more than one.
+and file suffix, and number patches when outputting more than one.
[format]
@@ -1025,17 +1073,17 @@ and file suffix, and number patches when outputting more than one.
cc = <email>
-EXAMPLES
+EXAMPLES
-
+
-For each commit a separate file is created in the current directory.
+For each commit a separate file is created in the current directory.
@@ -1056,7 +1104,7 @@ project:
-
$ git format-patch \--root origin
+
$ git format-patch --root origin
@@ -1067,11 +1115,11 @@ The same as the previous one:
$ git format-patch -M -B origin
-Additionally, it detects and handles renames and complete rewrites
+
Additionally, it detects and handles renames and complete rewrites
intelligently to produce a renaming patch. A renaming patch reduces
the amount of text output, and generally makes it easier to review it.
Note that the "patch" program does not understand renaming patches, so
-use it only when you know the recipient uses git to apply your patch.
+use it only when you know the recipient uses git to apply your patch.
@@ -1083,27 +1131,27 @@ as e-mailable patches:
$ git format-patch -3
-
+
-SEE ALSO
+SEE ALSO
-Author
+Author
-
Written by Junio C Hamano <junkio@cox.net>
+
Written by Junio C Hamano <junkio@cox.net>
-Documentation
+Documentation
-
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-format-patch.txt b/git-format-patch.txt
index 894b82d6b..7c2ff3eb2 100644
--- a/git-format-patch.txt
+++ b/git-format-patch.txt
@@ -27,7 +27,7 @@ DESCRIPTION
Prepare each commit with its patch in
one file per commit, formatted to resemble UNIX mailbox format.
The output of this command is convenient for e-mail submission or
-for use with `git-am`.
+for use with 'git-am'.
There are two ways to specify which commits to operate on.
@@ -61,7 +61,7 @@ they are created in the current working directory.
If -n is specified, instead of "[PATCH] Subject", the first line
is formatted as "[PATCH n/m] Subject".
-If given --thread, `git-format-patch` will generate In-Reply-To and
+If given --thread, 'git-format-patch' will generate In-Reply-To and
References headers to make the second and subsequent patch mails appear
as replies to the first mail; this also generates a Message-Id header to
reference.
@@ -175,10 +175,10 @@ and file suffix, and number patches when outputting more than one.
------------
[format]
- headers = "Organization: git-foo\n"
- subjectprefix = CHANGE
- suffix = .txt
- numbered = auto
+ headers = "Organization: git-foo\n"
+ subjectprefix = CHANGE
+ suffix = .txt
+ numbered = auto
cc =
------------
@@ -187,10 +187,10 @@ EXAMPLES
--------
* Extract commits between revisions R1 and R2, and apply them on top of
-the current branch using `git-am` to cherry-pick them:
+the current branch using 'git-am' to cherry-pick them:
+
------------
-$ git format-patch -k --stdout R1..R2 | git-am -3 -k
+$ git format-patch -k --stdout R1..R2 | git am -3 -k
------------
* Extract all commits which are in the current branch but not in the
@@ -206,7 +206,7 @@ For each commit a separate file is created in the current directory.
project:
+
------------
-$ git format-patch \--root origin
+$ git format-patch --root origin
------------
* The same as the previous one:
diff --git a/git-fsck.html b/git-fsck.html
index 95657d08c..a0d7c8dea 100644
--- a/git-fsck.html
+++ b/git-fsck.html
@@ -3,7 +3,7 @@
-
+
git-fsck(1)
@@ -276,13 +324,13 @@ git-fsck(1) Manual Page
git fsck [--tags] [--root] [--unreachable] [--cache] [--no-reflogs]
[--full] [--strict] [--verbose] [--lost-found] [<object>*]
-DESCRIPTION
+DESCRIPTION
-
Verifies the connectivity and validity of the objects in the database.
+
Verifies the connectivity and validity of the objects in the database.
-OPTIONS
+OPTIONS
-
+
<object>
@@ -290,9 +338,9 @@ git-fsck(1) Manual Page
An object to treat as the head of an unreachability trace.
-If no objects are given, git-fsck defaults to using the
+
If no objects are given, git-fsck defaults to using the
index file, all SHA1 references in .git/refs/*, and all reflogs (unless
---no-reflogs is given) as heads.
+--no-reflogs is given) as heads.
--unreachable
@@ -385,31 +433,31 @@ index file, all SHA1 references in .git/refs/*, and all reflogs (unless
its object name.
-
-
It tests SHA1 and general object sanity, and it does full tracking of
+
+It tests SHA1 and general object sanity, and it does full tracking of
the resulting reachability and everything else. It prints out any
corruption it finds (missing or bad objects), and if you use the
--unreachable flag it will also print out objects that exist but
-that aren't readable from any of the specified head nodes.
-
So for example
+that aren't readable from any of the specified head nodes.
+
git fsck --unreachable HEAD $(cat .git/refs/heads/*)
-will do quite a _lot_ of verification on the tree. There are a few
+
will do quite a lot of verification on the tree. There are a few
extra validity tests to be added (make sure that tree objects are
-sorted properly etc), but on the whole if git-fsck is happy, you
-do have a valid tree.
-
Any corrupt objects you will have to find in backups or other archives
-(i.e., you can just remove them and do an rsync with some other site in
-the hopes that somebody else has the object you have corrupted).
-
Of course, "valid tree" doesn't mean that it wasn't generated by some
+sorted properly etc), but on the whole if git-fsck is happy, you
+do have a valid tree.
+Any corrupt objects you will have to find in backups or other archives
+(i.e., you can just remove them and do an rsync with some other site in
+the hopes that somebody else has the object you have corrupted).
+Of course, "valid tree" doesn't mean that it wasn't generated by some
evil person, and the end result might be crap. git is a revision
-tracking system, not a quality assurance system ;)
+tracking system, not a quality assurance system ;)
-Extracted Diagnostics
+
-
+
expect dangling commits - potential heads - due to lack of head information
@@ -477,11 +525,11 @@ sha1 mismatch <object>
This indicates a serious data integrity problem.
-
+
-Environment Variables
+Environment Variables
-
+
GIT_OBJECT_DIRECTORY
@@ -506,23 +554,23 @@ GIT_ALTERNATE_OBJECT_DIRECTORIES
used to specify additional object database roots (usually unset)
-
+
-Author
+Author
-
Written by Linus Torvalds <torvalds@osdl.org>
+
Written by Linus Torvalds <torvalds@osdl.org>
-Documentation
+Documentation
-
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-fsck.txt b/git-fsck.txt
index ef4ceb3df..d5a764721 100644
--- a/git-fsck.txt
+++ b/git-fsck.txt
@@ -21,7 +21,7 @@ OPTIONS
::
An object to treat as the head of an unreachability trace.
+
-If no objects are given, `git-fsck` defaults to using the
+If no objects are given, 'git-fsck' defaults to using the
index file, all SHA1 references in .git/refs/*, and all reflogs (unless
--no-reflogs is given) as heads.
@@ -83,11 +83,11 @@ So for example
will do quite a _lot_ of verification on the tree. There are a few
extra validity tests to be added (make sure that tree objects are
-sorted properly etc), but on the whole if `git-fsck` is happy, you
+sorted properly etc), but on the whole if 'git-fsck' is happy, you
do have a valid tree.
Any corrupt objects you will have to find in backups or other archives
-(i.e., you can just remove them and do an `rsync` with some other site in
+(i.e., you can just remove them and do an 'rsync' with some other site in
the hopes that somebody else has the object you have corrupted).
Of course, "valid tree" doesn't mean that it wasn't generated by some
diff --git a/git-gc.html b/git-gc.html
index 97eec8e0a..bc7ff0f54 100644
--- a/git-gc.html
+++ b/git-gc.html
@@ -3,7 +3,7 @@
-
+
git-gc(1)
@@ -272,36 +320,36 @@ git-gc(1) Manual Page
SYNOPSIS
-
git gc [--aggressive] [--auto] [--quiet]
+
git gc [--aggressive] [--auto] [--quiet]
-DESCRIPTION
+DESCRIPTION
-
Runs a number of housekeeping tasks within the current repository,
+
Runs a number of housekeeping tasks within the current repository,
such as compressing file revisions (to reduce disk space and increase
performance) and removing unreachable objects which may have been
-created from prior invocations of git-add .
-
Users are encouraged to run this task on a regular basis within
+created from prior invocations of git-add .
+
Users are encouraged to run this task on a regular basis within
each repository to maintain good disk space utilization and good
-operating performance.
-
Some git commands may automatically run git-gc ; see the --auto flag
+operating performance.
+
Some git commands may automatically run git-gc ; see the --auto flag
below for details. If you know what you're doing and all you want is to
-disable this behavior permanently without further considerations, just do:
+disable this behavior permanently without further considerations, just do:
$ git config --global gc.auto 0
-OPTIONS
+OPTIONS
-
+
--aggressive
- Usually git-gc runs very quickly while providing good disk
+ Usually git-gc runs very quickly while providing good disk
space utilization and performance. This option will cause
- git-gc to more aggressively optimize the repository at the expense
+ git-gc to more aggressively optimize the repository at the expense
of taking much more time. The effects of this optimization are
persistent, so this option only needs to be used occasionally; every
few hundred changesets or so.
@@ -312,22 +360,22 @@ disable this behavior permanently without further considerations, just do:
- With this option, git-gc checks whether any housekeeping is
+ With this option, git-gc checks whether any housekeeping is
required; if not, it exits without performing any work.
Some git commands run git gc --auto after performing
operations that could create many loose objects.
-Housekeeping is required if there are too many loose objects or
+
Housekeeping is required if there are too many loose objects or
too many packs in the repository. If the number of loose objects
exceeds the value of the gc.auto configuration variable, then
all loose objects are combined into a single pack using
-git-repack -d -l . Setting the value of gc.auto to 0
-disables automatic packing of loose objects.
-
If the number of packs exceeds the value of gc.autopacklimit ,
+git-repack -d -l . Setting the value of gc.auto to 0
+disables automatic packing of loose objects.
+If the number of packs exceeds the value of gc.autopacklimit ,
then existing packs (except those marked with a .keep file)
are consolidated into a single pack by using the -A option of
-git-repack . Setting gc.autopacklimit to 0 disables
-automatic consolidation of packs.
+
git-repack . Setting
gc.autopacklimit to 0 disables
+automatic consolidation of packs.
--quiet
@@ -337,73 +385,73 @@ automatic consolidation of packs.
Suppress all progress reports.
-
+
-Configuration
+Configuration
-
The optional configuration variable gc.reflogExpire can be
+
The optional configuration variable gc.reflogExpire can be
set to indicate how long historical entries within each branch's
reflog should remain available in this repository. The setting is
expressed as a length of time, for example 90 days or 3 months .
-It defaults to 90 days .
-
The optional configuration variable gc.reflogExpireUnreachable
+It defaults to 90 days .
+
The optional configuration variable gc.reflogExpireUnreachable
can be set to indicate how long historical reflog entries which
are not part of the current branch should remain available in
this repository. These types of entries are generally created as
a result of using git commit --amend or git rebase and are the
commits prior to the amend or rebase occurring. Since these changes
are not part of the current project most users will want to expire
-them sooner. This option defaults to 30 days .
-
The optional configuration variable gc.rerereresolved indicates
+them sooner. This option defaults to 30 days .
+
The optional configuration variable gc.rerereresolved indicates
how long records of conflicted merge you resolved earlier are
-kept. This defaults to 60 days.
-
The optional configuration variable gc.rerereunresolved indicates
+kept. This defaults to 60 days.
+
The optional configuration variable gc.rerereunresolved indicates
how long records of conflicted merge you have not resolved are
-kept. This defaults to 15 days.
-
The optional configuration variable gc.packrefs determines if
-git-gc runs git-pack-refs . This can be set to "nobare" to enable
+kept. This defaults to 15 days.
+
The optional configuration variable gc.packrefs determines if
+git-gc runs git-pack-refs . This can be set to "nobare" to enable
it within all non-bare repos or it can be set to a boolean value.
-This defaults to true.
-
The optional configuration variable gc.aggressiveWindow controls how
+This defaults to true.
+
The optional configuration variable gc.aggressiveWindow controls how
much time is spent optimizing the delta compression of the objects in
the repository when the --aggressive option is specified. The larger
the value, the more time is spent optimizing the delta compression. See
the documentation for the --window' option in git-repack(1) for
-more details. This defaults to 10.
-
The optional configuration variable gc.pruneExpire controls how old
+more details. This defaults to 10.
+
The optional configuration variable gc.pruneExpire controls how old
the unreferenced loose objects have to be before they are pruned. The
-default is "2 weeks ago".
+default is "2 weeks ago".
-Notes
+Notes
-
git-gc tries very hard to be safe about the garbage it collects. In
+
git-gc tries very hard to be safe about the garbage it collects. In
particular, it will keep not only objects referenced by your current set
of branches and tags, but also objects referenced by the index, remote
-tracking branches, refs saved by git-filter-branch in
+tracking branches, refs saved by git-filter-branch in
refs/original/, or reflogs (which may references commits in branches
-that were later amended or rewound).
-
If you are expecting some objects to be collected and they aren't, check
+that were later amended or rewound).
+
If you are expecting some objects to be collected and they aren't, check
all of those locations and decide whether it makes sense in your case to
-remove those references.
+remove those references.
-SEE ALSO
+SEE ALSO
-Author
+Author
-
Written by Shawn O. Pearce <spearce@spearce.org>
+
Written by Shawn O. Pearce <spearce@spearce.org>
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-gc.txt b/git-gc.txt
index 0cce3894c..7086eea74 100644
--- a/git-gc.txt
+++ b/git-gc.txt
@@ -15,13 +15,13 @@ DESCRIPTION
Runs a number of housekeeping tasks within the current repository,
such as compressing file revisions (to reduce disk space and increase
performance) and removing unreachable objects which may have been
-created from prior invocations of `git-add`.
+created from prior invocations of 'git-add'.
Users are encouraged to run this task on a regular basis within
each repository to maintain good disk space utilization and good
operating performance.
-Some git commands may automatically run `git-gc`; see the `--auto` flag
+Some git commands may automatically run 'git-gc'; see the `--auto` flag
below for details. If you know what you're doing and all you want is to
disable this behavior permanently without further considerations, just do:
@@ -33,15 +33,15 @@ OPTIONS
-------
--aggressive::
- Usually `git-gc` runs very quickly while providing good disk
+ Usually 'git-gc' runs very quickly while providing good disk
space utilization and performance. This option will cause
- `git-gc` to more aggressively optimize the repository at the expense
+ 'git-gc' to more aggressively optimize the repository at the expense
of taking much more time. The effects of this optimization are
persistent, so this option only needs to be used occasionally; every
few hundred changesets or so.
--auto::
- With this option, `git-gc` checks whether any housekeeping is
+ With this option, 'git-gc' checks whether any housekeeping is
required; if not, it exits without performing any work.
Some git commands run `git gc --auto` after performing
operations that could create many loose objects.
@@ -50,13 +50,13 @@ Housekeeping is required if there are too many loose objects or
too many packs in the repository. If the number of loose objects
exceeds the value of the `gc.auto` configuration variable, then
all loose objects are combined into a single pack using
-`git-repack -d -l`. Setting the value of `gc.auto` to 0
+'git-repack -d -l'. Setting the value of `gc.auto` to 0
disables automatic packing of loose objects.
+
If the number of packs exceeds the value of `gc.autopacklimit`,
then existing packs (except those marked with a `.keep` file)
are consolidated into a single pack by using the `-A` option of
-`git-repack`. Setting `gc.autopacklimit` to 0 disables
+'git-repack'. Setting `gc.autopacklimit` to 0 disables
automatic consolidation of packs.
--quiet::
@@ -89,7 +89,7 @@ how long records of conflicted merge you have not resolved are
kept. This defaults to 15 days.
The optional configuration variable 'gc.packrefs' determines if
-`git-gc` runs `git-pack-refs`. This can be set to "nobare" to enable
+'git-gc' runs 'git-pack-refs'. This can be set to "nobare" to enable
it within all non-bare repos or it can be set to a boolean value.
This defaults to true.
@@ -108,10 +108,10 @@ default is "2 weeks ago".
Notes
-----
-`git-gc` tries very hard to be safe about the garbage it collects. In
+'git-gc' tries very hard to be safe about the garbage it collects. In
particular, it will keep not only objects referenced by your current set
of branches and tags, but also objects referenced by the index, remote
-tracking branches, refs saved by `git-filter-branch` in
+tracking branches, refs saved by 'git-filter-branch' in
refs/original/, or reflogs (which may references commits in branches
that were later amended or rewound).
diff --git a/git-get-tar-commit-id.html b/git-get-tar-commit-id.html
index 50a9ecaeb..0f31272a7 100644
--- a/git-get-tar-commit-id.html
+++ b/git-get-tar-commit-id.html
@@ -3,7 +3,7 @@
-
+
git-get-tar-commit-id(1)
@@ -272,33 +320,33 @@ git-get-tar-commit-id(1) Manual Page
SYNOPSIS
-
git get-tar-commit-id < <tarfile>
+
git get-tar-commit-id < <tarfile>
-DESCRIPTION
+DESCRIPTION
-
Acts as a filter, extracting the commit ID stored in archives created by
-git-archive . It reads only the first 1024 bytes of input, thus its
-runtime is not influenced by the size of <tarfile> very much.
-
If no commit ID is found, git-get-tar-commit-id quietly exists with a
+
Acts as a filter, extracting the commit ID stored in archives created by
+git-archive . It reads only the first 1024 bytes of input, thus its
+runtime is not influenced by the size of <tarfile> very much.
+
If no commit ID is found, git-get-tar-commit-id quietly exists with a
return code of 1. This can happen if <tarfile> had not been created
-using git-archive or if the first parameter of git-archive had been
-a tree ID instead of a commit ID or tag.
+using
git-archive or if the first parameter of
git-archive had been
+a tree ID instead of a commit ID or tag.
-Author
+Author
-
Written by Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
+
Written by Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
-Documentation
+Documentation
-
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-get-tar-commit-id.txt b/git-get-tar-commit-id.txt
index 50dfdfa19..84f23ee52 100644
--- a/git-get-tar-commit-id.txt
+++ b/git-get-tar-commit-id.txt
@@ -14,12 +14,12 @@ SYNOPSIS
DESCRIPTION
-----------
Acts as a filter, extracting the commit ID stored in archives created by
-`git-archive`. It reads only the first 1024 bytes of input, thus its
+'git-archive'. It reads only the first 1024 bytes of input, thus its
runtime is not influenced by the size of very much.
-If no commit ID is found, `git-get-tar-commit-id` quietly exists with a
+If no commit ID is found, 'git-get-tar-commit-id' quietly exists with a
return code of 1. This can happen if had not been created
-using `git-archive` or if the first parameter of `git-archive` had been
+using 'git-archive' or if the first parameter of 'git-archive' had been
a tree ID instead of a commit ID or tag.
diff --git a/git-grep.html b/git-grep.html
index 7d3d200d6..0fc0117eb 100644
--- a/git-grep.html
+++ b/git-grep.html
@@ -3,7 +3,7 @@
-
+
git-grep(1)
@@ -285,14 +333,14 @@ git-grep(1) Manual Page
[--and|--or|--not|(|)|-e <pattern>…] [<tree>…]
[--] [<path>…]
-DESCRIPTION
+DESCRIPTION
-
Look for specified patterns in the working tree files, blobs
-registered in the index file, or given tree objects.
+
Look for specified patterns in the working tree files, blobs
+registered in the index file, or given tree objects.
-OPTIONS
+OPTIONS
-
+
--cached
@@ -440,7 +488,7 @@ registered in the index file, or given tree objects.
Instead of showing every matched line, show only the
names of files that contain (or do not contain) matches.
- For better compatibility with git-diff , --name-only is a
+ For better compatibility with git-diff , --name-only is a
synonym for --files-with-matches.
@@ -541,11 +589,11 @@ registered in the index file, or given tree objects.
are <path> limiters.
-
+
-Example
+Example
-
+
git grep -e '#define' --and \( -e MAX_PATH -e PATH_MAX \)
@@ -564,24 +612,24 @@ git grep --all-match -e NODE -e Unexpected
files that have lines that match both.
-
+
-Author
+Author
-
Originally written by Linus Torvalds <torvalds@osdl.org>, later
-revamped by Junio C Hamano.
+
Originally written by Linus Torvalds <torvalds@osdl.org>, later
+revamped by Junio C Hamano.
-Documentation
+Documentation
-
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-grep.txt b/git-grep.txt
index 25cb64957..fa4d133c1 100644
--- a/git-grep.txt
+++ b/git-grep.txt
@@ -91,7 +91,7 @@ OPTIONS
--files-without-match::
Instead of showing every matched line, show only the
names of files that contain (or do not contain) matches.
- For better compatibility with `git-diff`, --name-only is a
+ For better compatibility with 'git-diff', --name-only is a
synonym for --files-with-matches.
-c::
diff --git a/git-gui.html b/git-gui.html
index b7667a0eb..b8cccbf60 100644
--- a/git-gui.html
+++ b/git-gui.html
@@ -3,7 +3,7 @@
-
+
git-gui(1)
@@ -272,26 +320,26 @@ git-gui(1) Manual Page
SYNOPSIS
-
git gui [<command>] [arguments]
+
git gui [<command>] [arguments]
-DESCRIPTION
+DESCRIPTION
-
A Tcl/Tk based graphical user interface to Git. git-gui focuses
+
A Tcl/Tk based graphical user interface to Git. git-gui focuses
on allowing users to make changes to their repository by making
new commits, amending existing ones, creating branches, performing
-local merges, and fetching/pushing to remote repositories.
-
Unlike gitk , git-gui focuses on commit generation
+local merges, and fetching/pushing to remote repositories.
+
Unlike gitk , git-gui focuses on commit generation
and single file annotation and does not show project history.
-It does however supply menu actions to start a gitk session from
-within git-gui .
-
git-gui is known to work on all popular UNIX systems, Mac OS X,
+It does however supply menu actions to start a gitk session from
+within git-gui .
+
git-gui is known to work on all popular UNIX systems, Mac OS X,
and Windows (under both Cygwin and MSYS). To the extent possible
-OS specific user interface guidelines are followed, making git-gui
-a fairly native interface for users.
+OS specific user interface guidelines are followed, making
git-gui
+a fairly native interface for users.
-COMMANDS
+COMMANDS
-
+
blame
@@ -316,7 +364,7 @@ citool
- Start git-gui and arrange to make exactly one commit before
+ Start git-gui and arrange to make exactly one commit before
exiting and returning to the shell. The interface is limited
to only commit actions, slightly reducing the application's
startup time and simplifying the menubar.
@@ -327,14 +375,14 @@ version
- Display the currently running version of git-gui .
+ Display the currently running version of git-gui .
-
+
-Examples
+Examples
-
+
git gui blame Makefile
@@ -372,7 +420,7 @@ git citool
- Same as git gui citool (above).
+ Same as git gui citool (above).
@@ -385,11 +433,11 @@ git gui browser maint
blame viewer.
-
+
-SEE ALSO
+SEE ALSO
-
+
gitk(1)
@@ -397,43 +445,43 @@ git gui browser maint
The git repository browser. Shows branches, commit history
and file differences. gitk is the utility started by
- git-gui 's Repository Visualize actions.
+ git-gui 's Repository Visualize actions.
-
+
-Other
+Other
-
git-gui is actually maintained as an independent project, but stable
+
git-gui is actually maintained as an independent project, but stable
versions are distributed as part of the Git suite for the convenience
-of end users.
-
A git-gui development repository can be obtained from:
+of end users.
+
A git-gui development repository can be obtained from:
git clone git://repo.or.cz/git-gui.git
-
or
+
git clone http://repo.or.cz/r/git-gui.git
-
or browsed online at http://repo.or.cz/w/git-gui.git/ .
+
-Author
+Author
-
Written by Shawn O. Pearce <spearce@spearce.org>.
+
Written by Shawn O. Pearce <spearce@spearce.org>.
-Documentation
+Documentation
-
Documentation by Shawn O. Pearce <spearce@spearce.org>.
+
Documentation by Shawn O. Pearce <spearce@spearce.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-gui.txt b/git-gui.txt
index 940e43f37..0e650f497 100644
--- a/git-gui.txt
+++ b/git-gui.txt
@@ -11,19 +11,19 @@ SYNOPSIS
DESCRIPTION
-----------
-A Tcl/Tk based graphical user interface to Git. `git-gui` focuses
+A Tcl/Tk based graphical user interface to Git. 'git-gui' focuses
on allowing users to make changes to their repository by making
new commits, amending existing ones, creating branches, performing
local merges, and fetching/pushing to remote repositories.
-Unlike `gitk`, `git-gui` focuses on commit generation
+Unlike 'gitk', 'git-gui' focuses on commit generation
and single file annotation and does not show project history.
-It does however supply menu actions to start a `gitk` session from
-within `git-gui`.
+It does however supply menu actions to start a 'gitk' session from
+within 'git-gui'.
-`git-gui` is known to work on all popular UNIX systems, Mac OS X,
+'git-gui' is known to work on all popular UNIX systems, Mac OS X,
and Windows (under both Cygwin and MSYS). To the extent possible
-OS specific user interface guidelines are followed, making `git-gui`
+OS specific user interface guidelines are followed, making 'git-gui'
a fairly native interface for users.
COMMANDS
@@ -34,17 +34,17 @@ blame::
browser::
Start a tree browser showing all files in the specified
- commit (or 'HEAD' by default). Files selected through the
+ commit (or 'HEAD' by default). Files selected through the
browser are opened in the blame viewer.
citool::
- Start `git-gui` and arrange to make exactly one commit before
+ Start 'git-gui' and arrange to make exactly one commit before
exiting and returning to the shell. The interface is limited
to only commit actions, slightly reducing the application's
startup time and simplifying the menubar.
version::
- Display the currently running version of `git-gui`.
+ Display the currently running version of 'git-gui'.
Examples
@@ -61,7 +61,7 @@ git gui blame Makefile::
git gui blame v0.99.8 Makefile::
Show the contents of 'Makefile' in revision 'v0.99.8'
- and provide annotations for each line. Unlike the above
+ and provide annotations for each line. Unlike the above
example the file is read from the object database and not
the working directory.
@@ -71,7 +71,7 @@ git gui citool::
git citool::
- Same as 'git gui citool' (above).
+ Same as `git gui citool` (above).
git gui browser maint::
@@ -84,15 +84,15 @@ SEE ALSO
linkgit:gitk[1]::
The git repository browser. Shows branches, commit history
and file differences. gitk is the utility started by
- `git-gui`'s Repository Visualize actions.
+ 'git-gui''s Repository Visualize actions.
Other
-----
-`git-gui` is actually maintained as an independent project, but stable
+'git-gui' is actually maintained as an independent project, but stable
versions are distributed as part of the Git suite for the convenience
of end users.
-A `git-gui` development repository can be obtained from:
+A 'git-gui' development repository can be obtained from:
git clone git://repo.or.cz/git-gui.git
diff --git a/git-hash-object.html b/git-hash-object.html
index 38273aee2..ea0909ecf 100644
--- a/git-hash-object.html
+++ b/git-hash-object.html
@@ -3,7 +3,7 @@
-
+
git-hash-object(1)
@@ -272,21 +320,21 @@ git-hash-object(1) Manual Page
SYNOPSIS
-
git hash-object [-t <type>] [-w] [--stdin | --stdin-paths] [--] <file>…
+
git hash-object [-t <type>] [-w] [--stdin | --stdin-paths] [--] <file>…
-DESCRIPTION
+DESCRIPTION
-
Computes the object ID value for an object with specified type
+
Computes the object ID value for an object with specified type
with the contents of the named file (which can be outside of the
work tree), and optionally writes the resulting object into the
object database. Reports its object ID to its standard output.
-This is used by git-cvsimport to update the index
+This is used by git-cvsimport to update the index
without modifying files in the work tree. When <type> is not
-specified, it defaults to "blob".
+specified, it defaults to "blob".
-OPTIONS
+OPTIONS
-
+
-t <type>
@@ -319,23 +367,23 @@ specified, it defaults to "blob".
Read file names from stdin instead of from the command-line.
-
+
-Author
+Author
-
Written by Junio C Hamano <junkio@cox.net>
+
Written by Junio C Hamano <junkio@cox.net>
-Documentation
+Documentation
-
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-hash-object.txt b/git-hash-object.txt
index 05550c5ac..9e654fc41 100644
--- a/git-hash-object.txt
+++ b/git-hash-object.txt
@@ -16,7 +16,7 @@ Computes the object ID value for an object with specified type
with the contents of the named file (which can be outside of the
work tree), and optionally writes the resulting object into the
object database. Reports its object ID to its standard output.
-This is used by `git-cvsimport` to update the index
+This is used by 'git-cvsimport' to update the index
without modifying files in the work tree. When is not
specified, it defaults to "blob".
diff --git a/git-help.html b/git-help.html
index a0ca75eae..953e0a10d 100644
--- a/git-help.html
+++ b/git-help.html
@@ -3,7 +3,7 @@
-
+
git-help(1)
@@ -272,24 +320,24 @@ git-help(1) Manual Page
SYNOPSIS
-
git help [-a|--all|-i|--info|-m|--man|-w|--web] [COMMAND]
+
git help [-a|--all|-i|--info|-m|--man|-w|--web] [COMMAND]
-DESCRIPTION
+DESCRIPTION
-
With no options and no COMMAND given, the synopsis of the git
+
With no options and no COMMAND given, the synopsis of the git
command and a list of the most commonly used git commands are printed
-on the standard output.
-
If the option --all or -a is given, then all available commands are
-printed on the standard output.
-
If a git command is named, a manual page for that command is brought
+on the standard output.
+
If the option --all or -a is given, then all available commands are
+printed on the standard output.
+
If a git command is named, a manual page for that command is brought
up. The man program is used by default for this purpose, but this
-can be overridden by other options or configuration variables.
-
Note that git --help … is identical as git help … because the
-former is internally converted into the latter.
+can be overridden by other options or configuration variables.
+
Note that git --help … is identical to git help … because the
+former is internally converted into the latter.
-OPTIONS
+OPTIONS
-
+
-a
@@ -326,9 +374,9 @@ former is internally converted into the latter.
option may be used to override a value set in the
help.format configuration variable.
-By default the man program will be used to display the manual page,
+
By default the man program will be used to display the manual page,
but the man.viewer configuration variable may be used to choose
-other display programs (see below).
+other display programs (see below).
-w
@@ -341,22 +389,22 @@ other display programs (see below).
Display manual page for the command in the web (HTML)
format. A web browser will be used for that purpose.
-The web browser can be specified using the configuration variable
+
The web browser can be specified using the configuration variable
help.browser , or web.browser if the former is not set. If none of
-these config variables is set, the git-web--browse helper script
-(called by git-help ) will pick a suitable default. See
-git-web--browse(1) for more information about this.
+these config variables is set, the
git-web--browse helper script
+(called by
git-help ) will pick a suitable default. See
+
git-web--browse(1) for more information about this.
-
+
-CONFIGURATION VARIABLES
+CONFIGURATION VARIABLES
-
help.format
-
If no command line option is passed, the help.format configuration
+
+
If no command line option is passed, the help.format configuration
variable will be checked. The following values are supported for this
-variable; they make git-help behave as their corresponding command
-line option:
-
+variable; they make git-help behave as their corresponding command
+line option:
+
-
help.browser, web.browser and browser.<tool>.path
-
The help.browser , web.browser and browser.<tool>.path will also
+
+
+
The help.browser , web.browser and browser.<tool>.path will also
be checked if the web format is chosen (either by command line
option or configuration variable). See -w|--web in the OPTIONS
-section above and git-web--browse(1) .
-
man.viewer
-
The man.viewer config variable will be checked if the man format
-is chosen. The following values are currently supported:
-
+
man.viewer
+
The man.viewer config variable will be checked if the man format
+is chosen. The following values are currently supported:
+
"man": use the man program as usual,
@@ -399,44 +447,44 @@ is chosen. The following values are currently supported:
tab (see Note about konqueror below).
-
-
Values for other tools can be used if there is a corresponding
-man.<tool>.cmd configuration entry (see below).
-
Multiple values may be given to the man.viewer configuration
+
+
Values for other tools can be used if there is a corresponding
+man.<tool>.cmd configuration entry (see below).
+
Multiple values may be given to the man.viewer configuration
variable. Their corresponding programs will be tried in the order
-listed in the configuration file.
-
For example, this configuration:
+listed in the configuration file.
+
For example, this configuration:
[man]
viewer = konqueror
viewer = woman
-
will try to use konqueror first. But this may fail (for example if
-DISPLAY is not set) and in that case emacs' woman mode will be tried.
-
If everything fails the man program will be tried anyway.
-
man.<tool>.path
-
You can explicitly provide a full path to your preferred man viewer by
+
will try to use konqueror first. But this may fail (for example if
+DISPLAY is not set) and in that case emacs' woman mode will be tried.
+
If everything fails the man program will be tried anyway.
+
+
You can explicitly provide a full path to your preferred man viewer by
setting the configuration variable man.<tool>.path . For example, you
can configure the absolute path to konqueror by setting
-man.konqueror.path . Otherwise, git help assumes the tool is
-available in PATH.
-
man.<tool>.cmd
-
When the man viewer, specified by the man.viewer configuration
+man.konqueror.path . Otherwise, git-help assumes the tool is
+available in PATH.
+
+
When the man viewer, specified by the man.viewer configuration
variables, is not among the supported ones, then the corresponding
man.<tool>.cmd configuration variable will be looked up. If this
variable exists then the specified tool will be treated as a custom
command and a shell eval will be used to run the command with the man
-page passed as arguments.
-
Note about konqueror
-
When konqueror is specified in the man.viewer configuration
+page passed as arguments.
+
Note about konqueror
+
When konqueror is specified in the man.viewer configuration
variable, we launch kfmclient to try to open the man page on an
-already opened konqueror in a new tab if possible.
-
For consistency, we also try such a trick if man.konqueror.path is
+already opened konqueror in a new tab if possible.
+
For consistency, we also try such a trick if man.konqueror.path is
set to something like A_PATH_TO/konqueror . That means we will try to
-launch A_PATH_TO/kfmclient instead.
-
If you really want to use konqueror , then you can use something like
-the following:
+launch
A_PATH_TO/kfmclient instead.
+
If you really want to use konqueror , then you can use something like
+the following:
[man]
@@ -445,35 +493,35 @@ the following:
[man "konq"]
cmd = A_PATH_TO/konqueror
-
Note about git config --global
-
Note that all these configuration variables should probably be set
-using the --global flag, for example like this:
+
Note about git config --global
+
Note that all these configuration variables should probably be set
+using the --global flag, for example like this:
$ git config --global help.format web
$ git config --global web.browser firefox
-
as they are probably more user specific than repository specific.
-See git-config(1) for more information about this.
+
as they are probably more user specific than repository specific.
+See git-config(1) for more information about this.
-Author
+Author
-
Written by Junio C Hamano <gitster@pobox.com> and the git-list
-<git@vger.kernel.org>.
+
Written by Junio C Hamano <gitster@pobox.com> and the git-list
+<git@vger.kernel.org>.
-Documentation
+Documentation
-
Initial documentation was part of the git(1) man page.
+
Initial documentation was part of the git(1) man page.
Christian Couder <chriscool@tuxfamily.org> extracted and rewrote it a
-little. Maintenance is done by the git-list <git@vger.kernel.org>.
+little. Maintenance is done by the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-help.txt b/git-help.txt
index 5ace863c1..f414583fc 100644
--- a/git-help.txt
+++ b/git-help.txt
@@ -23,7 +23,7 @@ If a git command is named, a manual page for that command is brought
up. The 'man' program is used by default for this purpose, but this
can be overridden by other options or configuration variables.
-Note that 'git --help ...' is identical as 'git help ...' because the
+Note that `git --help ...` is identical to `git help ...` because the
former is internally converted into the latter.
OPTIONS
@@ -55,8 +55,8 @@ other display programs (see below).
+
The web browser can be specified using the configuration variable
'help.browser', or 'web.browser' if the former is not set. If none of
-these config variables is set, the `git-web--browse` helper script
-(called by `git-help`) will pick a suitable default. See
+these config variables is set, the 'git-web--browse' helper script
+(called by 'git-help') will pick a suitable default. See
linkgit:git-web--browse[1] for more information about this.
CONFIGURATION VARIABLES
@@ -67,7 +67,7 @@ help.format
If no command line option is passed, the 'help.format' configuration
variable will be checked. The following values are supported for this
-variable; they make `git-help` behave as their corresponding command
+variable; they make 'git-help' behave as their corresponding command
line option:
* "man" corresponds to '-m|--man',
@@ -120,7 +120,7 @@ man..path
You can explicitly provide a full path to your preferred man viewer by
setting the configuration variable 'man..path'. For example, you
can configure the absolute path to konqueror by setting
-'man.konqueror.path'. Otherwise, 'git help' assumes the tool is
+'man.konqueror.path'. Otherwise, 'git-help' assumes the tool is
available in PATH.
man..cmd
diff --git a/git-http-fetch.html b/git-http-fetch.html
index 5ed9ef290..028bd920a 100644
--- a/git-http-fetch.html
+++ b/git-http-fetch.html
@@ -3,7 +3,7 @@
-
+
git-http-fetch(1)
@@ -272,15 +320,15 @@ git-http-fetch(1) Manual Page
SYNOPSIS
-
git http-fetch [-c] [-t] [-a] [-d] [-v] [-w filename] [--recover] [--stdin] <commit> <url>
+
git http-fetch [-c] [-t] [-a] [-d] [-v] [-w filename] [--recover] [--stdin] <commit> <url>
-DESCRIPTION
+DESCRIPTION
-
Downloads a remote git repository via HTTP.
+
Downloads a remote git repository via HTTP.
-OPTIONS
+OPTIONS
-
+
commit-id
@@ -337,7 +385,7 @@ commit-id
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
+ case), git-http-fetch expects lines on stdin in the format
@@ -353,23 +401,23 @@ commit-id
an earlier fetch is interrupted.
-
+
-Author
+Author
-
Written by Linus Torvalds <torvalds@osdl.org>
+
Written by Linus Torvalds <torvalds@osdl.org>
-Documentation
+Documentation
-
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-http-fetch.txt b/git-http-fetch.txt
index cfc5989b9..e7c796155 100644
--- a/git-http-fetch.txt
+++ b/git-http-fetch.txt
@@ -35,7 +35,7 @@ commit-id::
--stdin::
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
+ case), 'git-http-fetch' expects lines on stdin in the format
['\t']
diff --git a/git-imap-send.html b/git-imap-send.html
index 73fc27173..742816742 100644
--- a/git-imap-send.html
+++ b/git-imap-send.html
@@ -3,7 +3,7 @@
-
+
git-imap-send(1)
@@ -272,21 +320,21 @@ git-imap-send(1) Manual Page
SYNOPSIS
-DESCRIPTION
+DESCRIPTION
-
This command uploads a mailbox generated with git-format-patch
+
This command uploads a mailbox generated with git-format-patch
into an imap drafts folder. This allows patches to be sent as
other email is sent with mail clients that cannot read mailbox
-files directly.
-
Typical usage is something like:
-
git format-patch --signoff --stdout --attach origin | git imap-send
+files directly.
+
Typical usage is something like:
+
git format-patch --signoff --stdout --attach origin | git imap-send
-CONFIGURATION
+CONFIGURATION
-
git-imap-send requires the following values in the repository
-configuration file (shown with examples):
+
git-imap-send requires the following values in the repository
+configuration file (shown with examples):
[imap]
@@ -302,25 +350,25 @@ configuration file (shown with examples):
Port = 143
-BUGS
+BUGS
-
Doesn't handle lines starting with "From " in the message body.
+
Doesn't handle lines starting with "From " in the message body.
-Author
+Author
-
Derived from isync 1.0.1 by Mike McCormack.
+
Derived from isync 1.0.1 by Mike McCormack.
-Documentation
+Documentation
-
Documentation by Mike McCormack
+
Documentation by Mike McCormack
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-imap-send.txt b/git-imap-send.txt
index 776aa254d..b3d8da33e 100644
--- a/git-imap-send.txt
+++ b/git-imap-send.txt
@@ -26,7 +26,7 @@ git format-patch --signoff --stdout --attach origin | git imap-send
CONFIGURATION
-------------
-`git-imap-send` requires the following values in the repository
+'git-imap-send' requires the following values in the repository
configuration file (shown with examples):
..........................
diff --git a/git-index-pack.html b/git-index-pack.html
index b80cfb46b..93e3f8676 100644
--- a/git-index-pack.html
+++ b/git-index-pack.html
@@ -3,7 +3,7 @@
-
+
git-index-pack(1)
@@ -277,16 +325,16 @@ git-index-pack(1) Manual Page
git index-pack --stdin [--fix-thin] [--keep] [-v] [-o <index-file>]
[<pack-file>]
-DESCRIPTION
+DESCRIPTION
-
Reads a packed archive (.pack) from the specified file, and
+
Reads a packed archive (.pack) from the specified file, and
builds a pack index file (.idx) for it. The packed archive
together with the pack index can then be placed in the
-objects/pack/ directory of a git repository.
+objects/pack/ directory of a git repository.
-OPTIONS
+OPTIONS
-
+
-v
@@ -320,7 +368,7 @@ objects/pack/ directory of a git repository.
a default name determined from the pack content. If
<pack-file> is not specified consider using --keep to
prevent a race condition between this process and
- git-repack .
+ git-repack .
@@ -328,7 +376,7 @@ objects/pack/ directory of a git repository.
- It is possible for git-pack-objects to build
+ It is possible for git-pack-objects to build
"thin" pack, which records objects in deltified form based on
objects not included in the pack to reduce network traffic.
Those objects are expected to be present on the receiving end
@@ -346,7 +394,7 @@ objects/pack/ directory of a git repository.
Before moving the index into its final destination
create an empty .keep file for the associated pack file.
This option is usually necessary with --stdin to prevent a
- simultaneous git-repack process from deleting
+ simultaneous git-repack process from deleting
the newly constructed pack and index before refs can be
updated to use objects contained in the pack.
@@ -381,32 +429,32 @@ objects/pack/ directory of a git repository.
Die, if the pack contains broken objects or links.
-
+
-Note
+Note
-
Once the index has been created, the list of object names is sorted
+
Once the index has been created, the list of object names is sorted
and the SHA1 hash of that list is printed to stdout. If --stdin was
also used then this is prefixed by either "pack\t", or "keep\t" if a
new .keep file was successfully created. This is useful to remove a
-.keep file used as a lock to prevent the race with git-repack
-mentioned above.
+.keep file used as a lock to prevent the race with
git-repack
+mentioned above.
-Author
+Author
-
Written by Sergey Vlasov <vsu@altlinux.ru>
+
Written by Sergey Vlasov <vsu@altlinux.ru>
-Documentation
+Documentation
-
Documentation by Sergey Vlasov
+
Documentation by Sergey Vlasov
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-index-pack.txt b/git-index-pack.txt
index 194023774..4b5c743c1 100644
--- a/git-index-pack.txt
+++ b/git-index-pack.txt
@@ -43,10 +43,10 @@ OPTIONS
a default name determined from the pack content. If
is not specified consider using --keep to
prevent a race condition between this process and
- `git-repack`.
+ 'git-repack'.
--fix-thin::
- It is possible for `git-pack-objects` to build
+ It is possible for 'git-pack-objects' to build
"thin" pack, which records objects in deltified form based on
objects not included in the pack to reduce network traffic.
Those objects are expected to be present on the receiving end
@@ -59,7 +59,7 @@ OPTIONS
Before moving the index into its final destination
create an empty .keep file for the associated pack file.
This option is usually necessary with --stdin to prevent a
- simultaneous `git-repack` process from deleting
+ simultaneous 'git-repack' process from deleting
the newly constructed pack and index before refs can be
updated to use objects contained in the pack.
@@ -86,7 +86,7 @@ Once the index has been created, the list of object names is sorted
and the SHA1 hash of that list is printed to stdout. If --stdin was
also used then this is prefixed by either "pack\t", or "keep\t" if a
new .keep file was successfully created. This is useful to remove a
-.keep file used as a lock to prevent the race with `git-repack`
+.keep file used as a lock to prevent the race with 'git-repack'
mentioned above.
diff --git a/git-init.html b/git-init.html
index ccdb11773..ba308c710 100644
--- a/git-init.html
+++ b/git-init.html
@@ -3,7 +3,7 @@
-
+
git-init(1)
@@ -272,11 +320,11 @@ git-init(1) Manual Page
SYNOPSIS
-
git init [-q | --quiet] [--bare] [--template=<template_directory>] [--shared[=<permissions>]]
+
git init [-q | --quiet] [--bare] [--template=<template_directory>] [--shared[=<permissions>]]
-OPTIONS
+OPTIONS
-
+
-q
@@ -305,11 +353,11 @@ current working directory.
Provide the directory from which templates will be used. The default template
directory is /usr/share/git-core/templates .
-When specified, <template_directory> is used as the source of the template
+
When specified, <template_directory> is used as the source of the template
files rather than the default. The template files include some directory
structure, some suggested "exclude patterns", and copies of non-executing
"hook" files. The suggested patterns and hook files are all modifiable and
-extensible.
+extensible.
--shared[={false|true|umask|group|all|world|everybody|0xxx}]
@@ -323,9 +371,9 @@ set so that files and directories under $GIT_DIR are created with the
requested permissions. When not specified, git will use permissions reported
by umask(2).
-The option can have the following values, defaulting to group if no value
-is given:
-
+
-DESCRIPTION
+DESCRIPTION
-
This command creates an empty git repository - basically a .git directory
+
This command creates an empty git repository - basically a .git directory
with subdirectories for objects , refs/heads , refs/tags , and
template files.
An initial HEAD file that references the HEAD of the master branch
-is also created.
-
If the $GIT_DIR environment variable is set then it specifies a path
-to use instead of ./.git for the base of the repository.
-
If the object storage directory is specified via the $GIT_OBJECT_DIRECTORY
+is also created.
+
If the $GIT_DIR environment variable is set then it specifies a path
+to use instead of ./.git for the base of the repository.
+
If the object storage directory is specified via the $GIT_OBJECT_DIRECTORY
environment variable then the sha1 directories are created underneath -
-otherwise the default $GIT_DIR/objects directory is used.
-
Running git-init in an existing repository is safe. It will not overwrite
-things that are already there. The primary reason for rerunning git-init
-is to pick up newly added templates.
-
Note that git-init is the same as git-init-db . The command
+otherwise the default $GIT_DIR/objects directory is used.
+
Running git-init in an existing repository is safe. It will not overwrite
+things that are already there. The primary reason for rerunning git-init
+is to pick up newly added templates.
+
Note that git-init is the same as git-init-db . The command
was primarily meant to initialize the object database, but over
time it has become responsible for setting up the other aspects
of the repository, such as installing the default hooks and
setting the configuration variables. The old name is retained
-for backward compatibility reasons.
+for backward compatibility reasons.
-EXAMPLES
+EXAMPLES
-
+
Start a new git repository for an existing code base
@@ -395,7 +443,7 @@ Start a new git repository for an existing code base
$ git init (1)
$ git add . (2)
-
+
prepare /path/to/my/codebase/.git directory
@@ -406,25 +454,25 @@ prepare /path/to/my/codebase/.git directory
add all existing file to the index
-
+
-
+
-Author
+Author
-
Written by Linus Torvalds <torvalds@osdl.org>
+
Written by Linus Torvalds <torvalds@osdl.org>
-Documentation
+Documentation
-
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-init.txt b/git-init.txt
index 45244737f..71749c09d 100644
--- a/git-init.txt
+++ b/git-init.txt
@@ -86,11 +86,11 @@ If the object storage directory is specified via the `$GIT_OBJECT_DIRECTORY`
environment variable then the sha1 directories are created underneath -
otherwise the default `$GIT_DIR/objects` directory is used.
-Running `git-init` in an existing repository is safe. It will not overwrite
-things that are already there. The primary reason for rerunning `git-init`
+Running 'git-init' in an existing repository is safe. It will not overwrite
+things that are already there. The primary reason for rerunning 'git-init'
is to pick up newly added templates.
-Note that `git-init` is the same as `git-init-db`. The command
+Note that 'git-init' is the same as 'git-init-db'. The command
was primarily meant to initialize the object database, but over
time it has become responsible for setting up the other aspects
of the repository, such as installing the default hooks and
diff --git a/git-instaweb.html b/git-instaweb.html
index 24b42b434..37e773d25 100644
--- a/git-instaweb.html
+++ b/git-instaweb.html
@@ -3,7 +3,7 @@
-
+
git-instaweb(1)
@@ -277,14 +325,14 @@ git-instaweb(1) Manual Page
[--browser=<browser>]
git instaweb [--start] [--stop] [--restart]
-DESCRIPTION
+DESCRIPTION
-
A simple script to set up gitweb and a web server for browsing the local
-repository.
+
A simple script to set up gitweb and a web server for browsing the local
+repository.
-OPTIONS
+OPTIONS
-
+
-l
@@ -343,7 +391,7 @@ repository.
The web browser that should be used to view the gitweb
- page. This will be passed to the git-web--browse helper
+ page. This will be passed to the git-web--browse helper
script along with the URL of the gitweb instance. See
git-web--browse(1) for more information about this. If
the script fails, the URL will be printed to stdout.
@@ -377,11 +425,11 @@ repository.
any of the configuration files for spawning a new instance.
-
+
-CONFIGURATION
+CONFIGURATION
-
You may specify configuration in your .git/config
+
You may specify configuration in your .git/config
[instaweb]
@@ -392,25 +440,25 @@ repository.
modulepath = /usr/lib/apache2/modules
-
If the configuration variable instaweb.browser is not set,
+
If the configuration variable instaweb.browser is not set,
web.browser will be used instead if it is defined. See
-git-web--browse(1) for more information about this.
+
git-web--browse(1) for more information about this.
-Author
+Author
-
Written by Eric Wong <normalperson@yhbt.net>
+
Written by Eric Wong <normalperson@yhbt.net>
-Documentation
+Documentation
-
Documentation by Eric Wong <normalperson@yhbt.net>.
+
Documentation by Eric Wong <normalperson@yhbt.net>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-instaweb.txt b/git-instaweb.txt
index e7ca537e3..22da21a54 100644
--- a/git-instaweb.txt
+++ b/git-instaweb.txt
@@ -44,7 +44,7 @@ OPTIONS
-b::
--browser::
The web browser that should be used to view the gitweb
- page. This will be passed to the `git-web--browse` helper
+ page. This will be passed to the 'git-web--browse' helper
script along with the URL of the gitweb instance. See
linkgit:git-web--browse[1] for more information about this. If
the script fails, the URL will be printed to stdout.
diff --git a/git-log.html b/git-log.html
index 030962c91..a9805861e 100644
--- a/git-log.html
+++ b/git-log.html
@@ -3,7 +3,7 @@
-
+
git-log(1)
@@ -272,19 +320,19 @@ git-log(1) Manual Page
SYNOPSIS
-DESCRIPTION
+DESCRIPTION
-
Shows the commit logs.
-
The command takes options applicable to the git-rev-list
+
+
The command takes options applicable to the git-rev-list
command to control what is shown and how, and options applicable to
-the git-diff-* commands to control how the changes
-each commit introduces are shown.
+the
git-diff-* commands to control how the changes
+each commit introduces are shown.
-OPTIONS
+OPTIONS
-
+
-p
@@ -756,10 +804,10 @@ each commit introduces are shown.
Do not show any source or destination prefix.
-
-
For more detailed explanation on these common options, see also
-gitdiffcore(7) .
-
+
+For more detailed explanation on these common options, see also
+gitdiffcore(7) .
+
-<n>
@@ -829,9 +877,9 @@ each commit introduces are shown.
Show only commits that affect the specified paths.
-
-
Commit Formatting
-
+
+
+
--pretty[=<format> ]
@@ -842,8 +890,8 @@ each commit introduces are shown.
full , fuller , email , raw and format:<string> .
When omitted, the format defaults to medium .
-Note: you can specify the default pretty format in the repository
-configuration (see git-config(1) ).
+Note: you can specify the default pretty format in the repository
+configuration (see git-config(1) ).
--abbrev-commit
@@ -855,8 +903,8 @@ configuration (see git-config(1) ).
digits can be specified with "--abbrev=<n>" (which also modifies
diff output, if it is displayed).
-This should make "--pretty=oneline" a whole lot more readable for
-people using 80-column terminals.
+This should make "--pretty=oneline" a whole lot more readable for
+people using 80-column terminals.
--encoding[=<encoding>]
@@ -887,15 +935,15 @@ people using 80-column terminals.
as when using "--pretty". log.date config variable sets a default
value for log command's --date option.
---date=relative shows dates relative to the current time,
-e.g. "2 hours ago".
---date=local shows timestamps in user's local timezone.
---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 format.
---date=default shows timestamps in the original timezone
-(either committer's or author's).
+--date=relative shows dates relative to the current time,
+e.g. "2 hours ago".
+--date=local shows timestamps in user's local timezone.
+--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 format.
+--date=default shows timestamps in the original timezone
+(either committer's or author's).
--parents
@@ -915,7 +963,7 @@ format, often found in E-mail messages.
the right with > . If combined with --boundary , those
commits are prefixed with - .
-For example, if you have this topology:
+For example, if you have this topology:
y---b---b branch B
@@ -924,7 +972,7 @@ format, often found in E-mail messages.
/ / \
o---x---a---a branch A
-you would get an output line this:
+you would get an output line this:
$ git rev-list --left-right --boundary --pretty=oneline A...B
@@ -947,15 +995,15 @@ format, often found in E-mail messages.
to be printed in between commits, in order for the graph history
to be drawn properly.
- This implies the --topo-order option by default, but the
---date-order option may also be specified.
+This implies the --topo-order option by default, but the
+--date-order option may also be specified.
-
-Diff Formatting
-Below are listed options that control the formatting of diff output.
+
+
+
Below are listed options that control the formatting of diff output.
Some of them are specific to git-rev-list(1) , however other diff
-options may be given. See git-diff-files(1) for more options.
-
+options may be given. See git-diff-files(1) for more options.
+
-c
@@ -995,12 +1043,12 @@ options may be given. See git-diff-files(1) fo
Show the tree objects in the diff output. This implies -r .
-
-
Commit Limiting
-
Besides specifying a range of commits that should be listed using the
+
+
Commit Limiting
+
Besides specifying a range of commits that should be listed using the
special notations explained in the description, additional commit
-limiting may be applied.
-
+limiting may be applied.
+
-n number
@@ -1195,8 +1243,8 @@ used in the output. When the starting commit is specified as
instead. Under --pretty=oneline , the commit message is
prefixed with this information on the same line.
-Cannot be combined with --reverse .
-See also git-reflog(1) .
+
--merge
@@ -1228,14 +1276,14 @@ When optional paths are given, the default behaviour (--dense ) is to
only output commits that changes at least one of them, and also ignore
merges that do not touch the given paths.
-Use the --sparse flag to makes the command output all eligible commits
+
Use the --sparse flag to makes the command output all eligible commits
(still subject to count and age limitation), but apply merge
-simplification nevertheless.
+simplification nevertheless.
-
-
Commit Ordering
-
By default, the commits are shown in reverse chronological order.
-
+
+
Commit Ordering
+
By default, the commits are shown in reverse chronological order.
+
--topo-order
@@ -1264,10 +1312,10 @@ simplification nevertheless.
Cannot be combined with --walk-reflogs .
-
-
Object Traversal
-
These options are mostly targeted for packing of git repositories.
-
+
+
Object Traversal
+
These options are mostly targeted for packing of git repositories.
+
--objects
@@ -1316,11 +1364,11 @@ simplification nevertheless.
Overrides a previous --no-walk.
-
+
-PRETTY FORMATS
+
-
If the commit is a merge, and if the pretty-format
+
If the commit is a merge, and if the pretty-format
is not oneline , email or raw , an additional line is
inserted before the Author: line. This line begins with
"Merge: " and the sha1s of ancestral commits are printed,
@@ -1328,9 +1376,9 @@ separated by spaces. Note that the listed commits may not
necessarily be the list of the direct parent commits if you
have limited your view of history: for example, if you are
only interested in changes related to a certain directory or
-file.
-
Here are some additional details for each format:
-
+
Here are some additional details for each format:
+
-
This is designed to be as compact as possible.
+
This is designed to be as compact as possible.
@@ -1363,7 +1411,7 @@ Author: <author>
commit <sha1>
Author: <author>
-Date: <date>
+Date: <author date>
@@ -1401,9 +1449,9 @@ Commit: <committer>
commit <sha1>
Author: <author>
-AuthorDate: <date & time>
+AuthorDate: <author date>
Commit: <committer>
-CommitDate: <date & time>
+CommitDate: <committer date>
@@ -1422,7 +1470,7 @@ CommitDate: <date & time>
From <sha1> <date>
From: <author>
-Date: <date & time>
+Date: <author date>
Subject: [PATCH] <title line>
@@ -1434,31 +1482,31 @@ Subject: [PATCH] <title line>
raw
-
The raw format shows the entire commit exactly as
+
The raw format shows the entire commit exactly as
stored in the commit object. Notably, the SHA1s are
displayed in full, regardless of whether --abbrev or
--no-abbrev are used, and parents information show the
true parent commits, without taking grafts nor history
-simplification into account.
+simplification into account.
format:
-The format: format allows you to specify which information
+
The format: format allows you to specify which information
you want to show. It works a little bit like printf format,
with the notable exception that you get a newline with %n
-instead of \n .
-
E.g, format:"The author of %h was %an, %ar%nThe title was >>%s<<%n"
-would show something like this:
+instead of
\n .
+E.g, format:"The author of %h was %an, %ar%nThe title was >>%s<<%n"
+would show something like this:
The author of fe6e0ee was Junio C Hamano, 23 hours ago
The title was >>t4119: test autocomputing -p<n> for traditional diff input.<<
-The placeholders are:
-
tformat:
-The tformat: format works exactly like format: , except that it
+
The tformat: format works exactly like format: , except that it
provides "terminator" semantics instead of "separator" semantics. In
other words, each commit has the message terminator character (usually a
newline) appended, rather than a separator placed between entries.
This means that the final entry of a single-line format will be properly
terminated with a new line, just as the "oneline" format does.
-For example:
+For example:
$ git log -2 --pretty=format:%h 4da45bef \
@@ -1635,19 +1683,19 @@ $ git log -2 --pretty=tformat:%h 4da45bef \
7134973
-
+
-
Generating patches with -p
+
Generating patches with -p
-
When "git-diff-index", "git-diff-tree", or "git-diff-files" are run
+
When "git-diff-index", "git-diff-tree", or "git-diff-files" are run
with a -p option, "git diff" without the --raw option, or
"git log" with the "-p" option, they
do not produce the output described above; instead they produce a
patch file. You can customize the creation of such patches via the
-GIT_EXTERNAL_DIFF and the GIT_DIFF_OPTS environment variables.
-
What the -p option produces is slightly different from the traditional
-diff format.
-
+GIT_EXTERNAL_DIFF and the GIT_DIFF_OPTS environment variables.
+
What the -p option produces is slightly different from the traditional
+diff format.
+
It is preceded with a "git diff" header, that looks like
@@ -1657,12 +1705,12 @@ It is preceded with a "git diff" header, that looks like
diff --git a/file1 b/file2
-
The a/ and b/ filenames are the same unless rename/copy is
+
The a/ and b/ filenames are the same unless rename/copy is
involved. Especially, even for a creation or a deletion,
-/dev/null is _not_ used in place of a/ or b/ filenames.
-
When rename/copy is involved, file1 and file2 show the
+/dev/null is not used in place of a/ or b/ filenames.
+
When rename/copy is involved, file1 and file2 show the
name of the source file of the rename/copy and the name of
-the file that rename/copy produces, respectively.
+the file that rename/copy produces, respectively.
@@ -1691,20 +1739,20 @@ TAB, LF, double quote and backslash characters in pathnames
pathname is put in double quotes.
-
-
The similarity index is the percentage of unchanged lines, and
+
+
The similarity index is the percentage of unchanged lines, and
the dissimilarity index is the percentage of changed lines. It
is a rounded down integer, followed by a percent sign. The
similarity index value of 100% is thus reserved for two equal
files, while 100% dissimilarity means that no line from the old
-file made it into the new one.
+file made it into the new one.
-combined diff format
+
-
"git-diff-tree", "git-diff-files" and "git-diff" can take -c or
+
"git-diff-tree", "git-diff-files" and "git-diff" can take -c or
--cc option to produce combined diff . For showing a merge commit
with "git log -p", this is the default format.
-A combined diff format looks like this:
+A
combined diff format looks like this:
diff --combined describe.c
@@ -1735,7 +1783,7 @@ index fabadb8,cc95eb0..4866510
initialized = 1;
for_each_ref(get_name);
-
+
It is preceded with a "git diff" header, that looks like
@@ -1745,7 +1793,7 @@ It is preceded with a "git diff" header, that looks like
-or like this (when --cc option is used):
+or like this (when --cc option is used):
diff --c file
@@ -1763,11 +1811,11 @@ mode <mode>,<mode>..<mode>
new file mode <mode>
deleted file mode <mode>,<mode>
-The mode <mode>,<mode>..<mode> line appears only if at least one of
+
The mode <mode>,<mode>..<mode> line appears only if at least one of
the <mode> is different from the rest. Extended headers with
information about detected contents movement (renames and
copying detection) are designed to work with diff of two
-<tree-ish> and are not used by combined diff format.
+<tree-ish> and are not used by combined diff format.
@@ -1778,9 +1826,9 @@ It is followed by two-line from-file/to-file header
--- a/file
+++ b/file
-Similar to two-line header for traditional unified diff
+
Similar to two-line header for traditional unified diff
format, /dev/null is used to signal created or deleted
-files.
+files.
@@ -1794,38 +1842,38 @@ Chunk header format is modified to prevent people from
@@@ <from-file-range> <from-file-range> <to-file-range> @@@
-There are (number of parents + 1) @ characters in the chunk
-header for combined diff format.
+There are (number of parents + 1) @ characters in the chunk
+header for combined diff format.
-
-Unlike the traditional unified diff format, which shows two
+
+
Unlike the traditional unified diff format, which shows two
files A and B with a single column that has - (minus —
appears in A but removed in B), + (plus — missing in A but
added to B), or " " (space — unchanged) prefix, this format
compares two or more files file1, file2,… with one file X, and
shows how X differs from each of fileN. One column for each of
fileN is prepended to the output line to note how X's line is
-different from it.
-
A - character in the column N means that the line appears in
+different from it.
+A - character in the column N means that the line appears in
fileN but it does not appear in the result. A + character
in the column N means that the line appears in the last file,
and fileN does not have that line (in other words, the line was
-added, from the point of view of that parent).
-
In the above example output, the function signature was changed
+added, from the point of view of that parent).
+In the above example output, the function signature was changed
from both files (hence two - removals from both file1 and
-file2, plus ++ to mean one line that was added does not appear
+file2, plus + to mean one line that was added does not appear
in either file1 nor file2). Also two other lines are the same
-from file1 but do not appear in file2 (hence prefixed with + ).
-
When shown by git diff-tree -c , it compares the parents of a
+from file1 but do not appear in file2 (hence prefixed with ).
+When shown by git diff-tree -c , it compares the parents of a
merge commit with the merge result (i.e. file1..fileN are the
parents). When shown by git diff-files -c , it compares the
two unresolved merge parents with the working tree file
(i.e. file1 is stage 2 aka "our version", file2 is stage 3 aka
-"their version").
+"their version").
-Examples
+Examples
-
+
git log --no-merges
@@ -1873,12 +1921,12 @@ git log --follow builtin-rev-list.c
present name.
-
+
-Discussion
+Discussion
-
At the core level, git is character encoding agnostic.
-
+At the core level, git is character encoding agnostic.
+
-
Although we encourage that the commit log messages are encoded
+
+Although we encourage that the commit log messages are encoded
in UTF-8, both the core and git Porcelain are designed not to
force UTF-8 on projects. If all participants of a particular
project find it more convenient to use legacy encodings, git
does not forbid it. However, there are a few things to keep in
-mind.
-
+mind.
+
-git-commit-tree (hence, git-commit which uses it) issues
+git-commit-tree (hence, git-commit which uses it) issues
a warning if the commit log message given to it does not look
like a valid UTF-8 string, unless you explicitly say your
project uses a legacy encoding. The way to say this is to
@@ -1923,14 +1971,14 @@ mind.
[i18n]
commitencoding = ISO-8859-1
-Commit objects created with the above setting record the value
+
Commit objects created with the above setting record the value
of i18n.commitencoding in its encoding header. This is to
help other people who look at them later. Lack of this header
-implies that the commit log message is encoded in UTF-8.
+implies that the commit log message is encoded in UTF-8.
-git-log , git-show and friends looks at the encoding
+git-log , git-show and friends looks at the encoding
header of a commit object, and tries to re-code the log
message into UTF-8 unless otherwise specified. You can
specify the desired output encoding with
@@ -1941,30 +1989,30 @@ implies that the commit log message is encoded in UTF-8.
[i18n]
logoutputencoding = ISO-8859-1
-If you do not have this configuration variable, the value of
-i18n.commitencoding is used instead.
+If you do not have this configuration variable, the value of
+i18n.commitencoding is used instead.
-
-Note that we deliberately chose not to re-code the commit log
+
+
Note that we deliberately chose not to re-code the commit log
message when a commit is made to force UTF-8 at the commit
object level, because re-coding to UTF-8 is not necessarily a
-reversible operation.
+reversible operation.
-Author
+Author
-
Written by Linus Torvalds <torvalds@osdl.org>
+
Written by Linus Torvalds <torvalds@osdl.org>
-Documentation
+Documentation
-
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-log.txt b/git-log.txt
index 3373c2636..5a58d5b03 100644
--- a/git-log.txt
+++ b/git-log.txt
@@ -14,9 +14,9 @@ DESCRIPTION
-----------
Shows the commit logs.
-The command takes options applicable to the `git-rev-list`
+The command takes options applicable to the 'git-rev-list'
command to control what is shown and how, and options applicable to
-the `git-diff-*` commands to control how the changes
+the 'git-diff-*' commands to control how the changes
each commit introduces are shown.
diff --git a/git-ls-files.html b/git-ls-files.html
index 7cb7be093..934a06db6 100644
--- a/git-ls-files.html
+++ b/git-ls-files.html
@@ -3,7 +3,7 @@
-
+
git-ls-files(1)
@@ -283,17 +331,17 @@ git-ls-files(1) Manual Page
[--error-unmatch] [--with-tree=<tree-ish>]
[--full-name] [--abbrev] [--] [<file>]*
-DESCRIPTION
+DESCRIPTION
-
This merges the file listing in the directory cache index with the
+
This merges the file listing in the directory cache index with the
actual working directory list, and shows different combinations of the
-two.
-
One or more of the options below may be used to determine the files
-shown:
+two.
+
One or more of the options below may be used to determine the files
+shown:
-OPTIONS
+OPTIONS
-
+
-c
@@ -579,35 +627,35 @@ other
specified criteria are shown.
-
+
-Output
+Output
-
show files just outputs the filename unless --stage is specified in
-which case it outputs:
+
show files just outputs the filename unless --stage is specified in
+which case it outputs:
[<tag> ]<mode> <object> <stage> <file>
-
git-ls-files --unmerged and git-ls-files --stage can be used to examine
-detailed information on unmerged paths.
-
For an unmerged path, instead of recording a single mode/SHA1 pair,
+
git-ls-files --unmerged and git-ls-files --stage can be used to examine
+detailed information on unmerged paths.
+
For an unmerged path, instead of recording a single mode/SHA1 pair,
the index records up to three such pairs; one from tree O in stage
1, A in stage 2, and B in stage 3. This information can be used by
the user (or the porcelain) to see what should eventually be recorded at the
-path. (see git-read-tree(1) for more information on state)
-
When -z option is not used, TAB, LF, and backslash characters
+path. (see git-read-tree(1) for more information on state)
+
When -z option is not used, TAB, LF, and backslash characters
in pathnames are represented as \t , \n , and \\ ,
-respectively.
+respectively.
-Exclude Patterns
+Exclude Patterns
-
git-ls-files can use a list of "exclude patterns" when
+
git-ls-files can use a list of "exclude patterns" when
traversing the directory tree and finding files to show when the
flags --others or --ignored are specified. gitignore(5)
-specifies the format of exclude patterns.
-
These exclude patterns come from these places, in order:
-
+specifies the format of exclude patterns.
+
These exclude patterns come from these places, in order:
+
The command line flag --exclude=<pattern> specifies a
@@ -625,38 +673,38 @@ The command line flag --exclude-from=<file> specifies a
command line flag --exclude-per-directory=<name> specifies
- a name of the file in each directory git-ls-files
+ a name of the file in each directory git-ls-files
examines, normally .gitignore . Files in deeper
directories take precedence. Patterns are ordered in the
same order they appear in the files.
-
-
A pattern specified on the command line with --exclude or read
+
+
A pattern specified on the command line with --exclude or read
from the file specified with --exclude-from is relative to the
top of the directory tree. A pattern read from a file specified
by --exclude-per-directory is relative to the directory that the
-pattern file appears in.
+pattern file appears in.
-SEE ALSO
+SEE ALSO
-Author
+Author
-
Written by Linus Torvalds <torvalds@osdl.org>
+
Written by Linus Torvalds <torvalds@osdl.org>
-Documentation
+Documentation
-
Documentation by David Greaves, Junio C Hamano, Josh Triplett, and the git-list <git@vger.kernel.org>.
+
Documentation by David Greaves, Junio C Hamano, Josh Triplett, and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-ls-files.txt b/git-ls-files.txt
index a6883bf43..f43af4174 100644
--- a/git-ls-files.txt
+++ b/git-ls-files.txt
@@ -143,7 +143,7 @@ which case it outputs:
[ ]
-`git-ls-files --unmerged` and `git-ls-files --stage` can be used to examine
+'git-ls-files --unmerged' and 'git-ls-files --stage' can be used to examine
detailed information on unmerged paths.
For an unmerged path, instead of recording a single mode/SHA1 pair,
@@ -160,7 +160,7 @@ respectively.
Exclude Patterns
----------------
-`git-ls-files` can use a list of "exclude patterns" when
+'git-ls-files' can use a list of "exclude patterns" when
traversing the directory tree and finding files to show when the
flags --others or --ignored are specified. linkgit:gitignore[5]
specifies the format of exclude patterns.
@@ -176,7 +176,7 @@ These exclude patterns come from these places, in order:
in the same order they appear in the file.
3. command line flag --exclude-per-directory= specifies
- a name of the file in each directory `git-ls-files`
+ a name of the file in each directory 'git-ls-files'
examines, normally `.gitignore`. Files in deeper
directories take precedence. Patterns are ordered in the
same order they appear in the files.
diff --git a/git-ls-remote.html b/git-ls-remote.html
index 731a8909f..a29ca8d58 100644
--- a/git-ls-remote.html
+++ b/git-ls-remote.html
@@ -3,7 +3,7 @@
-
+
git-ls-remote(1)
@@ -276,14 +324,14 @@ git-ls-remote(1) Manual Page
git ls-remote [--heads] [--tags] [-u <exec> | --upload-pack <exec>]
<repository> <refs>…
-DESCRIPTION
+DESCRIPTION
-
Displays references available in a remote repository along with the associated
-commit IDs.
+
Displays references available in a remote repository along with the associated
+commit IDs.
-OPTIONS
+OPTIONS
-
+
-h
@@ -299,7 +347,7 @@ commit IDs.
Limit to only refs/heads and refs/tags, respectively.
- These options are _not_ mutually exclusive; when given
+ These options are not mutually exclusive; when given
both, references stored in refs/heads and refs/tags are
displayed.
@@ -312,7 +360,7 @@ commit IDs.
- Specify the full path of git-upload-pack on the remote
+ Specify the full path of git-upload-pack on the remote
host. This allows listing references from repositories accessed via
SSH and where the SSH daemon does not use the PATH configured by the
user.
@@ -339,9 +387,9 @@ commit IDs.
are displayed.
-
+
-EXAMPLES
+EXAMPLES
@@ -363,17 +411,17 @@ c5db5456ae3b0873fc659c19fafdde22313cc441 refs/tags/v0.99.2
7ceca275d047c90c0c7d5afb13ab97efdf51bd6e refs/tags/v0.99.3
-Author
+Author
-
Written by Junio C Hamano <junkio@cox.net>
+
Written by Junio C Hamano <junkio@cox.net>
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-ls-remote.txt b/git-ls-remote.txt
index c267cdae4..4f252441e 100644
--- a/git-ls-remote.txt
+++ b/git-ls-remote.txt
@@ -31,7 +31,7 @@ OPTIONS
-u ::
--upload-pack=::
- Specify the full path of `git-upload-pack` on the remote
+ Specify the full path of 'git-upload-pack' on the remote
host. This allows listing references from repositories accessed via
SSH and where the SSH daemon does not use the PATH configured by the
user.
diff --git a/git-mailinfo.html b/git-mailinfo.html
index 6a61a955b..6ebda7a71 100644
--- a/git-mailinfo.html
+++ b/git-mailinfo.html
@@ -3,7 +3,7 @@
-
+
git-mailinfo(1)
@@ -272,20 +320,20 @@ git-mailinfo(1) Manual Page
SYNOPSIS
-
git mailinfo [-k] [-u | --encoding=<encoding>] <msg> <patch>
+
git mailinfo [-k] [-u | --encoding=<encoding>] <msg> <patch>
-DESCRIPTION
+DESCRIPTION
-
Reading a single e-mail message from the standard input, and
+
Reading a single e-mail message from the standard input, and
writes the commit log message in <msg> file, and the patches in
<patch> file. The author name, e-mail and e-mail subject are
-written out to the standard output to be used by git-am
+written out to the standard output to be used by git-am
to create a commit. It is usually not necessary to use this
-command directly. See git-am(1) instead.
+command directly. See
git-am(1) instead.
-OPTIONS
+OPTIONS
-
+
-k
@@ -297,7 +345,7 @@ command directly. See git-am(1) instead.
whitespaces, (3) [ up to ] , typically [PATCH] , and
then prepends "[PATCH] ". This flag forbids this
munging, and is most useful when used to read back
- git-format-patch -k output.
+ git-format-patch -k output.
@@ -310,8 +358,8 @@ command directly. See git-am(1) instead.
transfer encoding, re-coded in UTF-8 by transliterating
them. This used to be optional but now it is the default.
-Note that the patch is always used as-is without charset
-conversion, even with this flag.
+Note that the patch is always used as-is without charset
+conversion, even with this flag.
--encoding=<encoding>
@@ -340,24 +388,24 @@ conversion, even with this flag.
The patch extracted from e-mail.
-
+
-Author
+Author
-
Written by Linus Torvalds <torvalds@osdl.org> and
-Junio C Hamano <junkio@cox.net>
+
Written by Linus Torvalds <torvalds@osdl.org> and
+Junio C Hamano <junkio@cox.net>
-Documentation
+Documentation
-
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-mailinfo.txt b/git-mailinfo.txt
index 6ebdeee84..cc52db3be 100644
--- a/git-mailinfo.txt
+++ b/git-mailinfo.txt
@@ -16,7 +16,7 @@ DESCRIPTION
Reading a single e-mail message from the standard input, and
writes the commit log message in file, and the patches in
file. The author name, e-mail and e-mail subject are
-written out to the standard output to be used by `git-am`
+written out to the standard output to be used by 'git-am'
to create a commit. It is usually not necessary to use this
command directly. See linkgit:git-am[1] instead.
@@ -30,7 +30,7 @@ OPTIONS
whitespaces, (3) '[' up to ']', typically '[PATCH]', and
then prepends "[PATCH] ". This flag forbids this
munging, and is most useful when used to read back
- `git-format-patch -k` output.
+ 'git-format-patch -k' output.
-u::
The commit log message, author name and author email are
diff --git a/git-merge-base.html b/git-merge-base.html
index 9c7cc1d48..450530c79 100644
--- a/git-merge-base.html
+++ b/git-merge-base.html
@@ -3,7 +3,7 @@
-
+
git-merge-base(1)
@@ -272,21 +320,21 @@ git-merge-base(1) Manual Page
SYNOPSIS
-
git merge-base [--all] <commit> <commit>
+
git merge-base [--all] <commit> <commit>
-DESCRIPTION
+DESCRIPTION
-
git-merge-base finds as good a common ancestor as possible between
+
git-merge-base finds as good a common ancestor as possible between
the two commits. That is, given two commits A and B, git merge-base A
B will output a commit which is reachable from both A and B through
-the parent relationship.
-
Given a selection of equally good common ancestors it should not be
-relied on to decide in any particular way.
-
The git-merge-base algorithm is still in flux - use the source…
+the parent relationship.
+
Given a selection of equally good common ancestors it should not be
+relied on to decide in any particular way.
+
The git-merge-base algorithm is still in flux - use the source…
-OPTIONS
+OPTIONS
-
+
--all
@@ -296,23 +344,23 @@ relied on to decide in any particular way.
just one.
-
+
-Author
+Author
-
Written by Linus Torvalds <torvalds@osdl.org>
+
Written by Linus Torvalds <torvalds@osdl.org>
-Documentation
+Documentation
-
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-merge-base.txt b/git-merge-base.txt
index 41fb0c76a..1a7ecbf8f 100644
--- a/git-merge-base.txt
+++ b/git-merge-base.txt
@@ -13,7 +13,7 @@ SYNOPSIS
DESCRIPTION
-----------
-`git-merge-base` finds as good a common ancestor as possible between
+'git-merge-base' finds as good a common ancestor as possible between
the two commits. That is, given two commits A and B, `git merge-base A
B` will output a commit which is reachable from both A and B through
the parent relationship.
@@ -21,7 +21,7 @@ the parent relationship.
Given a selection of equally good common ancestors it should not be
relied on to decide in any particular way.
-The `git-merge-base` algorithm is still in flux - use the source...
+The 'git-merge-base' algorithm is still in flux - use the source...
OPTIONS
-------
diff --git a/git-merge-file.html b/git-merge-file.html
index d44d79295..6dd32ecf5 100644
--- a/git-merge-file.html
+++ b/git-merge-file.html
@@ -3,7 +3,7 @@
-
+
git-merge-file(1)
@@ -276,18 +324,18 @@ git-merge-file(1) Manual Page
git merge-file [-L <current-name> [-L <base-name> [-L <other-name>]]]
[-p|--stdout] [-q|--quiet] <current-file> <base-file> <other-file>
-DESCRIPTION
+DESCRIPTION
-
git-file-merge incorporates all changes that lead from the <base-file>
+
git-file-merge incorporates all changes that lead from the <base-file>
to <other-file> into <current-file> . The result ordinarily goes into
-<current-file> . git-merge-file is useful for combining separate changes
+<current-file> . git-merge-file is useful for combining separate changes
to an original. Suppose <base-file> is the original, and both
<current-file> and <other-file> are modifications of <base-file> .
-Then git-merge-file combines both changes.
-
A conflict occurs if both <current-file> and <other-file> have changes
-in a common segment of lines. If a conflict is found, git-merge-file
+Then git-merge-file combines both changes.
+
A conflict occurs if both <current-file> and <other-file> have changes
+in a common segment of lines. If a conflict is found, git-merge-file
normally outputs a warning and brackets the conflict with <<<<<<< and
->>>>>>> lines. A typical conflict will look like this:
+>>>>>>> lines. A typical conflict will look like this:
<<<<<<< A
@@ -296,17 +344,17 @@ lines in file A
lines in file B
>>>>>>> B
-
If there are conflicts, the user should edit the result and delete one of
-the alternatives.
-
The exit value of this program is negative on error, and the number of
-conflicts otherwise. If the merge was clean, the exit value is 0.
-
git-merge-file is designed to be a minimal clone of RCS merge ; that is, it
-implements all of RCS merge's functionality which is needed by
-git(1) .
+
If there are conflicts, the user should edit the result and delete one of
+the alternatives.
+
The exit value of this program is negative on error, and the number of
+conflicts otherwise. If the merge was clean, the exit value is 0.
+
git-merge-file is designed to be a minimal clone of RCS merge ; that is, it
+implements all of RCS merge 's functionality which is needed by
+git(1) .
-OPTIONS
+OPTIONS
-
+
-L <label>
@@ -337,11 +385,11 @@ implements all of RCS merge's functionality which is needed by
Quiet; do not warn about conflicts.
-
+
-EXAMPLES
+EXAMPLES
-
+
git merge-file README.my README README.upstream
@@ -360,24 +408,24 @@ git merge-file -L a -L b -L c tmp/a123 tmp/b234 tmp/c345
a and c instead of tmp/a123 and tmp/c345 .
-
+
-Author
+Author
-
Written by Johannes Schindelin <johannes.schindelin@gmx.de>
+
Written by Johannes Schindelin <johannes.schindelin@gmx.de>
-Documentation
+Documentation
-
Documentation by Johannes Schindelin and the git-list <git@vger.kernel.org>,
-with parts copied from the original documentation of RCS merge.
+
Documentation by Johannes Schindelin and the git-list <git@vger.kernel.org>,
+with parts copied from the original documentation of RCS merge .
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-merge-file.txt b/git-merge-file.txt
index f057e4995..024ec015a 100644
--- a/git-merge-file.txt
+++ b/git-merge-file.txt
@@ -15,15 +15,15 @@ SYNOPSIS
DESCRIPTION
-----------
-`git-file-merge` incorporates all changes that lead from the ``
+'git-file-merge' incorporates all changes that lead from the ``
to `` into ``. The result ordinarily goes into
-``. `git-merge-file` is useful for combining separate changes
+``. 'git-merge-file' is useful for combining separate changes
to an original. Suppose `` is the original, and both
`` and `` are modifications of ``.
-Then `git-merge-file` combines both changes.
+Then 'git-merge-file' combines both changes.
A conflict occurs if both `` and `` have changes
-in a common segment of lines. If a conflict is found, `git-merge-file`
+in a common segment of lines. If a conflict is found, 'git-merge-file'
normally outputs a warning and brackets the conflict with <<<<<<< and
>>>>>>> lines. A typical conflict will look like this:
@@ -39,8 +39,8 @@ the alternatives.
The exit value of this program is negative on error, and the number of
conflicts otherwise. If the merge was clean, the exit value is 0.
-`git-merge-file` is designed to be a minimal clone of RCS `merge`; that is, it
-implements all of RCS merge's functionality which is needed by
+'git-merge-file' is designed to be a minimal clone of RCS 'merge'; that is, it
+implements all of RCS 'merge''s functionality which is needed by
linkgit:git[1].
@@ -85,7 +85,7 @@ Written by Johannes Schindelin
Documentation
--------------
Documentation by Johannes Schindelin and the git-list ,
-with parts copied from the original documentation of RCS merge.
+with parts copied from the original documentation of RCS 'merge'.
GIT
---
diff --git a/git-merge-index.html b/git-merge-index.html
index 5c5e0f9d5..efd6ed38f 100644
--- a/git-merge-index.html
+++ b/git-merge-index.html
@@ -3,7 +3,7 @@
-
+
git-merge-index(1)
@@ -272,18 +320,18 @@ git-merge-index(1) Manual Page
SYNOPSIS
-
git merge-index [-o] [-q] <merge-program> (-a | [--] <file>*)
+
git merge-index [-o] [-q] <merge-program> (-a | [--] <file>*)
-DESCRIPTION
+DESCRIPTION
-
This looks up the <file>(s) in the index and, if there are any merge
+
This looks up the <file>(s) in the index and, if there are any merge
entries, passes the SHA1 hash for those files as arguments 1, 2, 3 (empty
argument if no file), and <file> as argument 4. File modes for the three
-files are passed as arguments 5, 6 and 7.
+files are passed as arguments 5, 6 and 7.
-OPTIONS
+OPTIONS
-
+
--
@@ -321,19 +369,19 @@ files are passed as arguments 5, 6 and 7.
porcelains which might want to emit custom messages.
-
-
If git-merge-index is called with multiple <file>s (or -a) then it
+
+If git-merge-index is called with multiple <file>s (or -a) then it
processes them in turn only stopping if merge returns a non-zero exit
-code.
-
Typically this is run with a script calling git's imitation of
-the merge command from the RCS package.
-
A sample script called git-merge-one-file is included in the
-distribution.
-
ALERT ALERT ALERT! The git "merge object order" is different from the
-RCS merge program merge object order. In the above ordering, the
+code.
+Typically this is run with a script calling git's imitation of
+the merge command from the RCS package.
+A sample script called git-merge-one-file is included in the
+distribution.
+ALERT ALERT ALERT! The git "merge object order" is different from the
+RCS merge program merge object order. In the above ordering, the
original is first. But the argument order to the 3-way merge program
-merge is to have the original in the middle. Don't ask me why.
-
Examples:
+
merge is to have the original in the middle. Don't ask me why.
+
torvalds@ppc970:~/merge-test> git merge-index cat MM
@@ -342,7 +390,7 @@ This is modified MM in the branch A. # merge1
This is modified MM in the branch B. # merge2
This is modified MM in the branch B. # current contents
-or
+
torvalds@ppc970:~/merge-test> git merge-index cat AA MM
@@ -352,27 +400,27 @@ This is added AA in the branch B.
This is added AA in the branch B.
fatal: merge program failed
-where the latter example shows how git-merge-index will stop trying to
+
where the latter example shows how git-merge-index will stop trying to
merge once anything has returned an error (i.e., cat returned an error
for the AA file, because it didn't exist in the original, and thus
-git-merge-index didn't even try to merge the MM thing).
+
git-merge-index didn't even try to merge the MM thing).
-Author
+Author
-
Written by Linus Torvalds <torvalds@osdl.org>
-One-shot merge by Petr Baudis <pasky@ucw.cz>
+
Written by Linus Torvalds <torvalds@osdl.org>
+One-shot merge by Petr Baudis <pasky@ucw.cz>
-Documentation
+Documentation
-
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-merge-index.txt b/git-merge-index.txt
index 43680840e..ff088c5c2 100644
--- a/git-merge-index.txt
+++ b/git-merge-index.txt
@@ -36,20 +36,20 @@ OPTIONS
failure usually indicates conflicts during merge). This is for
porcelains which might want to emit custom messages.
-If `git-merge-index` is called with multiple s (or -a) then it
+If 'git-merge-index' is called with multiple s (or -a) then it
processes them in turn only stopping if merge returns a non-zero exit
code.
Typically this is run with a script calling git's imitation of
-the merge command from the RCS package.
+the 'merge' command from the RCS package.
-A sample script called `git-merge-one-file` is included in the
+A sample script called 'git-merge-one-file' is included in the
distribution.
ALERT ALERT ALERT! The git "merge object order" is different from the
-RCS `merge` program merge object order. In the above ordering, the
+RCS 'merge' program merge object order. In the above ordering, the
original is first. But the argument order to the 3-way merge program
-`merge` is to have the original in the middle. Don't ask me why.
+'merge' is to have the original in the middle. Don't ask me why.
Examples:
@@ -68,10 +68,10 @@ or
This is added AA in the branch B.
fatal: merge program failed
-where the latter example shows how `git-merge-index` will stop trying to
+where the latter example shows how 'git-merge-index' will stop trying to
merge once anything has returned an error (i.e., `cat` returned an error
for the AA file, because it didn't exist in the original, and thus
-`git-merge-index` didn't even try to merge the MM thing).
+'git-merge-index' didn't even try to merge the MM thing).
Author
------
diff --git a/git-merge-one-file.html b/git-merge-one-file.html
index 03bcedfd2..d40203f53 100644
--- a/git-merge-one-file.html
+++ b/git-merge-one-file.html
@@ -3,7 +3,7 @@
-
+
git-merge-one-file(1)
@@ -272,29 +320,29 @@ git-merge-one-file(1) Manual Page
SYNOPSIS
-DESCRIPTION
+DESCRIPTION
-
This is the standard helper program to use with git-merge-index
-to resolve a merge after the trivial merge done with git-read-tree -m .
+
This is the standard helper program to use with git-merge-index
+to resolve a merge after the trivial merge done with git-read-tree -m .
-Author
+Author
-
Written by Linus Torvalds <torvalds@osdl.org>,
-Junio C Hamano <junkio@cox.net> and Petr Baudis <pasky@suse.cz>.
+
Written by Linus Torvalds <torvalds@osdl.org>,
+Junio C Hamano <junkio@cox.net> and Petr Baudis <pasky@suse.cz>.
-Documentation
+Documentation
-
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-merge-one-file.txt b/git-merge-one-file.txt
index 62e09afe1..1dd134538 100644
--- a/git-merge-one-file.txt
+++ b/git-merge-one-file.txt
@@ -12,8 +12,8 @@ SYNOPSIS
DESCRIPTION
-----------
-This is the standard helper program to use with `git-merge-index`
-to resolve a merge after the trivial merge done with `git-read-tree -m`.
+This is the standard helper program to use with 'git-merge-index'
+to resolve a merge after the trivial merge done with 'git-read-tree -m'.
Author
------
diff --git a/git-merge.html b/git-merge.html
index 12b4a4c83..90992fcf1 100644
--- a/git-merge.html
+++ b/git-merge.html
@@ -3,7 +3,7 @@
-
+
git-merge(1)
@@ -277,17 +325,17 @@ git-merge(1) Manual Page
[-m <msg>] <remote> <remote>…
git merge <msg> HEAD <remote>…
-DESCRIPTION
+DESCRIPTION
-
This is the top-level interface to the merge machinery
-which drives multiple merge strategy scripts.
-
The second syntax (<msg> HEAD <remote>) is supported for
+
This is the top-level interface to the merge machinery
+which drives multiple merge strategy scripts.
+
The second syntax (<msg> HEAD <remote>) is supported for
historical reasons. Do not use it from the command line or in
-new scripts. It is the same as git merge -m <msg> <remote> .
+new scripts. It is the same as
git merge -m <msg> <remote> .
-OPTIONS
+OPTIONS
-
+
--stat
@@ -411,8 +459,8 @@ new scripts. It is the same as git merge -m <msg> <remote>
Use the given merge strategy; can be supplied more than
once to specify them in the order they should be tried.
If there is no -s option, a built-in list of strategies
- is used instead (git-merge-recursive when merging a single
- head, git-merge-octopus otherwise).
+ is used instead (git-merge-recursive when merging a single
+ head, git-merge-octopus otherwise).
@@ -421,8 +469,8 @@ new scripts. It is the same as git merge -m <msg> <remote>
The commit message to be used for the merge commit (in case
- it is created). The git-fmt-merge-msg script can be used
- to give a good default for automated git-merge invocations.
+ it is created). The git-fmt-merge-msg script can be used
+ to give a good default for automated git-merge invocations.
@@ -435,11 +483,11 @@ new scripts. It is the same as git merge -m <msg> <remote>
obviously means you are trying an Octopus.
-
+
-MERGE STRATEGIES
+MERGE STRATEGIES
-
+
resolve
@@ -505,13 +553,13 @@ subtree
ancestor tree.
-
-
If you tried a merge which resulted in a complex conflicts and
-would want to start over, you can recover with git-reset .
+
+If you tried a merge which resulted in a complex conflicts and
+would want to start over, you can recover with git-reset .
-CONFIGURATION
+CONFIGURATION
-
+
merge.stat
@@ -599,20 +647,20 @@ branch.<name>.mergeoptions
Sets default options for merging into branch <name>. The syntax and
- supported options are equal to that of git-merge , but option values
+ supported options are equal to that of git-merge , but option values
containing whitespace characters are currently not supported.
-
+
-HOW MERGE WORKS
+HOW MERGE WORKS
-
A merge is always between the current HEAD and one or more
+
A merge is always between the current HEAD and one or more
commits (usually, branch head or tag), and the index file must
exactly match the
tree of HEAD commit (i.e. the contents of the last commit) when
it happens. In other words, git diff --cached HEAD must
-report no changes.
+report no changes.
@@ -633,27 +681,27 @@ that path exactly in your index, the merge does not have to
fail.
-
Otherwise, merge will refuse to do any harm to your repository
+
Otherwise, merge will refuse to do any harm to your repository
(that is, it may fetch the objects from remote, and it may even
update the local branch used to keep track of the remote branch
with git pull remote rbranch:lbranch , but your working tree,
-.git/HEAD pointer and index file are left intact).
-
You may have local modifications in the working tree files. In
-other words, git-diff is allowed to report changes.
+.git/HEAD pointer and index file are left intact).
+
You may have local modifications in the working tree files. In
+other words, git-diff is allowed to report changes.
However, the merge uses your working tree as the working area,
and in order to prevent the merge operation from losing such
changes, it makes sure that they do not interfere with the
merge. Those complex tables in read-tree documentation define
what it means for a path to "interfere with the merge". And if
your local modifications interfere with the merge, again, it
-stops before touching anything.
-
So in the above two "failed merge" case, you do not have to
+stops before touching anything.
+
So in the above two "failed merge" case, you do not have to
worry about loss of data --- you simply were not ready to do
a merge, so no merge happened at all. You may want to finish
whatever you were in the middle of doing, and retry the same
-pull after you are done and ready.
-
When things cleanly merge, these things happen:
-
+pull after you are done and ready.
+
When things cleanly merge, these things happen:
+
The results are updated both in the index file and in your
@@ -675,8 +723,8 @@ The tree gets committed; and
The HEAD pointer gets advanced.
-
-
Because of 2., we require that the original state of the index
+
+
Because of 2., we require that the original state of the index
file to match exactly the current HEAD commit; otherwise we
will write out your local changes already registered in your
index file along with the merge result, which is not good.
@@ -684,9 +732,9 @@ Because 1. involves only the paths different between your
branch and the remote branch you are pulling from during the
merge (which is typically a fraction of the whole tree), you can
have local modifications in your working tree as long as they do
-not overlap with what the merge updates.
-
When there are conflicts, these things happen:
-
+not overlap with what the merge updates.
+
When there are conflicts, these things happen:
+
HEAD stays the same.
@@ -716,14 +764,14 @@ No other changes are done. In particular, the local
i.e. matching HEAD .
-
-
After seeing a conflict, you can do two things:
-
+
After seeing a conflict, you can do two things:
+
Decide not to merge. The only clean-up you need are to reset
the index file to the HEAD commit to reverse 2. and to clean
- up working tree changes made by 2. and 3.; git-reset can
+ up working tree changes made by 2. and 3.; git-reset can
be used for this.
@@ -731,37 +779,37 @@ Decide not to merge. The only clean-up you need are to reset
Resolve the conflicts. git diff would report only the
conflicting paths because of the above 2. and 3. Edit the
- working tree files into a desirable shape, git-add or git-rm
+ working tree files into a desirable shape, git-add or git-rm
them, to make the index file contain what the merge result
- should be, and run git-commit to commit the result.
+ should be, and run git-commit to commit the result.
-
+
-SEE ALSO
+SEE ALSO
-Author
+Author
-
Written by Junio C Hamano <junkio@cox.net>
+
Written by Junio C Hamano <junkio@cox.net>
-Documentation
+Documentation
-
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-merge.txt b/git-merge.txt
index e6fa2b9ae..62f99b5f3 100644
--- a/git-merge.txt
+++ b/git-merge.txt
@@ -29,8 +29,8 @@ include::merge-options.txt[]
-m ::
The commit message to be used for the merge commit (in case
- it is created). The `git-fmt-merge-msg` script can be used
- to give a good default for automated `git-merge` invocations.
+ it is created). The 'git-fmt-merge-msg' script can be used
+ to give a good default for automated 'git-merge' invocations.
::
Other branch head merged into our branch. You need at
@@ -41,7 +41,7 @@ include::merge-strategies.txt[]
If you tried a merge which resulted in a complex conflicts and
-would want to start over, you can recover with `git-reset`.
+would want to start over, you can recover with 'git-reset'.
CONFIGURATION
-------------
@@ -49,7 +49,7 @@ include::merge-config.txt[]
branch..mergeoptions::
Sets default options for merging into branch . The syntax and
- supported options are equal to that of `git-merge`, but option values
+ supported options are equal to that of 'git-merge', but option values
containing whitespace characters are currently not supported.
HOW MERGE WORKS
@@ -84,7 +84,7 @@ with `git pull remote rbranch:lbranch`, but your working tree,
`.git/HEAD` pointer and index file are left intact).
You may have local modifications in the working tree files. In
-other words, `git-diff` is allowed to report changes.
+other words, 'git-diff' is allowed to report changes.
However, the merge uses your working tree as the working area,
and in order to prevent the merge operation from losing such
changes, it makes sure that they do not interfere with the
@@ -140,14 +140,14 @@ After seeing a conflict, you can do two things:
* Decide not to merge. The only clean-up you need are to reset
the index file to the `HEAD` commit to reverse 2. and to clean
- up working tree changes made by 2. and 3.; `git-reset` can
+ up working tree changes made by 2. and 3.; 'git-reset' can
be used for this.
* Resolve the conflicts. `git diff` would report only the
conflicting paths because of the above 2. and 3. Edit the
- working tree files into a desirable shape, `git-add` or `git-rm`
+ working tree files into a desirable shape, 'git-add' or 'git-rm'
them, to make the index file contain what the merge result
- should be, and run `git-commit` to commit the result.
+ should be, and run 'git-commit' to commit the result.
SEE ALSO
diff --git a/git-mergetool.html b/git-mergetool.html
index fa1727feb..0c7b646eb 100644
--- a/git-mergetool.html
+++ b/git-mergetool.html
@@ -3,7 +3,7 @@
-
+
git-mergetool(1)
@@ -272,20 +320,20 @@ git-mergetool(1) Manual Page
SYNOPSIS
-
git mergetool [--tool=<tool>] [<file>]…
+
git mergetool [--tool=<tool>] [<file>]…
-DESCRIPTION
+DESCRIPTION
-
Use git mergetool to run one of several merge utilities to resolve
-merge conflicts. It is typically run after git-merge .
-
If one or more <file> parameters are given, the merge tool program will
+
Use git mergetool to run one of several merge utilities to resolve
+merge conflicts. It is typically run after git-merge .
+
If one or more <file> parameters are given, the merge tool program will
be run to resolve differences on each file. If no <file> names are
-specified, git-mergetool will run the merge tool program on every file
-with merge conflicts.
+specified,
git-mergetool will run the merge tool program on every file
+with merge conflicts.
-OPTIONS
+OPTIONS
-
+
-t or --tool=<tool>
@@ -295,20 +343,20 @@ with merge conflicts.
Valid merge tools are:
kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge, and opendiff
-If a merge resolution program is not specified, git-mergetool
+
If a merge resolution program is not specified, git-mergetool
will use the configuration variable merge.tool . If the
-configuration variable merge.tool is not set, git-mergetool
-will pick a suitable default.
-
You can explicitly provide a full path to the tool by setting the
+configuration variable merge.tool is not set, git-mergetool
+will pick a suitable default.
+You can explicitly provide a full path to the tool by setting the
configuration variable mergetool.<tool>.path . For example, you
can configure the absolute path to kdiff3 by setting
-mergetool.kdiff3.path . Otherwise, git-mergetool assumes the
-tool is available in PATH.
-
Instead of running one of the known merge tool programs
-git-mergetool can be customized to run an alternative program
+mergetool.kdiff3.path . Otherwise, git-mergetool assumes the
+tool is available in PATH.
+Instead of running one of the known merge tool programs
+git-mergetool can be customized to run an alternative program
by specifying the command line to invoke in a configration
-variable mergetool.<tool>.cmd .
-
When git-mergetool is invoked with this tool (either through the
+variable mergetool.<tool>.cmd .
+When git-mergetool is invoked with this tool (either through the
-t or --tool option or the merge.tool configuration
variable) the configured command line will be invoked with $BASE
set to the name of a temporary file containing the common base for
@@ -317,30 +365,30 @@ file containing the contents of the file on the current branch;
$REMOTE set to the name of a temporary file containing the
contents of the file to be merged, and $MERGED set to the name
of the file to which the merge tool should write the result of the
-merge resolution.
-
If the custom merge tool correctly indicates the success of a
+merge resolution.
+If the custom merge tool correctly indicates the success of a
merge resolution with its exit code then the configuration
variable mergetool.<tool>.trustExitCode can be set to true .
-Otherwise, git-mergetool will prompt the user to indicate the
-success of the resolution after the custom tool has exited.
+Otherwise,
git-mergetool will prompt the user to indicate the
+success of the resolution after the custom tool has exited.
-
+
-Author
+Author
-
Written by Theodore Y Ts'o <tytso@mit.edu>
+
Written by Theodore Y Ts'o <tytso@mit.edu>
-Documentation
+Documentation
-
Documentation by Theodore Y Ts'o.
+
Documentation by Theodore Y Ts'o.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-mergetool.txt b/git-mergetool.txt
index fedcfa054..31570b1e2 100644
--- a/git-mergetool.txt
+++ b/git-mergetool.txt
@@ -13,11 +13,11 @@ DESCRIPTION
-----------
Use `git mergetool` to run one of several merge utilities to resolve
-merge conflicts. It is typically run after `git-merge`.
+merge conflicts. It is typically run after 'git-merge'.
If one or more parameters are given, the merge tool program will
be run to resolve differences on each file. If no names are
-specified, `git-mergetool` will run the merge tool program on every file
+specified, 'git-mergetool' will run the merge tool program on every file
with merge conflicts.
OPTIONS
@@ -27,23 +27,23 @@ OPTIONS
Valid merge tools are:
kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge, and opendiff
+
-If a merge resolution program is not specified, `git-mergetool`
+If a merge resolution program is not specified, 'git-mergetool'
will use the configuration variable `merge.tool`. If the
-configuration variable `merge.tool` is not set, `git-mergetool`
+configuration variable `merge.tool` is not set, 'git-mergetool'
will pick a suitable default.
+
You can explicitly provide a full path to the tool by setting the
configuration variable `mergetool..path`. For example, you
can configure the absolute path to kdiff3 by setting
-`mergetool.kdiff3.path`. Otherwise, `git-mergetool` assumes the
+`mergetool.kdiff3.path`. Otherwise, 'git-mergetool' assumes the
tool is available in PATH.
+
Instead of running one of the known merge tool programs
-`git-mergetool` can be customized to run an alternative program
+'git-mergetool' can be customized to run an alternative program
by specifying the command line to invoke in a configration
variable `mergetool..cmd`.
+
-When `git-mergetool` is invoked with this tool (either through the
+When 'git-mergetool' is invoked with this tool (either through the
`-t` or `--tool` option or the `merge.tool` configuration
variable) the configured command line will be invoked with `$BASE`
set to the name of a temporary file containing the common base for
@@ -57,7 +57,7 @@ merge resolution.
If the custom merge tool correctly indicates the success of a
merge resolution with its exit code then the configuration
variable `mergetool..trustExitCode` can be set to `true`.
-Otherwise, `git-mergetool` will prompt the user to indicate the
+Otherwise, 'git-mergetool' will prompt the user to indicate the
success of the resolution after the custom tool has exited.
Author
diff --git a/git-name-rev.html b/git-name-rev.html
index b7ea7adb3..456e87cae 100644
--- a/git-name-rev.html
+++ b/git-name-rev.html
@@ -3,7 +3,7 @@
-
+
git-name-rev(1)
@@ -276,14 +324,14 @@ git-name-rev(1) Manual Page
git name-rev [--tags] [--refs=<pattern>]
( --all | --stdin | <committish>… )
-DESCRIPTION
+DESCRIPTION
-
Finds symbolic names suitable for human digestion for revisions given in any
-format parsable by git-rev-parse .
+
Finds symbolic names suitable for human digestion for revisions given in any
+format parsable by git-rev-parse .
-OPTIONS
+OPTIONS
-
+
--tags
@@ -325,7 +373,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 omitted from the name, matching the output
- of git-describe more closely. This option
+ of git-describe more closely. This option
cannot be combined with --stdin.
@@ -346,42 +394,42 @@ format parsable by git-rev-parse .
Show uniquely abbreviated commit object as fallback.
-
+
-EXAMPLE
+EXAMPLE
-
Given a commit, find out where it is relative to the local refs. Say somebody
+
Given a commit, find out where it is relative to the local refs. Say somebody
wrote you about that fantastic commit 33db5f4d9027a10e477ccf054b2c1ab94f74c85a.
Of course, you look into the commit, but that only tells you what happened, but
-not the context.
-
Enter git-name-rev :
+not the context.
+
% git name-rev 33db5f4d9027a10e477ccf054b2c1ab94f74c85a
33db5f4d9027a10e477ccf054b2c1ab94f74c85a tags/v0.99^0~940
-
Now you are wiser, because you know that it happened 940 revisions before v0.99.
-
Another nice thing you can do is:
+
Now you are wiser, because you know that it happened 940 revisions before v0.99.
+
Another nice thing you can do is:
% git log | git name-rev --stdin
-Author
+Author
-
Written by Johannes Schindelin <Johannes.Schindelin@gmx.de>
+
Written by Johannes Schindelin <Johannes.Schindelin@gmx.de>
-Documentation
+Documentation
-
Documentation by Johannes Schindelin.
+
Documentation by Johannes Schindelin.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-name-rev.txt b/git-name-rev.txt
index 00b1fa4dc..6e77ab135 100644
--- a/git-name-rev.txt
+++ b/git-name-rev.txt
@@ -15,7 +15,7 @@ SYNOPSIS
DESCRIPTION
-----------
Finds symbolic names suitable for human digestion for revisions given in any
-format parsable by `git-rev-parse`.
+format parsable by 'git-rev-parse'.
OPTIONS
@@ -38,7 +38,7 @@ OPTIONS
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 omitted from the name, matching the output
- of `git-describe` more closely. This option
+ of 'git-describe' more closely. This option
cannot be combined with --stdin.
--no-undefined::
@@ -56,7 +56,7 @@ wrote you about that fantastic commit 33db5f4d9027a10e477ccf054b2c1ab94f74c85a.
Of course, you look into the commit, but that only tells you what happened, but
not the context.
-Enter `git-name-rev`:
+Enter 'git-name-rev':
------------
% git name-rev 33db5f4d9027a10e477ccf054b2c1ab94f74c85a
diff --git a/git-pack-objects.html b/git-pack-objects.html
index b90d2766f..fa262410c 100644
--- a/git-pack-objects.html
+++ b/git-pack-objects.html
@@ -3,7 +3,7 @@
-
+
git-pack-objects(1)
@@ -277,31 +325,31 @@ git-pack-objects(1) Manual Page
[--local] [--incremental] [--window=N] [--depth=N] [--all-progress]
[--revs [--unpacked | --all]*] [--stdout | base-name] < object-list
-DESCRIPTION
+DESCRIPTION
-
Reads list of objects from the standard input, and writes a packed
-archive with specified base-name, or to the standard output.
-
A packed archive is an efficient way to transfer set of objects
+
Reads list of objects from the standard input, and writes a packed
+archive with specified base-name, or to the standard output.
+
A packed archive is an efficient way to transfer set of objects
between two repositories, and also is an archival format which
is efficient to access. The packed archive format (.pack) is
designed to be self contained so that it can be unpacked without
any further information, but for fast, random access to the objects
-in the pack, a pack index file (.idx) will be generated.
-
Placing both in the pack/ subdirectory of $GIT_OBJECT_DIRECTORY (or
+in the pack, a pack index file (.idx) will be generated.
+
Placing both in the pack/ subdirectory of $GIT_OBJECT_DIRECTORY (or
any of the directories on $GIT_ALTERNATE_OBJECT_DIRECTORIES)
-enables git to read from such an archive.
-
The git-unpack-objects command can read the packed archive and
+enables git to read from such an archive.
+
The git-unpack-objects command can read the packed archive and
expand the objects contained in the pack into "one-file
one-object" format; this is typically done by the smart-pull
commands when a pack is created on-the-fly for efficient network
-transport by their peers.
-
In a packed archive, an object is either stored as a compressed
+transport by their peers.
+
In a packed archive, an object is either stored as a compressed
whole, or as a difference from some other object. The latter is
-often called a delta.
+often called a delta.
-OPTIONS
+OPTIONS
-
+
base-name
@@ -332,7 +380,7 @@ base-name
Read the revision arguments from the standard input, instead of
individual object names. The revision arguments are processed
- the same way as git-rev-list with the --objects flag
+ the same way as git-rev-list with the --objects flag
uses its commit arguments to build the list of objects it
outputs. The objects on the resulting list are packed.
@@ -525,7 +573,7 @@ base-name
A packed archive can express base object of a delta as
either 20-byte object name or as an offset in the
stream, but older version of git does not understand the
- latter. By default, git-pack-objects only uses the
+ latter. By default, git-pack-objects only uses the
former format for better compatibility. This option
allows the command to use the latter format for
compactness. Depending on the average delta chain
@@ -558,29 +606,29 @@ base-name
64-bit index entries on objects located above the given offset.
-
+
-Author
+Author
-
Written by Linus Torvalds <torvalds@osdl.org>
+
Written by Linus Torvalds <torvalds@osdl.org>
-Documentation
+Documentation
-
Documentation by Junio C Hamano
+
Documentation by Junio C Hamano
-SEE ALSO
+SEE ALSO
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-pack-objects.txt b/git-pack-objects.txt
index d9cd16ae1..8c354bd47 100644
--- a/git-pack-objects.txt
+++ b/git-pack-objects.txt
@@ -30,7 +30,7 @@ Placing both in the pack/ subdirectory of $GIT_OBJECT_DIRECTORY (or
any of the directories on $GIT_ALTERNATE_OBJECT_DIRECTORIES)
enables git to read from such an archive.
-The `git-unpack-objects` command can read the packed archive and
+The 'git-unpack-objects' command can read the packed archive and
expand the objects contained in the pack into "one-file
one-object" format; this is typically done by the smart-pull
commands when a pack is created on-the-fly for efficient network
@@ -59,7 +59,7 @@ base-name::
--revs::
Read the revision arguments from the standard input, instead of
individual object names. The revision arguments are processed
- the same way as `git-rev-list` with the `--objects` flag
+ the same way as 'git-rev-list' with the `--objects` flag
uses its `commit` arguments to build the list of objects it
outputs. The objects on the resulting list are packed.
@@ -170,7 +170,7 @@ base-name::
A packed archive can express base object of a delta as
either 20-byte object name or as an offset in the
stream, but older version of git does not understand the
- latter. By default, `git-pack-objects` only uses the
+ latter. By default, 'git-pack-objects' only uses the
former format for better compatibility. This option
allows the command to use the latter format for
compactness. Depending on the average delta chain
diff --git a/git-pack-redundant.html b/git-pack-redundant.html
index da6507b05..e92e065bd 100644
--- a/git-pack-redundant.html
+++ b/git-pack-redundant.html
@@ -3,7 +3,7 @@
-
+
git-pack-redundant(1)
@@ -272,22 +320,22 @@ git-pack-redundant(1) Manual Page
SYNOPSIS
-
git pack-redundant [ --verbose ] [ --alt-odb ] < --all | .pack filename … >
+
git pack-redundant [ --verbose ] [ --alt-odb ] < --all | .pack filename … >
-DESCRIPTION
+DESCRIPTION
-
This program computes which packs in your repository
+
This program computes which packs in your repository
are redundant. The output is suitable for piping to
-xargs rm if you are in the root of the repository.
-
git-pack-redundant accepts a list of objects on standard input. Any objects
+xargs rm if you are in the root of the repository.
+
git-pack-redundant accepts a list of objects on standard input. Any objects
given will be ignored when checking which packs are required. This makes the
following command useful when wanting to remove packs which contain unreachable
-objects.
-
git fsck --full --unreachable | cut -d -f3 | git pack-redundant --all | xargs rm
+objects.
+
git fsck --full --unreachable | cut -d -f3 | git pack-redundant --all | xargs rm
-OPTIONS
+OPTIONS
-
+
--all
@@ -313,29 +361,29 @@ objects.
Outputs some statistics to stderr. Has a small performance penalty.
-
+
-Author
+Author
-
Written by Lukas Sandström <lukass@etek.chalmers.se>
+
Written by Lukas Sandström <lukass@etek.chalmers.se>
-Documentation
+Documentation
-
Documentation by Lukas Sandström <lukass@etek.chalmers.se>
+
Documentation by Lukas Sandström <lukass@etek.chalmers.se>
-SEE ALSO
+SEE ALSO
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-pack-redundant.txt b/git-pack-redundant.txt
index 80fc1bae3..5f9435e59 100644
--- a/git-pack-redundant.txt
+++ b/git-pack-redundant.txt
@@ -16,7 +16,7 @@ This program computes which packs in your repository
are redundant. The output is suitable for piping to
`xargs rm` if you are in the root of the repository.
-`git-pack-redundant` accepts a list of objects on standard input. Any objects
+'git-pack-redundant' accepts a list of objects on standard input. Any objects
given will be ignored when checking which packs are required. This makes the
following command useful when wanting to remove packs which contain unreachable
objects.
diff --git a/git-parse-remote.html b/git-parse-remote.html
index eed90d69b..6cededeec 100644
--- a/git-parse-remote.html
+++ b/git-parse-remote.html
@@ -3,7 +3,7 @@
-
+
git-parse-remote(1)
@@ -272,16 +320,16 @@ git-parse-remote(1) Manual Page
SYNOPSIS
-
. "$(git --exec-path)/git-parse-remote"
+
. "$(git --exec-path)/git-parse-remote"
-DESCRIPTION
+DESCRIPTION
-
This script is included in various scripts to supply
+
This script is included in various scripts to supply
routines to parse files under $GIT_DIR/remotes/ and
$GIT_DIR/branches/ and configuration variables that are related
-to fetching, pulling and pushing.
-
The primary entry points are:
-
+to fetching, pulling and pushing.
+
The primary entry points are:
+
get_remote_refs_for_fetch
@@ -304,29 +352,29 @@ get_remote_refs_for_push
Given the list of user-supplied <repo> <refspec>… ,
return the list of refs to push in a form suitable to be
- fed to the git-send-pack command. When <refspec>…
+ fed to the git-send-pack command. When <refspec>…
is empty the returned list of refs consists of the
defaults for the given <repo> , if specified in
$GIT_DIR/remotes/ .
-
+
-Author
+Author
-
Written by Junio C Hamano.
+
Written by Junio C Hamano.
-Documentation
+Documentation
-
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-parse-remote.txt b/git-parse-remote.txt
index 421312eca..cd4306987 100644
--- a/git-parse-remote.txt
+++ b/git-parse-remote.txt
@@ -32,7 +32,7 @@ get_remote_refs_for_fetch::
get_remote_refs_for_push::
Given the list of user-supplied ` ...`,
return the list of refs to push in a form suitable to be
- fed to the `git-send-pack` command. When `...`
+ fed to the 'git-send-pack' command. When `...`
is empty the returned list of refs consists of the
defaults for the given ``, if specified in
`$GIT_DIR/remotes/`.
diff --git a/git-patch-id.html b/git-patch-id.html
index 0e4645c81..09916be9d 100644
--- a/git-patch-id.html
+++ b/git-patch-id.html
@@ -3,7 +3,7 @@
-
+
git-patch-id(1)
@@ -272,24 +320,24 @@ git-patch-id(1) Manual Page
SYNOPSIS
-
git patch-id < <patch>
+
-DESCRIPTION
+DESCRIPTION
-
A "patch ID" is nothing but a SHA1 of the diff associated with a patch, with
+
A "patch ID" is nothing but a SHA1 of the diff associated with a patch, with
whitespace and line numbers ignored. As such, it's "reasonably stable", but at
the same time also reasonably unique, i.e., two patches that have the same "patch
-ID" are almost guaranteed to be the same thing.
-
IOW, you can use this thing to look for likely duplicate commits.
-
When dealing with git-diff-tree output, it takes advantage of
+ID" are almost guaranteed to be the same thing.
+
IOW, you can use this thing to look for likely duplicate commits.
+
When dealing with git-diff-tree output, it takes advantage of
the fact that the patch is prefixed with the object name of the
commit, and outputs two 40-byte hexadecimal string. The first
string is the patch ID, and the second string is the commit ID.
-This can be used to make a mapping from patch ID to commit ID.
+This can be used to make a mapping from patch ID to commit ID.
-OPTIONS
+OPTIONS
-
+
<patch>
@@ -298,23 +346,23 @@ This can be used to make a mapping from patch ID to commit ID.
The diff to create the ID of.
-
+
-Author
+Author
-
Written by Linus Torvalds <torvalds@osdl.org>
+
Written by Linus Torvalds <torvalds@osdl.org>
-Documentation
+Documentation
-
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-patch-id.txt b/git-patch-id.txt
index 17c178f86..477785e13 100644
--- a/git-patch-id.txt
+++ b/git-patch-id.txt
@@ -18,7 +18,7 @@ ID" are almost guaranteed to be the same thing.
IOW, you can use this thing to look for likely duplicate commits.
-When dealing with `git-diff-tree` output, it takes advantage of
+When dealing with 'git-diff-tree' output, it takes advantage of
the fact that the patch is prefixed with the object name of the
commit, and outputs two 40-byte hexadecimal string. The first
string is the patch ID, and the second string is the commit ID.
diff --git a/git-peek-remote.html b/git-peek-remote.html
index 06d601607..7abfb68cc 100644
--- a/git-peek-remote.html
+++ b/git-peek-remote.html
@@ -3,7 +3,7 @@
-
+
git-peek-remote(1)
@@ -272,21 +320,21 @@ git-peek-remote(1) Manual Page
SYNOPSIS
-
git peek-remote [--upload-pack=<git-upload-pack>] [<host>:]<directory>
+
git peek-remote [--upload-pack=<git-upload-pack>] [<host>:]<directory>
-DESCRIPTION
+DESCRIPTION
-
This command is deprecated; use git-ls-remote instead.
+
This command is deprecated; use git-ls-remote instead.
-OPTIONS
+OPTIONS
-
+
--upload-pack=<git-upload-pack>
- Use this to specify the path to git-upload-pack on the
+ Use this to specify the path to git-upload-pack on the
remote side, if it is not found on your $PATH. Some
installations of sshd ignores the user's environment
setup scripts for login shells (e.g. .bash_profile) and
@@ -304,7 +352,7 @@ git-peek-remote(1) Manual Page
A remote host that houses the repository. When this
- part is specified, git-upload-pack is invoked via
+ part is specified, git-upload-pack is invoked via
ssh.
@@ -316,23 +364,23 @@ git-peek-remote(1) Manual Page
The repository to sync from.
-
+
-Author
+Author
-
Written by Junio C Hamano <junkio@cox.net>
+
Written by Junio C Hamano <junkio@cox.net>
-Documentation
+Documentation
-
Documentation by Junio C Hamano.
+
Documentation by Junio C Hamano.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-peek-remote.txt b/git-peek-remote.txt
index c3ed4a10f..79c03ee7f 100644
--- a/git-peek-remote.txt
+++ b/git-peek-remote.txt
@@ -12,12 +12,12 @@ SYNOPSIS
DESCRIPTION
-----------
-This command is deprecated; use `git-ls-remote` instead.
+This command is deprecated; use 'git-ls-remote' instead.
OPTIONS
-------
--upload-pack=::
- Use this to specify the path to `git-upload-pack` on the
+ Use this to specify the path to 'git-upload-pack' on the
remote side, if it is not found on your $PATH. Some
installations of sshd ignores the user's environment
setup scripts for login shells (e.g. .bash_profile) and
@@ -30,7 +30,7 @@ OPTIONS
::
A remote host that houses the repository. When this
- part is specified, `git-upload-pack` is invoked via
+ part is specified, 'git-upload-pack' is invoked via
ssh.
::
diff --git a/git-prune.html b/git-prune.html
index e6bc772c3..28bd8a123 100644
--- a/git-prune.html
+++ b/git-prune.html
@@ -3,7 +3,7 @@
-
+
git-prune(1)
@@ -272,32 +320,32 @@ git-prune(1) Manual Page
SYNOPSIS
-
git-prune [-n] [--expire <expire>] [--] [<head>…]
+
git-prune [-n] [--expire <expire>] [--] [<head>…]
-DESCRIPTION
+DESCRIPTION
Note
-In most cases, users should run git-gc , which calls
-git-prune . See the section "NOTES", below.
+In most cases, users should run git-gc , which calls
+git-prune . See the section "NOTES", below.
-
This runs git-fsck --unreachable using all the refs
+
This runs git-fsck --unreachable using all the refs
available in $GIT_DIR/refs , optionally with additional set of
objects specified on the command line, and prunes all unpacked
objects unreachable from any of these head objects from the object database.
In addition, it
prunes the unpacked objects that are also found in packs by
-running git-prune-packed .
-
Note that unreachable, packed objects will remain. If this is
-not desired, see git-repack(1) .
+running
git-prune-packed .
+
Note that unreachable, packed objects will remain. If this is
+not desired, see git-repack(1) .
-OPTIONS
+OPTIONS
-
+
-n
@@ -333,47 +381,47 @@ not desired, see git-repack(1) .
reachable from listed <head>s.
-
+
-EXAMPLE
+EXAMPLE
-
To prune objects not used by your repository nor another that
+
To prune objects not used by your repository nor another that
borrows from your repository via its
-.git/objects/info/alternates :
+
.git/objects/info/alternates :
$ git prune $(cd ../another && $(git rev-parse --all))
-Notes
+Notes
-
In most cases, users will not need to call git-prune directly, but
-should instead call git-gc , which handles pruning along with
-many other housekeeping tasks.
-
For a description of which objects are considered for pruning, see
-git-fsck 's --unreachable option.
+
In most cases, users will not need to call git-prune directly, but
+should instead call git-gc , which handles pruning along with
+many other housekeeping tasks.
+
For a description of which objects are considered for pruning, see
+git-fsck 's --unreachable option.
-SEE ALSO
+SEE ALSO
-Author
+Author
-
Written by Linus Torvalds <torvalds@osdl.org>
+
Written by Linus Torvalds <torvalds@osdl.org>
-Documentation
+Documentation
-
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-prune.txt b/git-prune.txt
index a4a0d56ca..54f1dab38 100644
--- a/git-prune.txt
+++ b/git-prune.txt
@@ -13,16 +13,16 @@ SYNOPSIS
DESCRIPTION
-----------
-NOTE: In most cases, users should run `git-gc`, which calls
-`git-prune`. See the section "NOTES", below.
+NOTE: In most cases, users should run 'git-gc', which calls
+'git-prune'. See the section "NOTES", below.
-This runs `git-fsck --unreachable` using all the refs
+This runs 'git-fsck --unreachable' using all the refs
available in `$GIT_DIR/refs`, optionally with additional set of
objects specified on the command line, and prunes all unpacked
objects unreachable from any of these head objects from the object database.
In addition, it
prunes the unpacked objects that are also found in packs by
-running `git-prune-packed`.
+running 'git-prune-packed'.
Note that unreachable, packed objects will remain. If this is
not desired, see linkgit:git-repack[1].
@@ -59,12 +59,12 @@ $ git prune $(cd ../another && $(git rev-parse --all))
Notes
-----
-In most cases, users will not need to call `git-prune` directly, but
-should instead call `git-gc`, which handles pruning along with
+In most cases, users will not need to call 'git-prune' directly, but
+should instead call 'git-gc', which handles pruning along with
many other housekeeping tasks.
For a description of which objects are considered for pruning, see
-`git-fsck`'s --unreachable option.
+'git-fsck''s --unreachable option.
SEE ALSO
--------
diff --git a/git-pull.html b/git-pull.html
index 61be7a31e..e4538cdc0 100644
--- a/git-pull.html
+++ b/git-pull.html
@@ -3,7 +3,7 @@
-
+
git-pull(1)
@@ -272,22 +320,22 @@ git-pull(1) Manual Page
SYNOPSIS
-
git pull <options> <repository> <refspec>…
+
git pull <options> <repository> <refspec>…
-DESCRIPTION
+DESCRIPTION
-
Runs git-fetch with the given parameters, and calls git-merge
+
Runs git-fetch with the given parameters, and calls git-merge
to merge the retrieved head(s) into the current branch.
-With --rebase , calls git-rebase instead of git-merge .
-
Note that you can use . (current directory) as the
+With --rebase , calls git-rebase instead of git-merge .
+
Note that you can use . (current directory) as the
<repository> to pull from the local repository — this is useful
-when merging local branches into the current branch.
-
Also note that options meant for git-pull itself and underlying
-git-merge must be given before the options meant for git-fetch .
+when merging local branches into the current branch.
+
Also note that options meant for git-pull itself and underlying
+git-merge must be given before the options meant for git-fetch .
-OPTIONS
+OPTIONS
-
+
--stat
@@ -411,12 +459,12 @@ when merging local branches into the current branch.
Use the given merge strategy; can be supplied more than
once to specify them in the order they should be tried.
If there is no -s option, a built-in list of strategies
- is used instead (git-merge-recursive when merging a single
- head, git-merge-octopus otherwise).
+ is used instead (git-merge-recursive when merging a single
+ head, git-merge-octopus otherwise).
-
-
+
+
--rebase
@@ -434,7 +482,7 @@ when merging local branches into the current branch.
Note
-This is a potentially _dangerous_ mode of operation.
+ This is a potentially dangerous mode of operation.
It rewrites history, which does not bode well when you
published that history already. Do not use this option
unless you have read git-rebase(1) carefully.
@@ -504,7 +552,7 @@ unless you have read git-rebase(1) carefully.
- When git-fetch is used with <rbranch>:<lbranch>
+ When git-fetch is used with <rbranch>:<lbranch>
refspec, it refuses to update the local branch
<lbranch> unless the remote branch <rbranch> it
fetches is a descendant of <lbranch> . This option
@@ -556,10 +604,10 @@ unless you have read git-rebase(1) carefully.
- By default git-fetch refuses to update the head which
+ By default git-fetch refuses to update the head which
corresponds to the current branch. This flag disables the
- check. This is purely for the internal use for git-pull
- to communicate with git-fetch , and unless you are
+ check. This is purely for the internal use for git-pull
+ to communicate with git-fetch , and unless you are
implementing your own Porcelain you are not supposed to
use it.
@@ -591,16 +639,16 @@ 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.
-The remote ref that matches <src>
+
The remote ref that matches <src>
is fetched, and if <dst> is not empty string, the local
ref that matches it is fast forwarded using <src>.
Again, if the optional plus + is used, the local ref
is updated even if it does not result in a fast forward
-update.
+update.
@@ -625,7 +673,7 @@ must know this is the expected usage pattern for a branch.
You never do your own development on branches that appear
on the right hand side of a <refspec> colon on Pull: lines;
-they are to be updated by git-fetch . If you intend to do
+they are to be updated by git-fetch . If you intend to do
development derived from a remote branch B , have a Pull:
line to track it (i.e. Pull: B:remote-B ), and have a separate
branch my-B to do your development on top of it. The latter
@@ -642,13 +690,13 @@ on the remote branch, merge it into your development branch with
Note
There is a difference between listing multiple <refspec>
-directly on git-pull command line and having multiple
+directly on git-pull command line and having multiple
Pull: <refspec> lines for a <repository> and running
-git-pull command without any explicit <refspec> parameters.
+git-pull command without any explicit <refspec> parameters.
<refspec> listed explicitly on the command line are always
merged into the current branch after fetching. In other words,
if you list more than one remote refs, you would be making
-an Octopus. While git-pull run without any explicit <refspec>
+an Octopus. While git-pull run without any explicit <refspec>
parameter takes default <refspec>s from Pull: lines, it
merges only the first <refspec> found into the current branch,
after fetching all the remote refs. This is because making an
@@ -657,8 +705,8 @@ of multiple remote heads in one-go by fetching more than one
is often useful.
-Some short-cut notations are also supported.
-
-
+
-GIT URLS
+GIT URLS
-
One of the following notations can be used
-to name the remote repository:
+
One of the following notations can be used
+to name the remote repository:
-
SSH is the default transport protocol over the network. You can
+
SSH is the default transport protocol over the network. You can
optionally specify which user to log-in as, and an alternate,
scp-like syntax is also supported. Both syntaxes support
username expansion, as does the native git protocol, but
only the former supports port specification. The following
-three are identical to the last three above, respectively:
+three are identical to the last three above, respectively:
-
+
[user@]host.xz:/path/to/repo.git/
@@ -754,12 +802,12 @@ three are identical to the last three above, respectively:
[user@]host.xz:path/to/repo.git
-
+
-
To sync with a local directory, you can use:
+
To sync with a local directory, you can use:
-
They are mostly equivalent, except when cloning. See
-git-clone(1) for details.
-
If there are a large number of similarly-named remote repositories and
+
They are mostly equivalent, except when cloning. See
+git-clone(1) for details.
+
If there are a large number of similarly-named remote repositories and
you want to use a different format for them (such that the URLs you
use will be rewritten into URLs that work), you can create a
-configuration section of the form:
+configuration section of the form:
[url "<actual url base>"]
insteadOf = <other url base>
-
For example, with this:
+
[url "git://git.host.xz/"]
insteadOf = host.xz:/path/to/
insteadOf = work:
-
a URL like "work:repo.git" or like "host.xz:/path/to/repo.git" will be
-rewritten in any context that takes a URL to be "git://git.host.xz/repo.git".
+
a URL like "work:repo.git" or like "host.xz:/path/to/repo.git" will be
+rewritten in any context that takes a URL to be "git://git.host.xz/repo.git".
-REMOTES
+REMOTES
-
The name of one of the following can be used instead
-of a URL as <repository> argument:
-
+The name of one of the following can be used instead
+of a URL as <repository> argument:
+
a remote in the git configuration file: $GIT_DIR/config ,
@@ -813,17 +861,17 @@ a file in the $GIT_DIR/remotes directory, or
a file in the $GIT_DIR/branches directory.
-
-
All of these also allow you to omit the refspec from the command line
-because they each contain a refspec which git will use by default.
-
Named remote in configuration file
-
You can choose to provide the name of a remote which you had previously
+
+All of these also allow you to omit the refspec from the command line
+because they each contain a refspec which git will use by default.
+Named remote in configuration file
+You can choose to provide the name of a remote which you had previously
configured using git-remote(1) , git-config(1)
or even by a manual edit to the $GIT_DIR/config file. The URL of
this remote will be used to access the repository. The refspec
of this remote will be used by default when you do
not provide a refspec on the command line. The entry in the
-config file would appear like this:
+config file would appear like this:
[remote "<name>"]
@@ -831,13 +879,13 @@ config file would appear like this:
push = <refspec>
fetch = <refspec>
-Named file in $GIT_DIR/remotes
-You can choose to provide the name of a
+
Named file in $GIT_DIR/remotes
+You can choose to provide the name of a
file in $GIT_DIR/remotes . The URL
in this file will be used to access the repository. The refspec
in this file will be used as default when you do not
provide a refspec on the command line. This file should have the
-following format:
+following format:
URL: one of the above URL format
@@ -845,32 +893,32 @@ following format:
Pull: <refspec>
-Push: lines are used by git-push and
-Pull: lines are used by git-pull and git-fetch .
+
Push: lines are used by git-push and
+Pull: lines are used by git-pull and git-fetch .
Multiple Push: and Pull: lines may
-be specified for additional branch mappings.
-
Named file in $GIT_DIR/branches
-
You can choose to provide the name of a
+be specified for additional branch mappings.
+Named file in $GIT_DIR/branches
+You can choose to provide the name of a
file in $GIT_DIR/branches .
The URL in this file will be used to access the repository.
-This file should have the following format:
+This file should have the following format:
-<url> is required; #<head> is optional.
+
<url> is required; #<head> is optional.
When you do not provide a refspec on the command line,
git will use the following refspec, where <head> defaults to master ,
and <repository> is the name of this file
-you provided in the command line.
+you provided in the command line.
refs/heads/<head>:<repository>
-MERGE STRATEGIES
+MERGE STRATEGIES
-
+
resolve
@@ -936,46 +984,46 @@ subtree
ancestor tree.
-
+
-DEFAULT BEHAVIOUR
+DEFAULT BEHAVIOUR
-
Often people use git pull without giving any parameter.
+
Often people use git pull without giving any parameter.
Traditionally, this has been equivalent to saying git pull
origin . However, when configuration branch.<name>.remote is
present while on branch <name> , that value is used instead of
-origin .
-
In order to determine what URL to use to fetch from, the value
+origin .
+
In order to determine what URL to use to fetch from, the value
of the configuration remote.<origin>.url is consulted
and if there is not any such variable, the value on URL: line
-in $GIT_DIR/remotes/<origin> file is used.
-
In order to determine what remote branches to fetch (and
+in $GIT_DIR/remotes/<origin> file is used.
+
In order to determine what remote branches to fetch (and
optionally store in the tracking branches) when the command is
run without any refspec parameters on the command line, values
of the configuration variable remote.<origin>.fetch are
consulted, and if there aren't any, $GIT_DIR/remotes/<origin>
file is consulted and its Pull: lines are used.
In addition to the refspec formats described in the OPTIONS
-section, you can have a globbing refspec that looks like this:
+section, you can have a globbing refspec that looks like this:
refs/heads/*:refs/remotes/origin/*
-
A globbing refspec must have a non-empty RHS (i.e. must store
+
A globbing refspec must have a non-empty RHS (i.e. must store
what were fetched in tracking branches), and its LHS and RHS
must end with /* . The above specifies that all remote
branches are tracked using tracking branches in
-refs/remotes/origin/ hierarchy under the same name.
-
The rule to determine which remote branch to merge after
+refs/remotes/origin/ hierarchy under the same name.
+
The rule to determine which remote branch to merge after
fetching is a bit involved, in order not to break backward
-compatibility.
-
If explicit refspecs were given on the command
-line of git pull , they are all merged.
-
When no refspec was given on the command line, then git pull
+compatibility.
+
If explicit refspecs were given on the command
+line of git pull , they are all merged.
+
When no refspec was given on the command line, then git pull
uses the refspec from the configuration or
$GIT_DIR/remotes/<origin> . In such cases, the following
-rules apply:
-
+rules apply:
+
If branch.<name>.merge configuration for the current
@@ -993,11 +1041,11 @@ If the refspec is a globbing one, nothing is merged.
Otherwise the remote branch of the first refspec is merged.
-
+
-EXAMPLES
+EXAMPLES
-
+
-Normally the branch merged in is the HEAD of the remote repository,
+
Normally the branch merged in is the HEAD of the remote repository,
but the choice is determined by the branch.<name>.remote and
-branch.<name>.merge options; see git-config(1) for details.
+branch.<name>.merge options; see
git-config(1) for details.
@@ -1020,8 +1068,8 @@ Merge into the current branch the remote branch next :
-This leaves a copy of next temporarily in FETCH_HEAD, but
-does not update any remote-tracking branches.
+This leaves a copy of next temporarily in FETCH_HEAD, but
+does not update any remote-tracking branches.
@@ -1032,7 +1080,7 @@ Bundle local branch fixes and enhancements on top of
$ git pull . fixes enhancements
-This git pull . syntax is equivalent to git merge .
+This git pull . syntax is equivalent to git merge .
@@ -1053,11 +1101,11 @@ Merge local branch maint into the current branch, but do not make
$ git pull --no-commit . maint
-This can be used when you want to include further changes to the
-merge, or want to write your own merge commit message.
-You should refrain from abusing this option to sneak substantial
+
This can be used when you want to include further changes to the
+merge, or want to write your own merge commit message.
+You should refrain from abusing this option to sneak substantial
changes into a merge commit. Small fixups like bumping
-release/version name would be acceptable.
+release/version name would be acceptable.
@@ -1069,39 +1117,39 @@ Command line pull of multiple branches from one repository:
$ git fetch origin +pu:pu maint:tmp
$ git pull . tmp
-
This updates (or creates, as necessary) branches pu and tmp in
+
This updates (or creates, as necessary) branches pu and tmp in
the local repository by fetching from the branches (respectively)
-pu and maint from the remote repository.
-
The pu branch will be updated even if it is does not fast-forward;
-the others will not be.
-
The final command then merges the newly fetched tmp into master.
+
pu and
maint from the remote repository.
+The pu branch will be updated even if it is does not fast-forward;
+the others will not be.
+The final command then merges the newly fetched tmp into master.
-
-If you tried a pull which resulted in a complex conflicts and
-would want to start over, you can recover with git-reset .
+
+If you tried a pull which resulted in a complex conflicts and
+would want to start over, you can recover with git-reset .
-SEE ALSO
+SEE ALSO
-Author
+Author
-
Written by Linus Torvalds <torvalds@osdl.org>
-and Junio C Hamano <junkio@cox.net>
+
Written by Linus Torvalds <torvalds@osdl.org>
+and Junio C Hamano <junkio@cox.net>
-Documentation
+Documentation
-
Documentation by Jon Loeliger,
+
Documentation by Jon Loeliger,
David Greaves,
-Junio C Hamano and the git-list <git@vger.kernel.org>.
+Junio C Hamano and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-pull.txt b/git-pull.txt
index d9537ebc6..092d1b8a3 100644
--- a/git-pull.txt
+++ b/git-pull.txt
@@ -13,16 +13,16 @@ SYNOPSIS
DESCRIPTION
-----------
-Runs `git-fetch` with the given parameters, and calls `git-merge`
+Runs 'git-fetch' with the given parameters, and calls 'git-merge'
to merge the retrieved head(s) into the current branch.
-With `--rebase`, calls `git-rebase` instead of `git-merge`.
+With `--rebase`, calls 'git-rebase' instead of 'git-merge'.
Note that you can use `.` (current directory) as the
to pull from the local repository -- this is useful
when merging local branches into the current branch.
-Also note that options meant for `git-pull` itself and underlying
-`git-merge` must be given before the options meant for `git-fetch`.
+Also note that options meant for 'git-pull' itself and underlying
+'git-merge' must be given before the options meant for 'git-fetch'.
OPTIONS
-------
@@ -182,7 +182,7 @@ The final command then merges the newly fetched `tmp` into master.
If you tried a pull which resulted in a complex conflicts and
-would want to start over, you can recover with `git-reset`.
+would want to start over, you can recover with 'git-reset'.
SEE ALSO
diff --git a/git-push.html b/git-push.html
index 4697ad8f5..c08ddb54d 100644
--- a/git-push.html
+++ b/git-push.html
@@ -3,7 +3,7 @@
-
+
git-push(1)
@@ -276,17 +324,17 @@ git-push(1) Manual Page
git push [--all] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>]
[--repo=all] [-f | --force] [-v | --verbose] [<repository> <refspec>…]
-DESCRIPTION
+DESCRIPTION
-
Updates remote refs using local refs, while sending objects
-necessary to complete the given refs.
-
You can make interesting things happen to a repository
+
Updates remote refs using local refs, while sending objects
+necessary to complete the given refs.
+
You can make interesting things happen to a repository
every time you push into it, by setting up hooks there. See
-documentation for git-receive-pack(1) .
+documentation for
git-receive-pack(1) .
-OPTIONS
+OPTIONS
-
+
<repository>
@@ -302,30 +350,30 @@ documentation for git-receive-pack(1) .
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.
-The <src> side represents the source branch (or arbitrary
+
The <src> side represents the source branch (or arbitrary
"SHA1 expression", such as master~4 (four parents before the
tip of master branch); see git-rev-parse(1) ) that you
-want to push. The <dst> side represents the destination location.
-
The local ref that matches <src> is used
+want to push. The <dst> side represents the destination location.
+The local ref that matches <src> is used
to fast forward the remote ref that matches <dst> (or, if no <dst> was
specified, the same ref that <src> referred to locally). If
the optional leading plus + is used, the remote ref is updated
-even if it does not result in a fast forward update.
-
tag <tag> means the same as refs/tags/<tag>:refs/tags/<tag> .
-
A parameter <ref> without a colon pushes the <ref> from the source
-repository to the destination repository under the same name.
-
Pushing an empty <src> allows you to delete the <dst> ref from
-the remote repository.
-
The special refspec : (or +: to allow non-fast forward updates)
+even if it does not result in a fast forward update.
+tag <tag> means the same as refs/tags/<tag>:refs/tags/<tag> .
+A parameter <ref> without a colon pushes the <ref> from the source
+repository to the destination repository under the same name.
+Pushing an empty <src> allows you to delete the <dst> ref from
+the remote repository.
+The special refspec : (or +: to allow non-fast forward updates)
directs git to push "matching" heads: for every head that exists on
the local side, the remote side is updated if a head of the same name
already exists on the remote side. This is the default operation mode
if no explicit refspec is found (that is neither on the command line
-nor in any Push line of the corresponding remotes file---see below).
+nor in any Push line of the corresponding remotes file---see below).
--all
@@ -375,7 +423,7 @@ nor in any Push line of the corresponding remotes file---see below).
- Path to the git-receive-pack program on the remote
+ Path to the git-receive-pack program on the remote
end. Sometimes useful when pushing to a remote
repository over ssh, and you do not have the program in
a directory on the default $PATH.
@@ -420,7 +468,7 @@ nor in any Push line of the corresponding remotes file---see below).
- These options are passed to git-send-pack . Thin
+ These options are passed to git-send-pack . Thin
transfer spends extra cycles to minimize the number of
objects to be sent and meant to be used on slower connection.
@@ -436,15 +484,15 @@ nor in any Push line of the corresponding remotes file---see below).
Run verbosely.
-
+
-GIT URLS
+GIT URLS
-
One of the following notations can be used
-to name the remote repository:
+
One of the following notations can be used
+to name the remote repository:
-
SSH is the default transport protocol over the network. You can
+
SSH is the default transport protocol over the network. You can
optionally specify which user to log-in as, and an alternate,
scp-like syntax is also supported. Both syntaxes support
username expansion, as does the native git protocol, but
only the former supports port specification. The following
-three are identical to the last three above, respectively:
+three are identical to the last three above, respectively:
-
+
[user@]host.xz:/path/to/repo.git/
@@ -516,12 +564,12 @@ three are identical to the last three above, respectively:
[user@]host.xz:path/to/repo.git
-
+
-
To sync with a local directory, you can use:
+
To sync with a local directory, you can use:
-
They are mostly equivalent, except when cloning. See
-git-clone(1) for details.
-
If there are a large number of similarly-named remote repositories and
+
They are mostly equivalent, except when cloning. See
+git-clone(1) for details.
+
If there are a large number of similarly-named remote repositories and
you want to use a different format for them (such that the URLs you
use will be rewritten into URLs that work), you can create a
-configuration section of the form:
+configuration section of the form:
[url "<actual url base>"]
insteadOf = <other url base>
-
For example, with this:
+
[url "git://git.host.xz/"]
insteadOf = host.xz:/path/to/
insteadOf = work:
-
a URL like "work:repo.git" or like "host.xz:/path/to/repo.git" will be
-rewritten in any context that takes a URL to be "git://git.host.xz/repo.git".
+
a URL like "work:repo.git" or like "host.xz:/path/to/repo.git" will be
+rewritten in any context that takes a URL to be "git://git.host.xz/repo.git".
-REMOTES
+REMOTES
-
The name of one of the following can be used instead
-of a URL as <repository> argument:
-
+The name of one of the following can be used instead
+of a URL as <repository> argument:
+
a remote in the git configuration file: $GIT_DIR/config ,
@@ -575,17 +623,17 @@ a file in the $GIT_DIR/remotes directory, or
a file in the $GIT_DIR/branches directory.
-
-
All of these also allow you to omit the refspec from the command line
-because they each contain a refspec which git will use by default.
-
Named remote in configuration file
-
You can choose to provide the name of a remote which you had previously
+
+All of these also allow you to omit the refspec from the command line
+because they each contain a refspec which git will use by default.
+Named remote in configuration file
+You can choose to provide the name of a remote which you had previously
configured using git-remote(1) , git-config(1)
or even by a manual edit to the $GIT_DIR/config file. The URL of
this remote will be used to access the repository. The refspec
of this remote will be used by default when you do
not provide a refspec on the command line. The entry in the
-config file would appear like this:
+config file would appear like this:
[remote "<name>"]
@@ -593,13 +641,13 @@ config file would appear like this:
push = <refspec>
fetch = <refspec>
-Named file in $GIT_DIR/remotes
-You can choose to provide the name of a
+
Named file in $GIT_DIR/remotes
+You can choose to provide the name of a
file in $GIT_DIR/remotes . The URL
in this file will be used to access the repository. The refspec
in this file will be used as default when you do not
provide a refspec on the command line. This file should have the
-following format:
+following format:
URL: one of the above URL format
@@ -607,41 +655,41 @@ following format:
Pull: <refspec>
-Push: lines are used by git-push and
-Pull: lines are used by git-pull and git-fetch .
+
Push: lines are used by git-push and
+Pull: lines are used by git-pull and git-fetch .
Multiple Push: and Pull: lines may
-be specified for additional branch mappings.
-
Named file in $GIT_DIR/branches
-
You can choose to provide the name of a
+be specified for additional branch mappings.
+Named file in $GIT_DIR/branches
+You can choose to provide the name of a
file in $GIT_DIR/branches .
The URL in this file will be used to access the repository.
-This file should have the following format:
+This file should have the following format:
-<url> is required; #<head> is optional.
+
<url> is required; #<head> is optional.
When you do not provide a refspec on the command line,
git will use the following refspec, where <head> defaults to master ,
and <repository> is the name of this file
-you provided in the command line.
+you provided in the command line.
refs/heads/<head>:<repository>
-OUTPUT
+OUTPUT
-
The output of "git push" depends on the transport method used; this
+
The output of "git push" depends on the transport method used; this
section describes the output when pushing over the git protocol (either
-locally or via ssh).
-
The status of the push is output in tabular form, with each line
-representing the status of a single ref. Each line is of the form:
+locally or via ssh).
+
The status of the push is output in tabular form, with each line
+representing the status of a single ref. Each line is of the form:
<flag> <summary> <from> -> <to> (<reason>)
-
+
flag
@@ -703,11 +751,11 @@ reason
failure is described.
-
+
-Examples
+Examples
-
+
git push origin master
@@ -752,24 +800,24 @@ git push origin master:refs/heads/experimental
the ref name on its own will work.
-
+
-Author
+Author
-
Written by Junio C Hamano <junkio@cox.net>, later rewritten in C
-by Linus Torvalds <torvalds@osdl.org>
+
Written by Junio C Hamano <junkio@cox.net>, later rewritten in C
+by Linus Torvalds <torvalds@osdl.org>
-Documentation
+Documentation
-
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-push.txt b/git-push.txt
index 1f70e7275..c44dce374 100644
--- a/git-push.txt
+++ b/git-push.txt
@@ -85,7 +85,7 @@ nor in any Push line of the corresponding remotes file---see below).
line.
--receive-pack=::
- Path to the `git-receive-pack` program on the remote
+ Path to the 'git-receive-pack' program on the remote
end. Sometimes useful when pushing to a remote
repository over ssh, and you do not have the program in
a directory on the default $PATH.
@@ -106,7 +106,7 @@ nor in any Push line of the corresponding remotes file---see below).
--thin::
--no-thin::
- These options are passed to `git-send-pack`. Thin
+ These options are passed to 'git-send-pack'. Thin
transfer spends extra cycles to minimize the number of
objects to be sent and meant to be used on slower connection.
diff --git a/git-read-tree.html b/git-read-tree.html
index f11717ecc..31d8eed02 100644
--- a/git-read-tree.html
+++ b/git-read-tree.html
@@ -3,7 +3,7 @@
-
+
git-read-tree(1)
@@ -272,23 +320,23 @@ git-read-tree(1) Manual Page
SYNOPSIS
-
git read-tree (<tree-ish> | [[-m [--trivial] [--aggressive] | --reset | --prefix=<prefix>] [-u | -i]] [--exclude-per-directory=<gitignore>] [--index-output=<file>] <tree-ish1> [<tree-ish2> [<tree-ish3>]])
+
git read-tree (<tree-ish> | [[-m [--trivial] [--aggressive] | --reset | --prefix=<prefix>] [-u | -i]] [--exclude-per-directory=<gitignore>] [--index-output=<file>] <tree-ish1> [<tree-ish2> [<tree-ish3>]])
-DESCRIPTION
+DESCRIPTION
-
Reads the tree information given by <tree-ish> into the index,
+
Reads the tree information given by <tree-ish> into the index,
but does not actually update any of the files it "caches". (see:
-git-checkout-index(1) )
-
Optionally, it can merge a tree into the index, perform a
+git-checkout-index(1) )
+
Optionally, it can merge a tree into the index, perform a
fast-forward (i.e. 2-way) merge, or a 3-way merge, with the -m
flag. When used with -m , the -u flag causes it to also update
-the files in the work tree with the result of the merge.
-
Trivial merges are done by git-read-tree itself. Only conflicting paths
-will be in unmerged state when git-read-tree returns.
+the files in the work tree with the result of the merge.
+
Trivial merges are done by git-read-tree itself. Only conflicting paths
+will be in unmerged state when git-read-tree returns.
-OPTIONS
+OPTIONS
-
+
-m
@@ -345,7 +393,7 @@ will be in unmerged state when git-read-tree returns.
- Restrict three-way merge by git-read-tree to happen
+ Restrict three-way merge by git-read-tree to happen
only if there is no file-level merging required, instead
of resolving merge for trivial cases and leaving
conflicting files unresolved in the index.
@@ -356,13 +404,13 @@ will be in unmerged state when git-read-tree returns.
- Usually a three-way merge by git-read-tree resolves
+ Usually a three-way merge by git-read-tree resolves
the merge for really trivial cases and leaves other
cases unresolved in the index, so that Porcelains can
implement different merge policies. This flag makes the
command to resolve a few more cases internally:
-
--prefix=<prefix>/
@@ -440,33 +488,33 @@ when both sides adds a path identically. The resolution
The id of the tree object(s) to be read/merged.
-
+
-Merging
+Merging
-
If -m is specified, git-read-tree can perform 3 kinds of
+
If -m is specified, git-read-tree can perform 3 kinds of
merge, a single tree merge if only 1 tree is given, a
fast-forward merge with 2 trees, or a 3-way merge if 3 trees are
-provided.
-
Single Tree Merge
-
If only 1 tree is specified, git-read-tree operates as if the user did not
+provided.
+
Single Tree Merge
+
If only 1 tree is specified, git-read-tree operates as if the user did not
specify -m , except that if the original index has an entry for a
given pathname, and the contents of the path matches with the tree
being read, the stat info from the index is used. (In other words, the
-index's stat()s take precedence over the merged tree's).
-
That means that if you do a git read-tree -m <newtree> followed by a
-git checkout-index -f -u -a , the git-checkout-index only checks out
-the stuff that really changed.
-
This is used to avoid unnecessary false hits when git-diff-files is
-run after git-read-tree .
-
Two Tree Merge
-
Typically, this is invoked as git read-tree -m $H $M , where $H
+index's stat()s take precedence over the merged tree's).
+
That means that if you do a git read-tree -m <newtree> followed by a
+git checkout-index -f -u -a , the git-checkout-index only checks out
+the stuff that really changed.
+
This is used to avoid unnecessary false hits when git-diff-files is
+run after git-read-tree .
+
Two Tree Merge
+
Typically, this is invoked as git read-tree -m $H $M , where $H
is the head commit of the current repository, and $M is the head
of a foreign tree, which is simply ahead of $H (i.e. we are in a
-fast forward situation).
-
When two trees are specified, the user is telling git-read-tree
-the following:
-
+fast forward situation).
+
When two trees are specified, the user is telling git-read-tree
+the following:
+
The current index and work tree is derived from $H, but
@@ -478,10 +526,10 @@ The current index and work tree is derived from $H, but
The user wants to fast-forward to $M.
-
-
In this case, the git read-tree -m $H $M command makes sure
+
+
In this case, the git read-tree -m $H $M command makes sure
that no local change is lost as the result of this "merge".
-Here are the "carry forward" rules:
+Here are the "carry forward" rules:
I (index) H M Result
@@ -530,11 +578,11 @@ Here are the "carry forward" rules:
20 yes yes no exists exists use M
21 no yes no exists exists fail
-
In all "keep index" cases, the index entry stays as in the
+
In all "keep index" cases, the index entry stays as in the
original index file. If the entry were not up to date,
-git-read-tree keeps the copy in the work tree intact when
-operating under the -u flag.
-
When this form of git-read-tree returns successfully, you can
+git-read-tree keeps the copy in the work tree intact when
+operating under the -u flag.
+
When this form of git-read-tree returns successfully, you can
see what "local changes" you made are carried forward by running
git diff-index --cached $M . Note that this does not
necessarily match git diff-index --cached $H would have
@@ -543,27 +591,27 @@ produced before such a two tree merge. This is because of cases
you picked it up via e-mail in a patch form), git diff-index
--cached $H would have told you about the change before this
merge, but it would not show in git diff-index --cached $M
-output after two-tree merge.
-
3-Way Merge
-
Each "index" entry has two bits worth of "stage" state. stage 0 is the
-normal one, and is the only one you'd see in any kind of normal use.
-
However, when you do git-read-tree with three trees, the "stage"
-starts out at 1.
-
This means that you can do
+output after two-tree merge.
+
3-Way Merge
+
Each "index" entry has two bits worth of "stage" state. stage 0 is the
+normal one, and is the only one you'd see in any kind of normal use.
+
However, when you do git-read-tree with three trees, the "stage"
+starts out at 1.
+
This means that you can do
$ git read-tree -m <tree1> <tree2> <tree3>
-
and you will end up with an index with all of the <tree1> entries in
+
and you will end up with an index with all of the <tree1> entries in
"stage1", all of the <tree2> entries in "stage2" and all of the
<tree3> entries in "stage3". When performing a merge of another
branch into the current branch, we use the common ancestor tree
as <tree1>, the current branch head as <tree2>, and the other
-branch head as <tree3>.
-
Furthermore, git-read-tree has special-case logic that says: if you see
+branch head as <tree3>.
+
Furthermore, git-read-tree has special-case logic that says: if you see
a file that matches in all respects in the following states, it
-"collapses" back to "stage0":
-
+"collapses" back to "stage0":
+
-
The git-write-tree command refuses to write a nonsensical tree, and it
+
+
The git-write-tree command refuses to write a nonsensical tree, and it
will complain about unmerged entries if it sees a single entry that is not
-stage 0.
-
OK, this all sounds like a collection of totally nonsensical rules,
+stage 0.
+
OK, this all sounds like a collection of totally nonsensical rules,
but it's actually exactly what you want in order to do a fast
merge. The different stages represent the "result tree" (stage 0, aka
"merged"), the original tree (stage 1, aka "orig"), and the two trees
-you are trying to merge (stage 2 and 3 respectively).
-
The order of stages 1, 2 and 3 (hence the order of three
+you are trying to merge (stage 2 and 3 respectively).
+
The order of stages 1, 2 and 3 (hence the order of three
<tree-ish> command line arguments) are significant when you
start a 3-way merge with an index file that is already
-populated. Here is an outline of how the algorithm works:
-
+populated. Here is an outline of how the algorithm works:
+
if a file exists in identical format in all three trees, it will
- automatically collapse to "merged" state by git-read-tree .
+ automatically collapse to "merged" state by git-read-tree .
-a file that has _any_ difference what-so-ever in the three trees
+a file that has any difference what-so-ever in the three trees
will stay as separate entries in the index. It's up to "porcelain
policy" to determine how to remove the non-0 stages, and insert a
merged version.
@@ -620,7 +668,7 @@ the index file saves and restores with all this information, so you
stages 1/2/3 (i.e., "unmerged entries") you can't write the result. So
now the merge algorithm ends up being really simple:
-
+
you walk the index in order, and ignore all entries of stage 0,
@@ -642,41 +690,41 @@ if you find a matching "stage2" and "stage3" tree, you remove one
trivial rules ..
-
+
-
-
You would normally use git-merge-index with supplied
-git-merge-one-file to do this last step. The script updates
+
+
You would normally use git-merge-index with supplied
+git-merge-one-file to do this last step. The script updates
the files in the working tree as it merges each path and at the
-end of a successful merge.
-
When you start a 3-way merge with an index file that is already
+end of a successful merge.
+
When you start a 3-way merge with an index file that is already
populated, it is assumed that it represents the state of the
files in your work tree, and you can even have files with
changes unrecorded in the index file. It is further assumed
that this state is "derived" from the stage 2 tree. The 3-way
merge refuses to run if it finds an entry in the original index
-file that does not match stage 2.
-
This is done to prevent you from losing your work-in-progress
+file that does not match stage 2.
+
This is done to prevent you from losing your work-in-progress
changes, and mixing your random changes in an unrelated merge
commit. To illustrate, suppose you start from what has been
-committed last to your repository:
+committed last to your repository:
$ JC=`git rev-parse --verify "HEAD^0"`
$ git checkout-index -f -u -a $JC
-
You do random edits, without running git-update-index . And then
+
You do random edits, without running git-update-index . And then
you notice that the tip of your "upstream" tree has advanced
-since you pulled from him:
+since you pulled from him:
$ git fetch git://.... linus
$ LT=`cat .git/FETCH_HEAD`
-
Your work tree is still based on your HEAD ($JC), but you have
+
Your work tree is still based on your HEAD ($JC), but you have
some edits since. Three-way merge makes sure that you have not
added or modified index entries since $JC, and if you haven't,
-then does the right thing. So with the following sequence:
+then does the right thing. So with the following sequence:
$ git read-tree -m -u `git merge-base $JC $LT` $JC $LT
@@ -684,42 +732,42 @@ $ git merge-index git-merge-one-file -a
$ echo "Merge with Linus" | \
git commit-tree `git write-tree` -p $JC -p $LT
-
what you would commit is a pure merge between $JC and $LT without
+
what you would commit is a pure merge between $JC and $LT without
your work-in-progress changes, and your work tree would be
-updated to the result of the merge.
-
However, if you have local changes in the working tree that
-would be overwritten by this merge, git-read-tree will refuse
-to run to prevent your changes from being lost.
-
In other words, there is no need to worry about what exists only
+updated to the result of the merge.
+
However, if you have local changes in the working tree that
+would be overwritten by this merge, git-read-tree will refuse
+to run to prevent your changes from being lost.
+
In other words, there is no need to worry about what exists only
in the working tree. When you have local changes in a part of
the project that is not involved in the merge, your changes do
not interfere with the merge, and are kept intact. When they
-do interfere, the merge does not even start (git-read-tree
+do interfere, the merge does not even start (git-read-tree
complains loudly and fails without modifying anything). In such
a case, you can simply continue doing what you were in the
middle of doing, and when your working tree is ready (i.e. you
-have finished your work-in-progress), attempt the merge again.
+have finished your work-in-progress), attempt the merge again.
-SEE ALSO
+SEE ALSO
-Author
+Author
-
Written by Linus Torvalds <torvalds@osdl.org>
+
Written by Linus Torvalds <torvalds@osdl.org>
-Documentation
+Documentation
-
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-read-tree.txt b/git-read-tree.txt
index 0c7cc6b94..6f4b9b017 100644
--- a/git-read-tree.txt
+++ b/git-read-tree.txt
@@ -22,8 +22,8 @@ fast-forward (i.e. 2-way) merge, or a 3-way merge, with the `-m`
flag. When used with `-m`, the `-u` flag causes it to also update
the files in the work tree with the result of the merge.
-Trivial merges are done by `git-read-tree` itself. Only conflicting paths
-will be in unmerged state when `git-read-tree` returns.
+Trivial merges are done by 'git-read-tree' itself. Only conflicting paths
+will be in unmerged state when 'git-read-tree' returns.
OPTIONS
-------
@@ -54,13 +54,13 @@ OPTIONS
Show the progress of checking files out.
--trivial::
- Restrict three-way merge by `git-read-tree` to happen
+ Restrict three-way merge by 'git-read-tree' to happen
only if there is no file-level merging required, instead
of resolving merge for trivial cases and leaving
conflicting files unresolved in the index.
--aggressive::
- Usually a three-way merge by `git-read-tree` resolves
+ Usually a three-way merge by 'git-read-tree' resolves
the merge for really trivial cases and leaves other
cases unresolved in the index, so that Porcelains can
implement different merge policies. This flag makes the
@@ -113,7 +113,7 @@ OPTIONS
Merging
-------
-If `-m` is specified, `git-read-tree` can perform 3 kinds of
+If `-m` is specified, 'git-read-tree' can perform 3 kinds of
merge, a single tree merge if only 1 tree is given, a
fast-forward merge with 2 trees, or a 3-way merge if 3 trees are
provided.
@@ -121,18 +121,18 @@ provided.
Single Tree Merge
~~~~~~~~~~~~~~~~~
-If only 1 tree is specified, `git-read-tree` operates as if the user did not
+If only 1 tree is specified, 'git-read-tree' operates as if the user did not
specify `-m`, except that if the original index has an entry for a
given pathname, and the contents of the path matches with the tree
being read, the stat info from the index is used. (In other words, the
index's stat()s take precedence over the merged tree's).
That means that if you do a `git read-tree -m ` followed by a
-`git checkout-index -f -u -a`, the `git-checkout-index` only checks out
+`git checkout-index -f -u -a`, the 'git-checkout-index' only checks out
the stuff that really changed.
-This is used to avoid unnecessary false hits when `git-diff-files` is
-run after `git-read-tree`.
+This is used to avoid unnecessary false hits when 'git-diff-files' is
+run after 'git-read-tree'.
Two Tree Merge
@@ -143,7 +143,7 @@ is the head commit of the current repository, and $M is the head
of a foreign tree, which is simply ahead of $H (i.e. we are in a
fast forward situation).
-When two trees are specified, the user is telling `git-read-tree`
+When two trees are specified, the user is telling 'git-read-tree'
the following:
1. The current index and work tree is derived from $H, but
@@ -193,10 +193,10 @@ Here are the "carry forward" rules:
In all "keep index" cases, the index entry stays as in the
original index file. If the entry were not up to date,
-`git-read-tree` keeps the copy in the work tree intact when
+'git-read-tree' keeps the copy in the work tree intact when
operating under the -u flag.
-When this form of `git-read-tree` returns successfully, you can
+When this form of 'git-read-tree' returns successfully, you can
see what "local changes" you made are carried forward by running
`git diff-index --cached $M`. Note that this does not
necessarily match `git diff-index --cached $H` would have
@@ -213,7 +213,7 @@ output after two-tree merge.
Each "index" entry has two bits worth of "stage" state. stage 0 is the
normal one, and is the only one you'd see in any kind of normal use.
-However, when you do `git-read-tree` with three trees, the "stage"
+However, when you do 'git-read-tree' with three trees, the "stage"
starts out at 1.
This means that you can do
@@ -229,7 +229,7 @@ branch into the current branch, we use the common ancestor tree
as , the current branch head as , and the other
branch head as .
-Furthermore, `git-read-tree` has special-case logic that says: if you see
+Furthermore, 'git-read-tree' has special-case logic that says: if you see
a file that matches in all respects in the following states, it
"collapses" back to "stage0":
@@ -245,7 +245,7 @@ a file that matches in all respects in the following states, it
- stage 1 and stage 3 are the same and stage 2 is different take
stage 2 (we did something while they did nothing)
-The `git-write-tree` command refuses to write a nonsensical tree, and it
+The 'git-write-tree' command refuses to write a nonsensical tree, and it
will complain about unmerged entries if it sees a single entry that is not
stage 0.
@@ -261,7 +261,7 @@ start a 3-way merge with an index file that is already
populated. Here is an outline of how the algorithm works:
- if a file exists in identical format in all three trees, it will
- automatically collapse to "merged" state by `git-read-tree`.
+ automatically collapse to "merged" state by 'git-read-tree'.
- a file that has _any_ difference what-so-ever in the three trees
will stay as separate entries in the index. It's up to "porcelain
@@ -285,8 +285,8 @@ populated. Here is an outline of how the algorithm works:
matching "stage1" entry if it exists too. .. all the normal
trivial rules ..
-You would normally use `git-merge-index` with supplied
-`git-merge-one-file` to do this last step. The script updates
+You would normally use 'git-merge-index' with supplied
+'git-merge-one-file' to do this last step. The script updates
the files in the working tree as it merges each path and at the
end of a successful merge.
@@ -308,7 +308,7 @@ $ JC=`git rev-parse --verify "HEAD^0"`
$ git checkout-index -f -u -a $JC
----------------
-You do random edits, without running `git-update-index`. And then
+You do random edits, without running 'git-update-index'. And then
you notice that the tip of your "upstream" tree has advanced
since you pulled from him:
@@ -334,14 +334,14 @@ your work-in-progress changes, and your work tree would be
updated to the result of the merge.
However, if you have local changes in the working tree that
-would be overwritten by this merge, `git-read-tree` will refuse
+would be overwritten by this merge, 'git-read-tree' will refuse
to run to prevent your changes from being lost.
In other words, there is no need to worry about what exists only
in the working tree. When you have local changes in a part of
the project that is not involved in the merge, your changes do
not interfere with the merge, and are kept intact. When they
-*do* interfere, the merge does not even start (`git-read-tree`
+*do* interfere, the merge does not even start ('git-read-tree'
complains loudly and fails without modifying anything). In such
a case, you can simply continue doing what you were in the
middle of doing, and when your working tree is ready (i.e. you
diff --git a/git-rebase.html b/git-rebase.html
index 564948b37..a2905d502 100644
--- a/git-rebase.html
+++ b/git-rebase.html
@@ -3,7 +3,7 @@
-
+
git-rebase(1)
@@ -279,74 +327,74 @@ git-rebase(1) Manual Page
[--onto <newbase>] <upstream> [<branch>]
git rebase --continue | --skip | --abort
-DESCRIPTION
+DESCRIPTION
-
If <branch> is specified, git-rebase will perform an automatic
+
If <branch> is specified, git-rebase will perform an automatic
git checkout <branch> before doing anything else. Otherwise
-it remains on the current branch.
-
All changes made by commits in the current branch but that are not
+it remains on the current branch.
+
All changes made by commits in the current branch but that are not
in <upstream> are saved to a temporary area. This is the same set
-of commits that would be shown by git log <upstream>..HEAD .
-
The current branch is reset to <upstream>, or <newbase> if the
+of commits that would be shown by git log <upstream>..HEAD .
+
The current branch is reset to <upstream>, or <newbase> if the
--onto option was supplied. This has the exact same effect as
-git reset --hard <upstream> (or <newbase>).
-
The commits that were previously saved into the temporary area are
+git reset --hard <upstream> (or <newbase>).
+
The commits that were previously saved into the temporary area are
then reapplied to the current branch, one by one, in order. Note that
any commits in HEAD which introduce the same textual changes as a commit
in HEAD..<upstream> are omitted (i.e., a patch already accepted upstream
-with a different commit message or timestamp will be skipped).
-
It is possible that a merge failure will prevent this process from being
+with a different commit message or timestamp will be skipped).
+
It is possible that a merge failure will prevent this process from being
completely automatic. You will have to resolve any such merge failure
and run git rebase --continue . Another option is to bypass the commit
that caused the merge failure with git rebase --skip . To restore the
original <branch> and remove the .dotest working files, use the command
-git rebase --abort instead.
-
Assume the following history exists and the current branch is "topic":
+
git rebase --abort instead.
+
Assume the following history exists and the current branch is "topic":
A---B---C topic
/
D---E---F---G master
-
From this point, the result of either of the following commands:
+
From this point, the result of either of the following commands:
git rebase master
git rebase master topic
-
would be:
+
A'--B'--C' topic
/
D---E---F---G master
-
The latter form is just a short-hand of git checkout topic
-followed by git rebase master .
-
If the upstream branch already contains a change you have made (e.g.,
+
The latter form is just a short-hand of git checkout topic
+followed by git rebase master .
+
If the upstream branch already contains a change you have made (e.g.,
because you mailed a patch which was applied upstream), then that commit
will be skipped. For example, running git rebase master on the
following history (in which A' and A introduce the same set of changes,
-but have different committer information):
+but have different committer information):
A---B---C topic
/
D---E---A'---F master
-
will result in:
+
B'---C' topic
/
D---E---A'---F master
-
Here is how you would transplant a topic branch based on one
+
Here is how you would transplant a topic branch based on one
branch to another, to pretend that you forked the topic branch
-from the latter branch, using rebase --onto .
-
First let's assume your topic is based on branch next .
+from the latter branch, using rebase --onto .
+
First let's assume your topic is based on branch next .
For example feature developed in topic depends on some
-functionality which is found in next .
+functionality which is found in
next .
o---o---o---o---o master
@@ -355,9 +403,9 @@ functionality which is found in next .
\
o---o---o topic
-
We would want to make topic forked from branch master ,
+
We would want to make topic forked from branch master ,
for example because the functionality topic branch depend on
-got merged into more stable master branch, like this:
+got merged into more stable
master branch, like this:
o---o---o---o---o master
@@ -366,13 +414,13 @@ got merged into more stable master branch, like this:
\
o---o---o---o---o next
-
We can get this using the following command:
+
We can get this using the following command:
git rebase --onto master next topic
-
Another example of --onto option is to rebase part of a
-branch. If we have the following situation:
+
Another example of --onto option is to rebase part of a
+branch. If we have the following situation:
H---I---J topicB
@@ -381,12 +429,12 @@ branch. If we have the following situation:
/
A---B---C---D master
-
then the command
+
git rebase --onto master topicA topicB
-
would result in:
+
H'--I'--J' topicB
@@ -395,50 +443,50 @@ branch. If we have the following situation:
|/
A---B---C---D master
-
This is useful when topicB does not depend on topicA.
-
A range of commits could also be removed with rebase. If we have
-the following situation:
+
This is useful when topicB does not depend on topicA.
+
A range of commits could also be removed with rebase. If we have
+the following situation:
E---F---G---H---I---J topicA
-
then the command
+
git rebase --onto topicA~5 topicA~3 topicA
-
would result in the removal of commits F and G:
+
would result in the removal of commits F and G:
-
This is useful if F and G were flawed in some way, or should not be
+
This is useful if F and G were flawed in some way, or should not be
part of topicA. Note that the argument to --onto and the <upstream>
-parameter can be any valid commit-ish.
-
In case of conflict, git-rebase will stop at the first problematic commit
-and leave conflict markers in the tree. You can use git-diff to locate
+parameter can be any valid commit-ish.
+
In case of conflict, git-rebase will stop at the first problematic commit
+and leave conflict markers in the tree. You can use git-diff to locate
the markers (<<<<<<) and make edits to resolve the conflict. For each
file you edit, you need to tell git that the conflict has been resolved,
-typically this would be done with
+typically this would be done with
-
After resolving the conflict manually and updating the index with the
-desired resolution, you can continue the rebasing process with
+
After resolving the conflict manually and updating the index with the
+desired resolution, you can continue the rebasing process with
-
Alternatively, you can undo the git-rebase with
+
Alternatively, you can undo the git-rebase with
-OPTIONS
+OPTIONS
-
+
<newbase>
@@ -515,8 +563,8 @@ desired resolution, you can continue the rebasing process with
Use the given merge strategy; can be supplied more than
once to specify them in the order they should be tried.
If there is no -s option, a built-in list of strategies
- is used instead (git-merge-recursive when merging a single
- head, git-merge-octopus otherwise). This implies --merge.
+ is used instead (git-merge-recursive when merging a single
+ head, git-merge-octopus otherwise). This implies --merge.
@@ -546,7 +594,7 @@ desired resolution, you can continue the rebasing process with
- This flag is passed to the git-apply program
+ This flag is passed to the git-apply program
(see git-apply(1) ) that applies the patch.
@@ -575,11 +623,11 @@ desired resolution, you can continue the rebasing process with
only works in interactive mode.
-
+
-MERGE STRATEGIES
+MERGE STRATEGIES
-
+
resolve
@@ -645,28 +693,28 @@ subtree
ancestor tree.
-
+
-NOTES
+NOTES
-
When you rebase a branch, you are changing its history in a way that
+
When you rebase a branch, you are changing its history in a way that
will cause problems for anyone who already has a copy of the branch
in their repository and tries to pull updates from you. You should
-understand the implications of using git rebase on a repository that
-you share.
-
When the git rebase command is run, it will first execute a "pre-rebase"
+understand the implications of using git-rebase on a repository that
+you share.
+
When the git-rebase command is run, it will first execute a "pre-rebase"
hook if one exists. You can use this hook to do sanity checks and
reject the rebase if it isn't appropriate. Please see the template
-pre-rebase hook script for an example.
-
Upon completion, <branch> will be the current branch.
+pre-rebase hook script for an example.
+
Upon completion, <branch> will be the current branch.
-INTERACTIVE MODE
+INTERACTIVE MODE
-
Rebasing interactively means that you have a chance to edit the commits
+
Rebasing interactively means that you have a chance to edit the commits
which are rebased. You can reorder the commits, and you can
-remove them (weeding out bad or otherwise unwanted patches).
-
The interactive mode is meant for this type of workflow:
-
+remove them (weeding out bad or otherwise unwanted patches).
+
The interactive mode is meant for this type of workflow:
+
have a wonderful idea
@@ -687,14 +735,14 @@ prepare a series for submission
submit
-
-
where point 2. consists of several instances of
-
+
+
where point 2. consists of several instances of
+
regular use
-
+
finish something worthy of a commit
@@ -705,13 +753,13 @@ finish something worthy of a commit
commit
-
+
independent fixup
-
+
realize that something does not work
@@ -727,52 +775,52 @@ fix that
commit it
-
+
-
-
Sometimes the thing fixed in b.2. cannot be amended to the not-quite
+
+
Sometimes the thing fixed in b.2. cannot be amended to the not-quite
perfect commit it fixes, because that commit is buried deeply in a
patch series. That is exactly what interactive rebase is for: use it
after plenty of "a"s and "b"s, by rearranging and editing
-commits, and squashing multiple commits into one.
-
Start it with the last commit you want to retain as-is:
+commits, and squashing multiple commits into one.
+
Start it with the last commit you want to retain as-is:
git rebase -i <after-this-commit>
-
An editor will be fired up with all the commits in your current branch
+
An editor will be fired up with all the commits in your current branch
(ignoring merge commits), which come after the given commit. You can
reorder the commits in this list to your heart's content, and you can
-remove them. The list looks more or less like this:
+remove them. The list looks more or less like this:
pick deadbee The oneline of this commit
pick fa1afe1 The oneline of the next commit
...
-
The oneline descriptions are purely for your pleasure; git-rebase will
+
The oneline descriptions are purely for your pleasure; git-rebase will
not look at them but at the commit names ("deadbee" and "fa1afe1" in this
-example), so do not delete or edit the names.
-
By replacing the command "pick" with the command "edit", you can tell
-git-rebase to stop after applying that commit, so that you can edit
+example), so do not delete or edit the names.
+
By replacing the command "pick" with the command "edit", you can tell
+git-rebase to stop after applying that commit, so that you can edit
the files and/or the commit message, amend the commit, and continue
-rebasing.
-
If you want to fold two or more commits into one, replace the command
+rebasing.
+
If you want to fold two or more commits into one, replace the command
"pick" with "squash" for the second and subsequent commit. If the
commits had different authors, it will attribute the squashed commit to
-the author of the first commit.
-
In both cases, or when a "pick" does not succeed (because of merge
+the author of the first commit.
+
In both cases, or when a "pick" does not succeed (because of merge
errors), the loop will stop to let you fix things, and you can continue
-the loop with git rebase --continue .
-
For example, if you want to reorder the last 5 commits, such that what
+the loop with git rebase --continue .
+
For example, if you want to reorder the last 5 commits, such that what
was HEAD~4 becomes the new HEAD. To achieve that, you would call
-git-rebase like this:
+
git-rebase like this:
-
And move the first patch to the end of the list.
-
You might want to preserve merges, if you have a history like this:
+
And move the first patch to the end of the list.
+
You might want to preserve merges, if you have a history like this:
X
@@ -781,20 +829,20 @@ was HEAD~4 becomes the new HEAD. To achieve that, you would call
/
---o---O---P---Q
-
Suppose you want to rebase the side branch starting at "A" to "Q". Make
-sure that the current HEAD is "B", and call
+
Suppose you want to rebase the side branch starting at "A" to "Q". Make
+sure that the current HEAD is "B", and call
$ git rebase -i -p --onto Q O
-SPLITTING COMMITS
+SPLITTING COMMITS
-
In interactive mode, you can mark commits with the action "edit". However,
-this does not necessarily mean that git-rebase expects the result of this
+
In interactive mode, you can mark commits with the action "edit". However,
+this does not necessarily mean that git-rebase expects the result of this
edit to be exactly one commit. Indeed, you can undo the commit, or you can
-add other commits. This can be used to split a commit into two:
-
+add other commits. This can be used to split a commit into two:
+
Start an interactive rebase with git rebase -i <commit>^ , where
@@ -818,7 +866,7 @@ When it comes to editing that commit, execute git reset HEAD^ . The
Now add the changes to the index that you want to have in the first
commit. You can use git add (possibly interactively) or
- git-gui (or both) to do that.
+ git-gui (or both) to do that.
@@ -837,28 +885,28 @@ Repeat the last two steps until your working tree is clean.
Continue the rebase with git rebase --continue .
-
-
If you are not absolutely sure that the intermediate revisions are
+
+
If you are not absolutely sure that the intermediate revisions are
consistent (they compile, pass the testsuite, etc.) you should use
-git-stash to stash away the not-yet-committed changes
-after each commit, test, and amend the commit if fixes are necessary.
+
git-stash to stash away the not-yet-committed changes
+after each commit, test, and amend the commit if fixes are necessary.
-Authors
+Authors
-
Written by Junio C Hamano <junkio@cox.net> and
-Johannes E. Schindelin <johannes.schindelin@gmx.de>
+
Written by Junio C Hamano <junkio@cox.net> and
+Johannes E. Schindelin <johannes.schindelin@gmx.de>
-Documentation
+Documentation
-
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-rebase.txt b/git-rebase.txt
index 754230e46..f3459c7de 100644
--- a/git-rebase.txt
+++ b/git-rebase.txt
@@ -16,7 +16,7 @@ SYNOPSIS
DESCRIPTION
-----------
-If is specified, `git-rebase` will perform an automatic
+If is specified, 'git-rebase' will perform an automatic
`git checkout ` before doing anything else. Otherwise
it remains on the current branch.
@@ -167,8 +167,8 @@ This is useful if F and G were flawed in some way, or should not be
part of topicA. Note that the argument to --onto and the
parameter can be any valid commit-ish.
-In case of conflict, `git-rebase` will stop at the first problematic commit
-and leave conflict markers in the tree. You can use `git-diff` to locate
+In case of conflict, 'git-rebase' will stop at the first problematic commit
+and leave conflict markers in the tree. You can use 'git-diff' to locate
the markers (<<<<<<) and make edits to resolve the conflict. For each
file you edit, you need to tell git that the conflict has been resolved,
typically this would be done with
@@ -184,7 +184,7 @@ desired resolution, you can continue the rebasing process with
git rebase --continue
-Alternatively, you can undo the `git-rebase` with
+Alternatively, you can undo the 'git-rebase' with
git rebase --abort
@@ -224,8 +224,8 @@ OPTIONS
Use the given merge strategy; can be supplied more than
once to specify them in the order they should be tried.
If there is no `-s` option, a built-in list of strategies
- is used instead (`git-merge-recursive` when merging a single
- head, `git-merge-octopus` otherwise). This implies --merge.
+ is used instead ('git-merge-recursive' when merging a single
+ head, 'git-merge-octopus' otherwise). This implies --merge.
-v::
--verbose::
@@ -238,7 +238,7 @@ OPTIONS
ever ignored.
--whitespace=::
- This flag is passed to the `git-apply` program
+ This flag is passed to the 'git-apply' program
(see linkgit:git-apply[1]) that applies the patch.
-i::
@@ -259,10 +259,10 @@ NOTES
When you rebase a branch, you are changing its history in a way that
will cause problems for anyone who already has a copy of the branch
in their repository and tries to pull updates from you. You should
-understand the implications of using 'git rebase' on a repository that
+understand the implications of using 'git-rebase' on a repository that
you share.
-When the git rebase command is run, it will first execute a "pre-rebase"
+When the git-rebase command is run, it will first execute a "pre-rebase"
hook if one exists. You can use this hook to do sanity checks and
reject the rebase if it isn't appropriate. Please see the template
pre-rebase hook script for an example.
@@ -314,12 +314,12 @@ pick fa1afe1 The oneline of the next commit
...
-------------------------------------------
-The oneline descriptions are purely for your pleasure; `git-rebase` will
+The oneline descriptions are purely for your pleasure; 'git-rebase' will
not look at them but at the commit names ("deadbee" and "fa1afe1" in this
example), so do not delete or edit the names.
By replacing the command "pick" with the command "edit", you can tell
-`git-rebase` to stop after applying that commit, so that you can edit
+'git-rebase' to stop after applying that commit, so that you can edit
the files and/or the commit message, amend the commit, and continue
rebasing.
@@ -334,7 +334,7 @@ the loop with `git rebase --continue`.
For example, if you want to reorder the last 5 commits, such that what
was HEAD~4 becomes the new HEAD. To achieve that, you would call
-`git-rebase` like this:
+'git-rebase' like this:
----------------------
$ git rebase -i HEAD~5
@@ -364,7 +364,7 @@ SPLITTING COMMITS
-----------------
In interactive mode, you can mark commits with the action "edit". However,
-this does not necessarily mean that `git-rebase` expects the result of this
+this does not necessarily mean that 'git-rebase' expects the result of this
edit to be exactly one commit. Indeed, you can undo the commit, or you can
add other commits. This can be used to split a commit into two:
@@ -380,7 +380,7 @@ add other commits. This can be used to split a commit into two:
- Now add the changes to the index that you want to have in the first
commit. You can use `git add` (possibly interactively) or
- `git-gui` (or both) to do that.
+ 'git-gui' (or both) to do that.
- Commit the now-current index with whatever commit message is appropriate
now.
@@ -391,7 +391,7 @@ add other commits. This can be used to split a commit into two:
If you are not absolutely sure that the intermediate revisions are
consistent (they compile, pass the testsuite, etc.) you should use
-`git-stash` to stash away the not-yet-committed changes
+'git-stash' to stash away the not-yet-committed changes
after each commit, test, and amend the commit if fixes are necessary.
diff --git a/git-receive-pack.html b/git-receive-pack.html
index d5ea89b57..d4c5cfb09 100644
--- a/git-receive-pack.html
+++ b/git-receive-pack.html
@@ -3,7 +3,7 @@
-
+
git-receive-pack(1)
@@ -272,29 +320,29 @@ git-receive-pack(1) Manual Page
SYNOPSIS
-
git receive-pack <directory>
+
git receive-pack <directory>
-DESCRIPTION
+DESCRIPTION
-
Invoked by git-send-pack and updates the repository with the
-information fed from the remote end.
-
This command is usually not invoked directly by the end user.
-The UI for the protocol is on the git-send-pack side, and the
+
Invoked by git-send-pack and updates the repository with the
+information fed from the remote end.
+
This command is usually not invoked directly by the end user.
+The UI for the protocol is on the git-send-pack side, and the
program pair is meant to be used to push updates to remote
-repository. For pull operations, see git-fetch-pack(1) .
-
The command allows for creation and fast forwarding of sha1 refs
+repository. For pull operations, see git-fetch-pack(1) .
+
The command allows for creation and fast forwarding of sha1 refs
(heads/tags) on the remote end (strictly speaking, it is the
-local end git-receive-pack runs, but to the user who is sitting at
-the send-pack end, it is updating the remote. Confused?)
-
There are other real-world examples of using update and
-post-update hooks found in the Documentation/howto directory.
-
git-receive-pack honours the receive.denyNonFastForwards config
+local end git-receive-pack runs, but to the user who is sitting at
+the send-pack end, it is updating the remote. Confused?)
+
There are other real-world examples of using update and
+post-update hooks found in the Documentation/howto directory.
+
git-receive-pack honours the receive.denyNonFastForwards config
option, which tells it if updates to a ref should be denied if they
-are not fast-forwards.
+are not fast-forwards.
-OPTIONS
+OPTIONS
-
+
<directory>
@@ -303,72 +351,72 @@ are not fast-forwards.
The repository to sync into.
-
+
-pre-receive Hook
+pre-receive Hook
-
Before any ref is updated, if $GIT_DIR/hooks/pre-receive file exists
+
Before any ref is updated, if $GIT_DIR/hooks/pre-receive file exists
and is executable, it will be invoked once with no parameters. The
-standard input of the hook will be one line per ref to be updated:
+standard input of the hook will be one line per ref to be updated:
sha1-old SP sha1-new SP refname LF
-
The refname value is relative to $GIT_DIR; e.g. for the master
+
The refname value is relative to $GIT_DIR; e.g. for the master
head this is "refs/heads/master". The two sha1 values before
each refname are the object names for the refname before and after
the update. Refs to be created will have sha1-old equal to 0{40},
while refs to be deleted will have sha1-new equal to 0{40}, otherwise
-sha1-old and sha1-new should be valid objects in the repository.
-
This hook is called before any refname is updated and before any
-fast-forward checks are performed.
-
If the pre-receive hook exits with a non-zero exit status no updates
+sha1-old and sha1-new should be valid objects in the repository.
+
This hook is called before any refname is updated and before any
+fast-forward checks are performed.
+
If the pre-receive hook exits with a non-zero exit status no updates
will be performed, and the update, post-receive and post-update
hooks will not be invoked either. This can be useful to quickly
-bail out if the update is not to be supported.
+bail out if the update is not to be supported.
-update Hook
+update Hook
-
Before each ref is updated, if $GIT_DIR/hooks/update file exists
-and is executable, it is invoked once per ref, with three parameters:
+
Before each ref is updated, if $GIT_DIR/hooks/update file exists
+and is executable, it is invoked once per ref, with three parameters:
$GIT_DIR/hooks/update refname sha1-old sha1-new
-
The refname parameter is relative to $GIT_DIR; e.g. for the master
+
The refname parameter is relative to $GIT_DIR; e.g. for the master
head this is "refs/heads/master". The two sha1 arguments are
the object names for the refname before and after the update.
Note that the hook is called before the refname is updated,
so either sha1-old is 0{40} (meaning there is no such ref yet),
-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
+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 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.
+this hook. Consider using the post-receive hook instead.
-post-receive Hook
+post-receive Hook
-
After all refs were updated (or attempted to be updated), if any
+
After all refs were updated (or attempted to be updated), if any
ref update was successful, and if $GIT_DIR/hooks/post-receive
file exists and is executable, it will be invoke once with no
parameters. The standard input of the hook will be one line
-for each successfully updated ref:
+for each successfully updated ref:
sha1-old SP sha1-new SP refname LF
-
The refname value is relative to $GIT_DIR; e.g. for the master
+
The refname value is relative to $GIT_DIR; e.g. for the master
head this is "refs/heads/master". The two sha1 values before
each refname are the object names for the refname before and after
the update. Refs that were created will have sha1-old equal to
0{40}, while refs that were deleted will have sha1-new equal to
0{40}, otherwise sha1-old and sha1-new should be valid objects in
-the repository.
-
Using this hook, it is easy to generate mails describing the updates
+the repository.
+
Using this hook, it is easy to generate mails describing the updates
to the repository. This example script sends one mail message per
-ref listing the commits pushed to the repository:
+ref listing the commits pushed to the repository:
#!/bin/sh
@@ -387,50 +435,50 @@ do
done
exit 0
-
The exit code from this hook invocation is ignored, however a
-non-zero exit code will generate an error message.
-
Note that it is possible for refname to not have sha1-new when this
+
The exit code from this hook invocation is ignored, however a
+non-zero exit code will generate an error message.
+
Note that it is possible for refname to not have sha1-new when this
hook runs. This can easily occur if another user modifies the ref
-after it was updated by git-receive-pack , but before the hook was able
+after it was updated by git-receive-pack , but before the hook was able
to evaluate it. It is recommended that hooks rely on sha1-new
-rather than the current value of refname.
+rather than the current value of refname.
-post-update Hook
+post-update Hook
-
After all other processing, if at least one ref was updated, and
+
After all other processing, if at least one ref was updated, and
if $GIT_DIR/hooks/post-update file exists and is executable, then
post-update will called with the list of refs that have been updated.
-This can be used to implement any repository wide cleanup tasks.
-
The exit code from this hook invocation is ignored; the only thing
-left for git-receive-pack to do at that point is to exit itself
-anyway.
-
This hook can be used, for example, to run git update-server-info
-if the repository is packed and is served via a dumb transport.
+This can be used to implement any repository wide cleanup tasks.
+
The exit code from this hook invocation is ignored; the only thing
+left for git-receive-pack to do at that point is to exit itself
+anyway.
+
This hook can be used, for example, to run git update-server-info
+if the repository is packed and is served via a dumb transport.
#!/bin/sh
exec git update-server-info
-SEE ALSO
+SEE ALSO
-Author
+Author
-
Written by Linus Torvalds <torvalds@osdl.org>
+
Written by Linus Torvalds <torvalds@osdl.org>
-Documentation
+Documentation
-
Documentation by Junio C Hamano.
+
Documentation by Junio C Hamano.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-receive-pack.txt b/git-receive-pack.txt
index 207684d1c..6b2f8c4de 100644
--- a/git-receive-pack.txt
+++ b/git-receive-pack.txt
@@ -12,23 +12,23 @@ SYNOPSIS
DESCRIPTION
-----------
-Invoked by `git-send-pack` and updates the repository with the
+Invoked by 'git-send-pack' and updates the repository with the
information fed from the remote end.
This command is usually not invoked directly by the end user.
-The UI for the protocol is on the `git-send-pack` side, and the
+The UI for the protocol is on the 'git-send-pack' side, and the
program pair is meant to be used to push updates to remote
repository. For pull operations, see linkgit:git-fetch-pack[1].
The command allows for creation and fast forwarding of sha1 refs
(heads/tags) on the remote end (strictly speaking, it is the
-local end `git-receive-pack` runs, but to the user who is sitting at
+local end 'git-receive-pack' runs, but to the user who is sitting at
the send-pack end, it is updating the remote. Confused?)
There are other real-world examples of using update and
post-update hooks found in the Documentation/howto directory.
-`git-receive-pack` honours the receive.denyNonFastForwards config
+'git-receive-pack' honours the receive.denyNonFastForwards config
option, which tells it if updates to a ref should be denied if they
are not fast-forwards.
@@ -125,7 +125,7 @@ non-zero exit code will generate an error message.
Note that it is possible for refname to not have sha1-new when this
hook runs. This can easily occur if another user modifies the ref
-after it was updated by `git-receive-pack`, but before the hook was able
+after it was updated by 'git-receive-pack', but before the hook was able
to evaluate it. It is recommended that hooks rely on sha1-new
rather than the current value of refname.
@@ -137,7 +137,7 @@ post-update will called with the list of refs that have been updated.
This can be used to implement any repository wide cleanup tasks.
The exit code from this hook invocation is ignored; the only thing
-left for `git-receive-pack` to do at that point is to exit itself
+left for 'git-receive-pack' to do at that point is to exit itself
anyway.
This hook can be used, for example, to run `git update-server-info`
diff --git a/git-reflog.html b/git-reflog.html
index 8fb049cc1..745b5690e 100644
--- a/git-reflog.html
+++ b/git-reflog.html
@@ -3,7 +3,7 @@
-
+
git-reflog(1)
@@ -272,41 +320,43 @@ git-reflog(1) Manual Page
SYNOPSIS
-
git reflog <subcommand> <options>
+
git reflog <subcommand> <options>
-DESCRIPTION
+DESCRIPTION
-
The command takes various subcommands, and different options
-depending on the subcommand:
+
The command takes various subcommands, and different options
+depending on the subcommand:
-
git reflog expire [--dry-run] [--stale-fix] [--verbose]
+
git reflog expire [--dry-run] [--stale-fix] [--verbose]
[--expire=<time>] [--expire-unreachable=<time>] [--all] <refs>…
-
git reflog delete ref@{specifier}…
-
git reflog [show] [log-options] [<ref>]
-
Reflog is a mechanism to record when the tip of branches are
-updated. This command is to manage the information recorded in it.
-
The subcommand "expire" is used to prune older reflog entries.
+
+
+git reflog delete ref@{specifier}…
+
+
+git reflog [show ] [log-options] [<ref>]
+
Reflog is a mechanism to record when the tip of branches are
+updated. This command is to manage the information recorded in it.
+
The subcommand "expire" is used to prune older reflog entries.
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 absence of any
+directly by the end users — instead, see git-gc(1) .
+
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
the reference provided in the command-line (or HEAD , by default).
The reflog will cover all recent actions (HEAD reflog records branch switching
-as well). It is an alias for git log -g --abbrev-commit --pretty=oneline ;
-see git-log(1) .
-
The reflog is useful in various git commands, to specify the old value
+as well). It is an alias for git log -g --abbrev-commit --pretty=oneline ;
+see git-log(1) .
+
The reflog is useful in various git commands, to specify the old value
of a reference. For example, HEAD@{2} means "where HEAD used to be
two moves ago", master@{one.week.ago} means "where master used to
point to one week ago", and so on. See git-rev-parse(1) for
-more details.
-
To delete single entries from the reflog, use the subcommand "delete"
-and specify the _exact_ entry (e.g. “git reflog delete master@{2}”).
+more details.
+
To delete single entries from the reflog, use the subcommand "delete"
+and specify the exact entry (e.g. "git reflog delete master@{2} ").
-
OPTIONS
+
OPTIONS
-
+
--stale-fix
@@ -318,11 +368,11 @@ and specify the _exact_ entry (e.g. “git reflog delete master@{2}”).
objects reachable from it that is not reachable from any of the
refs.
-This computation involves traversing all the reachable objects, i.e. it
-has the same cost as git prune . Fortunately, once this is run, we
+
This computation involves traversing all the reachable objects, i.e. it
+has the same cost as git-prune . Fortunately, once this is run, we
should not have to ever worry about missing objects, because the current
prune and pack-objects know about reflogs and protect objects referred by
-them.
+them.
--expire=<time>
@@ -381,23 +431,23 @@ them.
Print extra information on screen.
-
+
-
Author
+
Author
-
Written by Junio C Hamano <junkio@cox.net>
+
Written by Junio C Hamano <junkio@cox.net>
-
Documentation
+
Documentation
-
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
-
GIT
+
GIT
-
Part of the git(1) suite
+
diff --git a/git-reflog.txt b/git-reflog.txt
index 8492aeacf..146d7f545 100644
--- a/git-reflog.txt
+++ b/git-reflog.txt
@@ -16,12 +16,12 @@ The command takes various subcommands, and different options
depending on the subcommand:
[verse]
-git reflog expire [--dry-run] [--stale-fix] [--verbose]
+'git reflog expire' [--dry-run] [--stale-fix] [--verbose]
[--expire=
] [--expire-unreachable=] [--all] ...
-
-git reflog delete ref@\{specifier\}...
-
-git reflog [show] [log-options] [[]
++
+'git reflog delete' ref@\{specifier\}...
++
+'git reflog' ['show'] [log-options] [][]
Reflog is a mechanism to record when the tip of branches are
updated. This command is to manage the information recorded in it.
@@ -36,7 +36,7 @@ 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
the reference provided in the command-line (or `HEAD`, by default).
The reflog will cover all recent actions (HEAD reflog records branch switching
-as well). It is an alias for 'git log -g --abbrev-commit --pretty=oneline';
+as well). It is an alias for `git log -g --abbrev-commit --pretty=oneline`;
see linkgit:git-log[1].
The reflog is useful in various git commands, to specify the old value
@@ -46,7 +46,7 @@ point to one week ago", and so on. See linkgit:git-rev-parse[1] for
more details.
To delete single entries from the reflog, use the subcommand "delete"
-and specify the _exact_ entry (e.g. ``git reflog delete master@\{2\}'').
+and specify the _exact_ entry (e.g. "`git reflog delete master@\{2\}`").
OPTIONS
@@ -60,7 +60,7 @@ OPTIONS
refs.
+
This computation involves traversing all the reachable objects, i.e. it
-has the same cost as 'git prune'. Fortunately, once this is run, we
+has the same cost as 'git-prune'. Fortunately, once this is run, we
should not have to ever worry about missing objects, because the current
prune and pack-objects know about reflogs and protect objects referred by
them.
diff --git a/git-remote.html b/git-remote.html
index d18790184..49f56d121 100644
--- a/git-remote.html
+++ b/git-remote.html
@@ -3,7 +3,7 @@
]
-
+
git-remote(1)
@@ -274,19 +322,19 @@ git-remote(1) Manual Page
git remote [-v | --verbose]
-git remote add [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>
-git remote rm <name>
-git remote show [-n] <name>
-git remote prune [-n | --dry-run] <name>
-git remote update [group]
+
git remote add [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>
+
git remote rm <name>
+
git remote show [-n] <name>
+
git remote prune [-n | --dry-run] <name>
+
git remote update [group]
-DESCRIPTION
+DESCRIPTION
-
Manage the set of repositories ("remotes") whose branches you track.
+
Manage the set of repositories ("remotes") whose branches you track.
-OPTIONS
+OPTIONS
-
+
-v
@@ -298,13 +346,13 @@ git-remote(1) Manual Page
Be a little more verbose and show remote url after name.
-
+
-COMMANDS
+COMMANDS
-
With no arguments, shows a list of existing remotes. Several
-subcommands are available to perform operations on the remotes.
-
+With no arguments, shows a list of existing remotes. Several
+subcommands are available to perform operations on the remotes.
+
add
@@ -314,21 +362,21 @@ Adds a remote named <name> for the repository at
<url>. The command git fetch <name> can then be used to create and
update remote-tracking branches <name>/<branch>.
-With -f option, git fetch <name> is run immediately after
-the remote information is set up.
-With -t <branch> option, instead of the default glob
+
With -f option, git fetch <name> is run immediately after
+the remote information is set up.
+With -t <branch> option, instead of the default glob
refspec for the remote to track all branches under
$GIT_DIR/remotes/<name>/ , a refspec to track only <branch>
is created. You can give more than one -t <branch> to track
-multiple branches without grabbing all branches.
-
With -m <master> option, $GIT_DIR/remotes/<name>/HEAD is set
+multiple branches without grabbing all branches.
+With -m <master> option, $GIT_DIR/remotes/<name>/HEAD is set
up to point at remote's <master> branch instead of whatever
-branch the HEAD at the remote repository actually points at.
-
In mirror mode, enabled with --mirror , the refs will not be stored
+branch the HEAD at the remote repository actually points at.
+In mirror mode, enabled with --mirror , the refs will not be stored
in the refs/remotes/ namespace, but in refs/heads/ . This option
only makes sense in bare repositories. If a remote uses mirror
mode, furthermore, git push will always behave as if --mirror
-was passed.
+was passed.
rm
@@ -346,8 +394,8 @@ configuration settings for the remote are removed.
Gives some information about the remote <name>.
-With -n option, the remote heads are not queried first with
-git ls-remote <name> ; cached information is used instead.
+With -n option, the remote heads are not queried first with
+git ls-remote <name> ; cached information is used instead.
prune
@@ -359,8 +407,8 @@ These stale branches have already been removed from the remote repository
referenced by <name>, but are still locally available in
"remotes/<name>".
-With --dry-run option, report what branches will be pruned, but do no
-actually prune them.
+With --dry-run option, report what branches will be pruned, but do no
+actually prune them.
update
@@ -375,17 +423,17 @@ configuration parameter remote.<name>.skipDefaultUpdate set to true will
be updated. (See git-config(1) ).
-
+
-DISCUSSION
+DISCUSSION
-
The remote configuration is achieved using the remote.origin.url and
+
The remote configuration is achieved using the remote.origin.url and
remote.origin.fetch configuration variables. (See
-git-config(1) ).
+
git-config(1) ).
-Examples
+Examples
-
+
Add a new remote, fetch, and check out a branch from it
@@ -412,7 +460,7 @@ $ git checkout -b nfs linux-nfs/master
-Imitate git clone but track only selected branches
+Imitate git-clone but track only selected branches
@@ -423,29 +471,29 @@ $ git remote add -f -t master -m master origin git://example.com/git.git/
$ git merge origin
-
+
-SEE ALSO
+SEE ALSO
-Author
+Author
-
Written by Junio Hamano
+
-Documentation
+Documentation
-
Documentation by J. Bruce Fields and the git-list <git@vger.kernel.org>.
+
Documentation by J. Bruce Fields and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-remote.txt b/git-remote.txt
index 32db0aed1..bb99810ec 100644
--- a/git-remote.txt
+++ b/git-remote.txt
@@ -10,11 +10,11 @@ SYNOPSIS
--------
[verse]
'git remote' [-v | --verbose]
-'git remote' add [-t ] [-m ] [-f] [--mirror]
-'git remote' rm
-'git remote' show [-n]
-'git remote' prune [-n | --dry-run]
-'git remote' update [group]
+'git remote add' [-t ] [-m ] [-f] [--mirror]
+'git remote rm'
+'git remote show' [-n]
+'git remote prune' [-n | --dry-run]
+'git remote update' [group]
DESCRIPTION
-----------
@@ -124,7 +124,7 @@ $ git checkout -b nfs linux-nfs/master
...
------------
-* Imitate 'git clone' but track only selected branches
+* Imitate 'git-clone' but track only selected branches
+
------------
$ mkdir project.git
diff --git a/git-repack.html b/git-repack.html
index c2c792ebb..09c39a733 100644
--- a/git-repack.html
+++ b/git-repack.html
@@ -3,7 +3,7 @@
-
+
git-repack(1)
@@ -272,22 +320,22 @@ git-repack(1) Manual Page
SYNOPSIS
-
git repack [-a] [-A] [-d] [-f] [-l] [-n] [-q] [--window=N] [--depth=N]
+
git repack [-a] [-A] [-d] [-f] [-l] [-n] [-q] [--window=N] [--depth=N]
-DESCRIPTION
+DESCRIPTION
-
This script is used to combine all objects that do not currently
+
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-organize
-existing packs into a single, more efficient pack.
-
A pack is a collection of objects, individually compressed, with
+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
-associated index file.
-
Packs are used to reduce the load on mirror systems, backup
-engines, disk storage, etc.
+associated index file.
+
Packs are used to reduce the load on mirror systems, backup
+engines, disk storage, etc.
-OPTIONS
+OPTIONS
-
+
-a
@@ -317,7 +365,7 @@ engines, disk storage, etc.
deleted by way of being left in the old pack and then
removed. Instead, the loose unreachable objects
will be pruned according to normal expiry rules
- with the next git-gc invocation. See git-gc(1) .
+ with the next git-gc invocation. See git-gc(1) .
@@ -327,7 +375,7 @@ engines, disk storage, etc.
After packing, if the newly created packs make some
existing packs redundant, remove the redundant packs.
- Also run git-prune-packed to remove redundant
+ Also run git-prune-packed to remove redundant
loose object files.
@@ -336,7 +384,7 @@ engines, disk storage, etc.
- Pass the --local option to git-pack-objects . See
+ Pass the --local option to git-pack-objects . See
git-pack-objects(1) .
@@ -345,7 +393,7 @@ engines, disk storage, etc.
- Pass the --no-reuse-delta option to git-pack-objects . See
+ Pass the --no-reuse-delta option to git-pack-objects . See
git-pack-objects(1) .
@@ -354,7 +402,7 @@ engines, disk storage, etc.
- Pass the -q option to git-pack-objects . See
+ Pass the -q option to git-pack-objects . See
git-pack-objects(1) .
@@ -364,10 +412,10 @@ engines, disk storage, etc.
Do not update the server information with
- git-update-server-info . This option skips
+ git-update-server-info . This option skips
updating local catalog files needed to publish
this repository (or a direct copy of it)
- over HTTP or FTP. See .
+ over HTTP or FTP. See git-update-server-info(1) .
@@ -414,40 +462,40 @@ engines, disk storage, etc.
The default is unlimited.
-
+
-Configuration
+Configuration
-
When configuration variable repack.UseDeltaBaseOffset is set
+
When configuration variable repack.UseDeltaBaseOffset is set
for the repository, the command passes --delta-base-offset
-option to git-pack-objects ; this typically results in slightly
+option to git-pack-objects ; this typically results in slightly
smaller packs, but the generated packs are incompatible with
versions of git older than (and including) v1.4.3; do not set
the variable in a repository that older version of git needs to
be able to read (this includes repositories from which packs can
be copied out over http or rsync, and people who obtained packs
-that way can try to use older git with it).
+that way can try to use older git with it).
-Author
+Author
-
Written by Linus Torvalds <torvalds@osdl.org>
+
Written by Linus Torvalds <torvalds@osdl.org>
-Documentation
+Documentation
-
Documentation by Ryan Anderson <ryan@michonline.com>
+
Documentation by Ryan Anderson <ryan@michonline.com>
-SEE ALSO
+SEE ALSO
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-repack.txt b/git-repack.txt
index 0d72e8302..38ac60947 100644
--- a/git-repack.txt
+++ b/git-repack.txt
@@ -47,32 +47,32 @@ OPTIONS
deleted by way of being left in the old pack and then
removed. Instead, the loose unreachable objects
will be pruned according to normal expiry rules
- with the next `git-gc` invocation. See linkgit:git-gc[1].
+ with the next 'git-gc' invocation. See linkgit:git-gc[1].
-d::
After packing, if the newly created packs make some
existing packs redundant, remove the redundant packs.
- Also run `git-prune-packed` to remove redundant
+ Also run 'git-prune-packed' to remove redundant
loose object files.
-l::
- Pass the `--local` option to `git-pack-objects`. See
+ Pass the `--local` option to 'git-pack-objects'. See
linkgit:git-pack-objects[1].
-f::
- Pass the `--no-reuse-delta` option to `git-pack-objects`. See
+ Pass the `--no-reuse-delta` option to 'git-pack-objects'. See
linkgit:git-pack-objects[1].
-q::
- Pass the `-q` option to `git-pack-objects`. See
+ Pass the `-q` option to 'git-pack-objects'. See
linkgit:git-pack-objects[1].
-n::
Do not update the server information with
- `git-update-server-info`. This option skips
+ 'git-update-server-info'. This option skips
updating local catalog files needed to publish
this repository (or a direct copy of it)
- over HTTP or FTP. See gitlink:git-update-server-info[1].
+ over HTTP or FTP. See linkgit:git-update-server-info[1].
--window=[N]::
--depth=[N]::
@@ -107,7 +107,7 @@ Configuration
When configuration variable `repack.UseDeltaBaseOffset` is set
for the repository, the command passes `--delta-base-offset`
-option to `git-pack-objects`; this typically results in slightly
+option to 'git-pack-objects'; this typically results in slightly
smaller packs, but the generated packs are incompatible with
versions of git older than (and including) v1.4.3; do not set
the variable in a repository that older version of git needs to
diff --git a/git-rerere.html b/git-rerere.html
index fab9d72ec..9c5b43a0b 100644
--- a/git-rerere.html
+++ b/git-rerere.html
@@ -3,7 +3,7 @@
-
+
git-rerere(1)
@@ -272,18 +320,18 @@ git-rerere(1) Manual Page
SYNOPSIS
-
git rerere [clear|diff|status|gc]
+
git rerere [clear |diff |status |gc ]
-DESCRIPTION
+DESCRIPTION
-
In a workflow that employs relatively long lived topic branches,
+
In a workflow that employs relatively long lived topic branches,
the developer sometimes needs to resolve the same conflict over
and over again until the topic branches are done (either merged
-to the "release" branch, or sent out and accepted upstream).
-
This command helps this process by recording conflicted
+to the "release" branch, or sent out and accepted upstream).
+
This command helps this process by recording conflicted
automerge results and corresponding hand-resolve results on the
initial manual merge, and later by noticing the same automerge
-results and applying the previously recorded hand resolution.
+results and applying the previously recorded hand resolution.
@@ -294,19 +342,19 @@ enable this command.
-COMMANDS
+COMMANDS
-
Normally, git-rerere is run without arguments or user-intervention.
+
Normally, git-rerere is run without arguments or user-intervention.
However, it has several commands that allow it to interact with
-its working state.
-
+its working state.
+
clear
This resets the metadata used by rerere if a merge resolution is to be
-is aborted. Calling git-am --skip or git-rebase [--skip|--abort]
+is aborted. Calling git-am --skip or git-rebase [--skip|--abort]
will automatically invoke this command.
@@ -318,7 +366,7 @@ will automatically invoke this command.
This displays diffs for the current state of the resolution. It is
useful for tracking what has changed while the user is resolving
conflicts. Additional arguments are passed directly to the system
-diff command installed in PATH.
+diff command installed in PATH.
@@ -326,7 +374,7 @@ conflicts. Additional arguments are passed directly to the system
-Like diff, but this only prints the filenames that will be tracked
+Like diff , but this only prints the filenames that will be tracked
for resolutions.
@@ -343,22 +391,22 @@ older than 60 days, are pruned. These are controlled with
variables.
-
+
-DISCUSSION
+DISCUSSION
-
When your topic branch modifies overlapping area that your
+
When your topic branch modifies overlapping area that your
master branch (or upstream) touched since your topic branch
forked from it, you may want to test it with the latest master,
-even before your topic branch is ready to be pushed upstream:
+even before your topic branch is ready to be pushed upstream:
o---*---o topic
/
o---o---o---*---o---o master
-
For such a test, you need to merge master and topic somehow.
-One way to do it is to pull master into the topic branch:
+
For such a test, you need to merge master and topic somehow.
+One way to do it is to pull master into the topic branch:
$ git checkout topic
@@ -368,17 +416,17 @@ One way to do it is to pull master into the topic branch:
/ /
o---o---o---*---o---o master
-
The commits marked with * touch the same area in the same
+
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
-work-in-progress still works with what is in the latest master.
-
After this test merge, there are two ways to continue your work
+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 + ,
-in which case the final commit graph would look like this:
+the upstream might have been advanced since the test merge
,
+in which case the final commit graph would look like this:
$ git checkout topic
@@ -391,15 +439,15 @@ in which case the final commit graph would look like this:
/ / \
o---o---o---*---o---o---o---o---+ master
-
When your topic branch is long-lived, however, your topic branch
+
When your topic branch is long-lived, however, your topic branch
would end up having many such "Merge from master" commits on it,
which would unnecessarily clutter the development history.
Readers of the Linux kernel mailing list may remember that Linus
complained about such too frequent test merges when a subsystem
-maintainer asked to pull from a branch full of "useless merges".
-
As an alternative, to keep the topic branch clean of test
+maintainer asked to pull from a branch full of "useless merges".
+
As an alternative, to keep the topic branch clean of test
merges, you could blow away the test merge, and keep building on
-top of the tip before the test merge:
+top of the tip before the test merge:
$ git checkout topic
@@ -413,45 +461,45 @@ top of the tip before the test merge:
/ \
o---o---o---*---o---o---o---o---+ master
-
This would leave only one merge commit when your topic branch is
+
This would leave only one merge commit when your topic branch is
finally ready and merged into the master branch. This merge
would require you to resolve the conflict, introduced by the
commits marked with * . However, often this conflict is the
same conflict you resolved when you created the test merge you
-blew away. git-rerere command helps you to resolve this final
+blew away. git-rerere command helps you to resolve this final
conflicted merge using the information from your earlier hand
-resolve.
-
Running the git-rerere command immediately after a conflicted
+resolve.
+
Running the git-rerere command immediately after a conflicted
automerge records the conflicted working tree files, with the
usual conflict markers <<<<<<< , ======= , and >>>>>>> in
them. Later, after you are done resolving the conflicts,
-running git-rerere again records the resolved state of these
+running git-rerere again records the resolved state of these
files. Suppose you did this when you created the test merge of
-master into the topic branch.
-
Next time, running git-rerere after seeing a conflicted
+master into the topic branch.
+
Next time, running git-rerere after seeing a conflicted
automerge, if the conflict is the same as the earlier one
recorded, it is noticed and a three-way merge between the
earlier conflicted automerge, the earlier manual resolution, and
the current conflicted automerge is performed by the command.
If this three-way merge resolves cleanly, the result is written
out to your working tree file, so you would not have to manually
-resolve it. Note that git-rerere leaves the index file alone,
+resolve it. Note that git-rerere leaves the index file alone,
so you still need to do the final sanity checks with git diff
-(or git diff -c ) and git add when you are satisfied.
-
As a convenience measure, git-merge automatically invokes
-git-rerere when it exits with a failed automerge, which
+(or git diff -c ) and git-add when you are satisfied.
+
As a convenience measure, git-merge automatically invokes
+git-rerere when it exits with a failed automerge, which
records it if it is a new conflict, or reuses the earlier hand
-resolve when it is not. git-commit also invokes git-rerere
+resolve when it is not. git-commit also invokes git-rerere
when recording a merge result. What this means is that you do
not have to do anything special yourself (Note: you still have
-to set the config variable rerere.enabled to enable this command).
-
In our example, when you did the test merge, the manual
+to set the config variable rerere.enabled to enable this command).
+
In our example, when you did the test merge, the manual
resolution is recorded, and it will be reused when you do the
actual merge later with updated master and topic branch, as long
-as the earlier resolution is still applicable.
-
The information git-rerere records is also used when running
-git-rebase . After blowing away the test merge and continuing
-development on the topic branch:
+as the earlier resolution is still applicable.
+
The information git-rerere records is also used when running
+git-rebase . After blowing away the test merge and continuing
+development on the topic branch:
o---*---o-------o---o topic
@@ -464,24 +512,24 @@ development on the topic branch:
/
o---o---o---*---o---o---o---o master
-
you could run git rebase master topic , to keep yourself
+
you could run git rebase master topic , to keep yourself
up-to-date even before your topic is ready to be sent upstream.
This would result in falling back to three-way merge, and it
would conflict the same way the test merge you resolved earlier.
-git-rerere is run by git-rebase to help you resolve this
-conflict.
+
git-rerere is run by
git-rebase to help you resolve this
+conflict.
-Author
+Author
-
Written by Junio C Hamano <junkio@cox.net>
+
Written by Junio C Hamano <junkio@cox.net>
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-rerere.txt b/git-rerere.txt
index 345802904..678bfd3cd 100644
--- a/git-rerere.txt
+++ b/git-rerere.txt
@@ -7,7 +7,7 @@ git-rerere - Reuse recorded resolution of conflicted merges
SYNOPSIS
--------
-'git rerere' [clear|diff|status|gc]
+'git rerere' ['clear'|'diff'|'status'|'gc']
DESCRIPTION
-----------
@@ -30,14 +30,14 @@ enable this command.
COMMANDS
--------
-Normally, `git-rerere` is run without arguments or user-intervention.
+Normally, 'git-rerere' is run without arguments or user-intervention.
However, it has several commands that allow it to interact with
its working state.
'clear'::
This resets the metadata used by rerere if a merge resolution is to be
-is aborted. Calling `git-am --skip` or `git-rebase [--skip|--abort]`
+is aborted. Calling 'git-am --skip' or 'git-rebase [--skip|--abort]'
will automatically invoke this command.
'diff'::
@@ -45,11 +45,11 @@ will automatically invoke this command.
This displays diffs for the current state of the resolution. It is
useful for tracking what has changed while the user is resolving
conflicts. Additional arguments are passed directly to the system
-`diff` command installed in PATH.
+'diff' command installed in PATH.
'status'::
-Like diff, but this only prints the filenames that will be tracked
+Like 'diff', but this only prints the filenames that will be tracked
for resolutions.
'gc'::
@@ -142,33 +142,33 @@ finally ready and merged into the master branch. This merge
would require you to resolve the conflict, introduced by the
commits marked with `*`. However, often this conflict is the
same conflict you resolved when you created the test merge you
-blew away. `git-rerere` command helps you to resolve this final
+blew away. 'git-rerere' command helps you to resolve this final
conflicted merge using the information from your earlier hand
resolve.
-Running the `git-rerere` command immediately after a conflicted
+Running the 'git-rerere' command immediately after a conflicted
automerge records the conflicted working tree files, with the
usual conflict markers `<<<<<<<`, `=======`, and `>>>>>>>` in
them. Later, after you are done resolving the conflicts,
-running `git-rerere` again records the resolved state of these
+running 'git-rerere' again records the resolved state of these
files. Suppose you did this when you created the test merge of
master into the topic branch.
-Next time, running `git-rerere` after seeing a conflicted
+Next time, running 'git-rerere' after seeing a conflicted
automerge, if the conflict is the same as the earlier one
recorded, it is noticed and a three-way merge between the
earlier conflicted automerge, the earlier manual resolution, and
the current conflicted automerge is performed by the command.
If this three-way merge resolves cleanly, the result is written
out to your working tree file, so you would not have to manually
-resolve it. Note that `git-rerere` leaves the index file alone,
+resolve it. Note that 'git-rerere' leaves the index file alone,
so you still need to do the final sanity checks with `git diff`
-(or `git diff -c`) and `git add` when you are satisfied.
+(or `git diff -c`) and 'git-add' when you are satisfied.
-As a convenience measure, `git-merge` automatically invokes
-`git-rerere` when it exits with a failed automerge, which
+As a convenience measure, 'git-merge' automatically invokes
+'git-rerere' when it exits with a failed automerge, which
records it if it is a new conflict, or reuses the earlier hand
-resolve when it is not. `git-commit` also invokes `git-rerere`
+resolve when it is not. 'git-commit' also invokes 'git-rerere'
when recording a merge result. What this means is that you do
not have to do anything special yourself (Note: you still have
to set the config variable rerere.enabled to enable this command).
@@ -178,8 +178,8 @@ resolution is recorded, and it will be reused when you do the
actual merge later with updated master and topic branch, as long
as the earlier resolution is still applicable.
-The information `git-rerere` records is also used when running
-`git-rebase`. After blowing away the test merge and continuing
+The information 'git-rerere' records is also used when running
+'git-rebase'. After blowing away the test merge and continuing
development on the topic branch:
------------
@@ -198,7 +198,7 @@ you could run `git rebase master topic`, to keep yourself
up-to-date even before your topic is ready to be sent upstream.
This would result in falling back to three-way merge, and it
would conflict the same way the test merge you resolved earlier.
-`git-rerere` is run by `git-rebase` to help you resolve this
+'git-rerere' is run by 'git-rebase' to help you resolve this
conflict.
diff --git a/git-reset.html b/git-reset.html
index dde5e3248..980c50b9e 100644
--- a/git-reset.html
+++ b/git-reset.html
@@ -3,7 +3,7 @@
-
+
git-reset(1)
@@ -276,21 +324,21 @@ git-reset(1) Manual Page
git reset [--mixed | --soft | --hard] [-q] [<commit>]
git reset [-q] [<commit>] [--] <paths>…
-DESCRIPTION
+DESCRIPTION
-
Sets the current head to the specified commit and optionally resets the
-index and working tree to match.
-
This command is useful if you notice some small error in a recent
+
Sets the current head to the specified commit and optionally resets the
+index and working tree to match.
+
This command is useful if you notice some small error in a recent
commit (or set of commits) and want to redo that part without showing
-the undo in the history.
-
If you want to undo a commit other than the latest on a branch,
-git-revert(1) is your friend.
-
The second form with paths is used to revert selected paths in
-the index from a given commit, without moving HEAD.
+the undo in the history.
+
If you want to undo a commit other than the latest on a branch,
+git-revert(1) is your friend.
+
The second form with paths is used to revert selected paths in
+the index from a given commit, without moving HEAD.
-OPTIONS
+OPTIONS
-
+
--mixed
@@ -308,7 +356,7 @@ the index from a given commit, without moving HEAD.
Does not touch the index file nor the working tree at all, but
requires them to be in a good order. This leaves all your changed
- files "Changes to be committed", as git-status would
+ files "Changes to be committed", as git-status would
put it.
@@ -338,11 +386,11 @@ the index from a given commit, without moving HEAD.
Commit to make the current HEAD. If not given defaults to HEAD.
-
+
-Examples
+Examples
-
+
Undo a commit and redo
@@ -354,7 +402,7 @@ $ git reset --soft HEAD^ (1)
$ edit (2)
$ git commit -a -c ORIG_HEAD (3)
-
+
This is most often done when you remembered what you
@@ -373,9 +421,9 @@ Make corrections to working tree files.
commit by starting with its log message. If you do not need to
edit the message further, you can give -C option instead.
-See also the --amend option to git-commit(1) .
+
-
+
Undo commits permanently
@@ -386,7 +434,7 @@ Undo commits permanently
$ git commit ...
$ git reset --hard HEAD~3 (1)
-
+
The last three commits (HEAD, HEAD^, and HEAD~2) were bad
@@ -394,7 +442,7 @@ and you do not want to ever see them again. Do not do this if
you have already given these commits to somebody else.
-
+
Undo a commit, making it a topic branch
@@ -406,7 +454,7 @@ Undo a commit, making it a topic branch
$ git reset --hard HEAD~3 (2)
$ git checkout topic/wip (3)
-
+
You have made some commits, but realize they were premature
@@ -425,7 +473,7 @@ Rewind the master branch to get rid of those three commits.
Switch to "topic/wip" branch and keep working.
-
+
Undo add
@@ -439,7 +487,7 @@ $ mailx (2)
$ git reset (3)
$ git pull git://info.example.com/ nitfol (4)
-
+
You are happily working on something, and find the changes
@@ -468,7 +516,7 @@ Then you can pull and merge, leaving frotz.c and filfre.c
changes still in the working tree.
-
+
Undo a merge or pull
@@ -486,7 +534,7 @@ Updating from 41223... to 13134...
Fast forward
$ git reset --hard ORIG_HEAD (4)
-
+
Try to update from the upstream resulted in a lot of
@@ -516,16 +564,16 @@ brings your index file and the working tree back to that state,
and resets the tip of the branch to that commit.
-
+
Interrupted workflow
-Suppose you are interrupted by an urgent fix request while you
+
Suppose you are interrupted by an urgent fix request while you
are in the middle of a large change. The files in your
working tree are not in any shape to be committed yet, but you
-need to get to the other branch for a quick bugfix.
+need to get to the other branch for a quick bugfix.
$ git checkout feature ;# you were working in "feature" branch and
@@ -538,7 +586,7 @@ $ git checkout feature
$ git reset --soft HEAD^ ;# go back to WIP state (2)
$ git reset (3)
-
+
This commit will get blown away so a throw-away log message is OK.
@@ -557,22 +605,22 @@ At this point the index file still has all the WIP changes you
WIP files as uncommitted.
-
+
Reset a single file in the index
-Suppose you have added a file to your index, but later decide you do not
+
Suppose you have added a file to your index, but later decide you do not
want to add it to your commit. You can remove the file from the index
-while keeping your changes with git reset.
+while keeping your changes with git reset.
$ git reset -- frotz.c (1)
$ git commit -m "Commit files in index" (2)
$ git add frotz.c (3)
-
+
This removes the file from the index while keeping it in the working
@@ -589,25 +637,25 @@ This commits all other changes in the index.
Adds the file to the index again.
-
+
-
+
-Author
+Author
-
Written by Junio C Hamano <junkio@cox.net> and Linus Torvalds <torvalds@osdl.org>
+
Written by Junio C Hamano <junkio@cox.net> and Linus Torvalds <torvalds@osdl.org>
-Documentation
+Documentation
-
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-reset.txt b/git-reset.txt
index dc05f58f1..c8d175768 100644
--- a/git-reset.txt
+++ b/git-reset.txt
@@ -37,7 +37,7 @@ OPTIONS
--soft::
Does not touch the index file nor the working tree at all, but
requires them to be in a good order. This leaves all your changed
- files "Changes to be committed", as `git-status` would
+ files "Changes to be committed", as 'git-status' would
put it.
--hard::
diff --git a/git-rev-list.html b/git-rev-list.html
index 5a94c9116..29ad5b374 100644
--- a/git-rev-list.html
+++ b/git-rev-list.html
@@ -3,7 +3,7 @@
-
+
git-rev-list(1)
@@ -311,49 +359,49 @@ git-rev-list(1) Manual Page
[ --no-walk ] [ --do-walk ]
<commit>… [ -- <paths>… ]
-DESCRIPTION
+DESCRIPTION
-
Lists commit objects in reverse chronological order starting at the
+
Lists commit objects in reverse chronological order starting at the
given commit(s), taking ancestry relationship into account. This is
-useful to produce human-readable log output.
-
Commits which are stated with a preceding ^ cause listing to
+useful to produce human-readable log output.
+
Commits which are stated with a preceding ^ cause listing to
stop at that point. Their parents are implied. Thus the following
-command:
+command:
$ git rev-list foo bar ^baz
-
means "list all the commits which are included in foo and bar , but
-not in baz ".
-
A special notation "<commit1> ..<commit2> " can be used as a
+
means "list all the commits which are included in foo and bar , but
+not in baz ".
+
A special notation "<commit1> ..<commit2> " can be used as a
short-hand for "^<commit1> <commit2> ". For example, either of
-the following may be used interchangeably:
+the following may be used interchangeably:
$ git rev-list origin..HEAD
$ git rev-list HEAD ^origin
-
Another special notation is "<commit1> …<commit2> " which is useful
+
Another special notation is "<commit1> …<commit2> " which is useful
for merges. The resulting set of commits is the symmetric difference
-between the two operands. The following two commands are equivalent:
+between the two operands. The following two commands are equivalent:
$ git rev-list A B --not $(git merge-base --all A B)
$ git rev-list A...B
-
git-rev-list is a very essential git program, since it
+
git-rev-list is a very essential git program, since it
provides the ability to build and traverse commit ancestry graphs. For
this reason, it has a lot of different options that enables it to be
-used by commands as different as git-bisect and
-git-repack .
+used by commands as different as
git-bisect and
+
git-repack .
-OPTIONS
+OPTIONS
-
Commit Formatting
-
Using these options, git-rev-list(1) will act similar to the
+
+
+
--pretty[=<format> ]
@@ -364,8 +412,8 @@ more specialized family of commit log tools: git-log(1)
full , fuller , email , raw and format:<string> .
When omitted, the format defaults to medium .
-Note: you can specify the default pretty format in the repository
-configuration (see git-config(1) ).
+Note: you can specify the default pretty format in the repository
+configuration (see git-config(1) ).
--abbrev-commit
@@ -377,8 +425,8 @@ configuration (see git-config(1) ).
digits can be specified with "--abbrev=<n>" (which also modifies
diff output, if it is displayed).
-This should make "--pretty=oneline" a whole lot more readable for
-people using 80-column terminals.
+This should make "--pretty=oneline" a whole lot more readable for
+people using 80-column terminals.
--encoding[=<encoding>]
@@ -409,15 +457,15 @@ people using 80-column terminals.
as when using "--pretty". log.date config variable sets a default
value for log command's --date option.
---date=relative shows dates relative to the current time,
-e.g. "2 hours ago".
---date=local shows timestamps in user's local timezone.
---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 format.
---date=default shows timestamps in the original timezone
-(either committer's or author's).
+--date=relative shows dates relative to the current time,
+e.g. "2 hours ago".
+--date=local shows timestamps in user's local timezone.
+--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 format.
+--date=default shows timestamps in the original timezone
+(either committer's or author's).
--header
@@ -454,7 +502,7 @@ format, often found in E-mail messages.
the right with > . If combined with --boundary , those
commits are prefixed with - .
-For example, if you have this topology:
+For example, if you have this topology:
y---b---b branch B
@@ -463,7 +511,7 @@ format, often found in E-mail messages.
/ / \
o---x---a---a branch A
-you would get an output line this:
+you would get an output line this:
$ git rev-list --left-right --boundary --pretty=oneline A...B
@@ -486,15 +534,15 @@ format, often found in E-mail messages.
to be printed in between commits, in order for the graph history
to be drawn properly.
- This implies the --topo-order option by default, but the
---date-order option may also be specified.
+This implies the --topo-order option by default, but the
+--date-order option may also be specified.
-
-Diff Formatting
-Below are listed options that control the formatting of diff output.
+
+
+
Below are listed options that control the formatting of diff output.
Some of them are specific to git-rev-list(1) , however other diff
-options may be given. See git-diff-files(1) for more options.
-
+options may be given. See git-diff-files(1) for more options.
+
-c
@@ -534,12 +582,12 @@ options may be given. See git-diff-files(1) fo
Show the tree objects in the diff output. This implies -r .
-
-
Commit Limiting
-
Besides specifying a range of commits that should be listed using the
+
+
Commit Limiting
+
Besides specifying a range of commits that should be listed using the
special notations explained in the description, additional commit
-limiting may be applied.
-
+limiting may be applied.
+
-n number
@@ -766,8 +814,8 @@ used in the output. When the starting commit is specified as
instead. Under --pretty=oneline , the commit message is
prefixed with this information on the same line.
-Cannot be combined with --reverse .
-See also git-reflog(1) .
+
--merge
@@ -799,9 +847,9 @@ When optional paths are given, the default behaviour (--dense ) is to
only output commits that changes at least one of them, and also ignore
merges that do not touch the given paths.
-Use the --sparse flag to makes the command output all eligible commits
+
Use the --sparse flag to makes the command output all eligible commits
(still subject to count and age limitation), but apply merge
-simplification nevertheless.
+simplification nevertheless.
--bisect
@@ -815,16 +863,16 @@ the included and excluded commits. Thus, if
$ git-rev-list --bisect foo ^bar ^baz
-
outputs midpoint , the output of the two commands
+
outputs midpoint , the output of the two commands
$ git-rev-list foo ^midpoint
$ git-rev-list midpoint ^bar ^baz
-
would be of roughly the same length. Finding the change which
+
would be of roughly the same length. Finding the change which
introduces a regression is thus reduced to a binary search: repeatedly
generate and test new 'midpoint's until the commit chain is of length
-one.
+one.
--bisect-vars
@@ -852,17 +900,17 @@ commits, ordered by their distance to the included and excluded
commits. The farthest from them is displayed first. (This is the only
one displayed by --bisect .)
-This is useful because it makes it easy to choose a good commit to
+
This is useful because it makes it easy to choose a good commit to
test when you want to avoid to test some of them for some reason (they
-may not compile for example).
-
This option can be used along with --bisect-vars , in this case,
+may not compile for example).
+This option can be used along with --bisect-vars , in this case,
after all the sorted commit objects, there will be the same text as if
---bisect-vars had been used alone.
+
--bisect-vars had been used alone.
-
-Commit Ordering
-By default, the commits are shown in reverse chronological order.
-
+
+Commit Ordering
+By default, the commits are shown in reverse chronological order.
+
--topo-order
@@ -891,10 +939,10 @@ after all the sorted commit objects, there will be the same text as if
Cannot be combined with --walk-reflogs .
-
-
Object Traversal
-
These options are mostly targeted for packing of git repositories.
-
+
+Object Traversal
+These options are mostly targeted for packing of git repositories.
+
--objects
@@ -943,11 +991,11 @@ after all the sorted commit objects, there will be the same text as if
Overrides a previous --no-walk.
-
+
-
PRETTY FORMATS
+
-
If the commit is a merge, and if the pretty-format
+
If the commit is a merge, and if the pretty-format
is not oneline , email or raw , an additional line is
inserted before the Author: line. This line begins with
"Merge: " and the sha1s of ancestral commits are printed,
@@ -955,9 +1003,9 @@ separated by spaces. Note that the listed commits may not
necessarily be the list of the direct parent commits if you
have limited your view of history: for example, if you are
only interested in changes related to a certain directory or
-file.
-
Here are some additional details for each format:
-
+
Here are some additional details for each format:
+
-
This is designed to be as compact as possible.
+
This is designed to be as compact as possible.
@@ -990,7 +1038,7 @@ Author: <author>
commit <sha1>
Author: <author>
-Date: <date>
+Date: <author date>
@@ -1028,9 +1076,9 @@ Commit: <committer>
commit <sha1>
Author: <author>
-AuthorDate: <date & time>
+AuthorDate: <author date>
Commit: <committer>
-CommitDate: <date & time>
+CommitDate: <committer date>
@@ -1049,7 +1097,7 @@ CommitDate: <date & time>
From <sha1> <date>
From: <author>
-Date: <date & time>
+Date: <author date>
Subject: [PATCH] <title line>
@@ -1061,31 +1109,31 @@ Subject: [PATCH] <title line>
raw
-
The raw format shows the entire commit exactly as
+
The raw format shows the entire commit exactly as
stored in the commit object. Notably, the SHA1s are
displayed in full, regardless of whether --abbrev or
--no-abbrev are used, and parents information show the
true parent commits, without taking grafts nor history
-simplification into account.
+simplification into account.
format:
-The format: format allows you to specify which information
+
The format: format allows you to specify which information
you want to show. It works a little bit like printf format,
with the notable exception that you get a newline with %n
-instead of \n .
-
E.g, format:"The author of %h was %an, %ar%nThe title was >>%s<<%n"
-would show something like this:
+instead of
\n .
+E.g, format:"The author of %h was %an, %ar%nThe title was >>%s<<%n"
+would show something like this:
The author of fe6e0ee was Junio C Hamano, 23 hours ago
The title was >>t4119: test autocomputing -p<n> for traditional diff input.<<
-The placeholders are:
-
tformat:
-The tformat: format works exactly like format: , except that it
+
The tformat: format works exactly like format: , except that it
provides "terminator" semantics instead of "separator" semantics. In
other words, each commit has the message terminator character (usually a
newline) appended, rather than a separator placed between entries.
This means that the final entry of a single-line format will be properly
terminated with a new line, just as the "oneline" format does.
-For example:
+For example:
$ git log -2 --pretty=format:%h 4da45bef \
@@ -1262,24 +1310,24 @@ $ git log -2 --pretty=tformat:%h 4da45bef \
7134973
-
+
-
Author
+
Author
-
Written by Linus Torvalds <torvalds@osdl.org>
+
Written by Linus Torvalds <torvalds@osdl.org>
-
Documentation
+
Documentation
-
Documentation by David Greaves, Junio C Hamano, Jonas Fonseca
-and the git-list <git@vger.kernel.org>.
+
Documentation by David Greaves, Junio C Hamano, Jonas Fonseca
+and the git-list <git@vger.kernel.org>.
-
GIT
+
GIT
-
Part of the git(1) suite
+
diff --git a/git-rev-list.txt b/git-rev-list.txt
index e7d736ffa..fd1de92e3 100644
--- a/git-rev-list.txt
+++ b/git-rev-list.txt
@@ -83,11 +83,11 @@ between the two operands. The following two commands are equivalent:
$ git rev-list A...B
-----------------------------------------------------------------------
-`git-rev-list` is a very essential git program, since it
+'git-rev-list' is a very essential git program, since it
provides the ability to build and traverse commit ancestry graphs. For
this reason, it has a lot of different options that enables it to be
-used by commands as different as `git-bisect` and
-`git-repack`.
+used by commands as different as 'git-bisect' and
+'git-repack'.
OPTIONS
-------
diff --git a/git-rev-parse.html b/git-rev-parse.html
index 0286d4fa9..54309af0a 100644
--- a/git-rev-parse.html
+++ b/git-rev-parse.html
@@ -3,7 +3,7 @@
-
+
git-rev-parse(1)
@@ -272,26 +320,26 @@ git-rev-parse(1) Manual Page
SYNOPSIS
-
git rev-parse [ --option ] <args>…
+
git rev-parse [ --option ] <args>…
-
DESCRIPTION
+
DESCRIPTION
-
Many git porcelainish commands take mixture of flags
+
Many git porcelainish commands take mixture of flags
(i.e. parameters that begin with a dash - ) and parameters
-meant for the underlying git-rev-list command they use internally
+meant for the underlying git-rev-list command they use internally
and flags and parameters for the other commands they use
-downstream of git-rev-list . This command is used to
-distinguish between them.
+downstream of
git-rev-list . This command is used to
+distinguish between them.
-
OPTIONS
+
OPTIONS
-
+
--parseopt
- Use git-rev-parse in option parsing mode (see PARSEOPT section below).
+ Use git-rev-parse in option parsing mode (see PARSEOPT section below).
@@ -309,7 +357,7 @@ distinguish between them.
Do not output flags and parameters not meant for
- git-rev-list command.
+ git-rev-list command.
@@ -318,7 +366,7 @@ distinguish between them.
Do not output flags and parameters meant for
- git-rev-list command.
+ git-rev-list command.
@@ -378,7 +426,7 @@ distinguish between them.
properly quoted for consumption by shell. Useful when
you expect your parameter to contain whitespaces and
newlines (e.g. when using pickaxe -S with
- git-diff-* ).
+ git-diff-* ).
@@ -522,7 +570,7 @@ distinguish between them.
Parse the date string, and output the corresponding
- --max-age= parameter for git-rev-list .
+ --max-age= parameter for git-rev-list .
@@ -534,7 +582,7 @@ distinguish between them.
Parse the date string, and output the corresponding
- --min-age= parameter for git-rev-list .
+ --min-age= parameter for git-rev-list .
@@ -545,16 +593,16 @@ distinguish between them.
Flags and parameters to be parsed.
-
+
-
SPECIFYING REVISIONS
+
SPECIFYING REVISIONS
-
A revision parameter typically, but not necessarily, names a
+
A revision parameter typically, but not necessarily, names a
commit object. They use what is called an extended SHA1
syntax. Here are various ways to spell object names. The
ones listed near the end of this list are to name trees and
-blobs contained in a commit.
-
+blobs contained in a commit.
+
The full SHA1 object name (40-byte hexadecimal string), or
@@ -566,7 +614,7 @@ The full SHA1 object name (40-byte hexadecimal string), or
-An output from git-describe ; i.e. a closest tag, followed by a
+An output from git-describe ; i.e. a closest tag, followed by a
dash, a g , and an abbreviated object name.
@@ -579,7 +627,7 @@ A symbolic ref name. E.g. master typically means the commit
When ambiguous, a <name> is disambiguated by taking the
first match in the following rules:
-
+
if $GIT_DIR/<name> exists, that is what you mean (this is usually
@@ -611,7 +659,7 @@ otherwise, $GIT_DIR/refs/remotes/<name> if exists;
otherwise, $GIT_DIR/refs/remotes/<name>/HEAD if exists.
-
+
@@ -711,10 +759,10 @@ A colon, optionally followed by a stage number (0 to 3) and a
the branch being merged.
-
-
Here is an illustration, by Jon Loeliger. Both commit nodes B
+
+
Here is an illustration, by Jon Loeliger. Both commit nodes B
and C are parents of commit node A. Parent commits are ordered
-left-to-right.
+left-to-right.
G H I J
@@ -742,31 +790,31 @@ I = F^ = B^3^ = A^^3^
J = F^2 = B^3^2 = A^^3^2
-
SPECIFYING RANGES
+
SPECIFYING RANGES
-
History traversing commands such as git-log operate on a set
+
History traversing commands such as git-log operate on a set
of commits, not just a single commit. To these commands,
specifying a single revision with the notation described in the
previous section means the set of commits reachable from that
-commit, following the commit ancestry chain.
-
To exclude commits reachable from a commit, a prefix ^
+commit, following the commit ancestry chain.
+
To exclude commits reachable from a commit, a prefix ^
notation is used. E.g. "^r1 r2 " means commits reachable
-from r2 but exclude the ones reachable from r1 .
-
This set operation appears so often that there is a shorthand
+from r2 but exclude the ones reachable from r1 .
+
This set operation appears so often that there is a shorthand
for it. "r1..r2 " is equivalent to "^r1 r2 ". It is
the difference of two sets (subtract the set of commits
reachable from r1 from the set of commits reachable from
-r2 ).
-
A similar notation "r1...r2 " is called symmetric difference
+r2 ).
+
A similar notation "r1...r2 " is called symmetric difference
of r1 and r2 and is defined as
"r1 r2 --not $(git merge-base --all r1 r2) ".
It is the set of commits that are reachable from either one of
-r1 or r2 but not from both.
-
Two other shorthands for naming a set that is formed by a commit
+r1 or r2 but not from both.
+
Two other shorthands for naming a set that is formed by a commit
and its parent commits exists. r1^@ notation means all
parents of r1 . r1^! includes commit r1 but excludes
-its all parents.
-
Here are a handful of examples:
+its all parents.
+
Here are a handful of examples:
D G H D
@@ -779,26 +827,26 @@ C^@ I J F
F^! D G H D F
-
PARSEOPT
+
PARSEOPT
-
In --parseopt mode, git-rev-parse helps massaging options to bring to shell
+
In --parseopt mode, git-rev-parse helps massaging options to bring to shell
scripts the same facilities C builtins have. It works as an option normalizer
-(e.g. splits single switches aggregate values), a bit like getopt(1) does.
-
It takes on the standard input the specification of the options to parse and
+(e.g. splits single switches aggregate values), a bit like getopt(1) does.
+
It takes on the standard input the specification of the options to parse and
understand, and echoes on the standard output a line suitable for sh(1) eval
to replace the arguments with normalized ones. In case of error, it outputs
-usage on the standard error stream, and exits with code 129.
-
Input Format
-
git-rev-parse --parseopt input format is fully text based. It has two parts,
+usage on the standard error stream, and exits with code 129.
+
+
git-rev-parse --parseopt input format is fully text based. It has two parts,
separated by a line that contains only -- . The lines before the separator
(should be more than one) are used for the usage.
-The lines after the separator describe the options.
-
Each line of options has this format:
+The lines after the separator describe the options.
+
Each line of options has this format:
<opt_spec><flags>* SP+ help LF
-
+
<opt_spec>
@@ -817,7 +865,7 @@ The lines after the separator describe the options.
<flags> are of * , = , ? or ! .
-
-
The remainder of the line, after stripping the spaces, is used
-as the help associated to the option.
-
Blank lines are ignored, and lines that don't match this specification are used
+
+The remainder of the line, after stripping the spaces, is used
+as the help associated to the option.
+Blank lines are ignored, and lines that don't match this specification are used
as option group headers (start the line with a space to create such
-lines on purpose).
-
Example
+lines on purpose).
+Example
OPTS_SPEC="\
@@ -867,9 +915,9 @@ C? option C with an optional argument"
eval `echo "$OPTS_SPEC" | git rev-parse --parseopt -- "$@" || echo exit $?`
-
EXAMPLES
+
EXAMPLES
-
+
-This will error out if $REV is empty or not a valid revision.
+This will error out if $REV is empty or not a valid revision.
@@ -897,26 +945,26 @@ Same as above:
$ git rev-parse --default master --verify $REV
-
but if $REV is empty, the commit object name from master will be printed.
+
but if $REV is empty, the commit object name from master will be printed.
-
+
-Author
+Author
-
Written by Linus Torvalds <torvalds@osdl.org> .
-Junio C Hamano <junkio@cox.net> and Pierre Habouzit <madcoder@debian.org>
+
Written by Linus Torvalds <torvalds@osdl.org> .
+Junio C Hamano <junkio@cox.net> and Pierre Habouzit <madcoder@debian.org>
-Documentation
+Documentation
-
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-rev-parse.txt b/git-rev-parse.txt
index 6825ae27c..0501a8702 100644
--- a/git-rev-parse.txt
+++ b/git-rev-parse.txt
@@ -15,16 +15,16 @@ DESCRIPTION
Many git porcelainish commands take mixture of flags
(i.e. parameters that begin with a dash '-') and parameters
-meant for the underlying `git-rev-list` command they use internally
+meant for the underlying 'git-rev-list' command they use internally
and flags and parameters for the other commands they use
-downstream of `git-rev-list`. This command is used to
+downstream of 'git-rev-list'. This command is used to
distinguish between them.
OPTIONS
-------
--parseopt::
- Use `git-rev-parse` in option parsing mode (see PARSEOPT section below).
+ Use 'git-rev-parse' in option parsing mode (see PARSEOPT section below).
--keep-dash-dash::
Only meaningful in `--parseopt` mode. Tells the option parser to echo
@@ -32,11 +32,11 @@ OPTIONS
--revs-only::
Do not output flags and parameters not meant for
- `git-rev-list` command.
+ 'git-rev-list' command.
--no-revs::
Do not output flags and parameters meant for
- `git-rev-list` command.
+ 'git-rev-list' command.
--flags::
Do not output non-flag parameters.
@@ -64,7 +64,7 @@ OPTIONS
properly quoted for consumption by shell. Useful when
you expect your parameter to contain whitespaces and
newlines (e.g. when using pickaxe `-S` with
- `git-diff-\*`).
+ 'git-diff-\*').
--not::
When showing object names, prefix them with '{caret}' and
@@ -129,12 +129,12 @@ OPTIONS
--since=datestring::
--after=datestring::
Parse the date string, and output the corresponding
- --max-age= parameter for `git-rev-list`.
+ --max-age= parameter for 'git-rev-list'.
--until=datestring::
--before=datestring::
Parse the date string, and output the corresponding
- --min-age= parameter for `git-rev-list`.
+ --min-age= parameter for 'git-rev-list'.
...::
Flags and parameters to be parsed.
@@ -155,7 +155,7 @@ blobs contained in a commit.
name the same commit object if there are no other object in
your repository whose object name starts with dae86e.
-* An output from `git-describe`; i.e. a closest tag, followed by a
+* An output from 'git-describe'; i.e. a closest tag, followed by a
dash, a `g`, and an abbreviated object name.
* A symbolic ref name. E.g. 'master' typically means the commit
@@ -278,7 +278,7 @@ G H I J
SPECIFYING RANGES
-----------------
-History traversing commands such as `git-log` operate on a set
+History traversing commands such as 'git-log' operate on a set
of commits, not just a single commit. To these commands,
specifying a single revision with the notation described in the
previous section means the set of commits reachable from that
@@ -319,7 +319,7 @@ Here are a handful of examples:
PARSEOPT
--------
-In `--parseopt` mode, `git-rev-parse` helps massaging options to bring to shell
+In `--parseopt` mode, 'git-rev-parse' helps massaging options to bring to shell
scripts the same facilities C builtins have. It works as an option normalizer
(e.g. splits single switches aggregate values), a bit like `getopt(1)` does.
@@ -331,7 +331,7 @@ usage on the standard error stream, and exits with code 129.
Input Format
~~~~~~~~~~~~
-`git-rev-parse --parseopt` input format is fully text based. It has two parts,
+'git-rev-parse --parseopt' input format is fully text based. It has two parts,
separated by a line that contains only `--`. The lines before the separator
(should be more than one) are used for the usage.
The lines after the separator describe the options.
diff --git a/git-revert.html b/git-revert.html
index 77d378b2e..ffcdcd016 100644
--- a/git-revert.html
+++ b/git-revert.html
@@ -3,7 +3,7 @@
-
+
git-revert(1)
@@ -272,17 +320,17 @@ git-revert(1) Manual Page
SYNOPSIS
-
git revert [--edit | --no-edit] [-n] [-m parent-number] [-s] <commit>
+
git revert [--edit | --no-edit] [-n] [-m parent-number] [-s] <commit>
-DESCRIPTION
+DESCRIPTION
-
Given one existing commit, revert the change the patch introduces, and record a
+
Given one existing commit, revert the change the patch introduces, and record a
new commit that records it. This requires your working tree to be clean (no
-modifications from the HEAD commit).
+modifications from the HEAD commit).
-OPTIONS
+OPTIONS
-
+
<commit>
@@ -301,7 +349,7 @@ modifications from the HEAD commit).
- With this option, git-revert will let you edit the commit
+ With this option, git-revert will let you edit the commit
message prior to committing the revert. This is the default if
you run the command from a terminal.
@@ -326,7 +374,7 @@ modifications from the HEAD commit).
- With this option, git-revert will not start the commit
+ With this option, git-revert will not start the commit
message editor.
@@ -347,8 +395,8 @@ modifications from the HEAD commit).
The revert is done against the beginning state of your
working tree.
-This is useful when reverting more than one commits'
-effect to your working tree in a row.
+This is useful when reverting more than one commits'
+effect to your working tree in a row.
-s
@@ -361,23 +409,23 @@ effect to your working tree in a row.
Add Signed-off-by line at the end of the commit message.
-
+
-Author
+Author
-
Written by Junio C Hamano <junkio@cox.net>
+
Written by Junio C Hamano <junkio@cox.net>
-Documentation
+Documentation
-
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-revert.txt b/git-revert.txt
index 3d0c5aba9..5411edca9 100644
--- a/git-revert.txt
+++ b/git-revert.txt
@@ -24,7 +24,7 @@ OPTIONS
-e::
--edit::
- With this option, `git-revert` will let you edit the commit
+ With this option, 'git-revert' will let you edit the commit
message prior to committing the revert. This is the default if
you run the command from a terminal.
@@ -37,7 +37,7 @@ OPTIONS
relative to the specified parent.
--no-edit::
- With this option, `git-revert` will not start the commit
+ With this option, 'git-revert' will not start the commit
message editor.
-n::
diff --git a/git-rm.html b/git-rm.html
index 74798cb64..657ccfe49 100644
--- a/git-rm.html
+++ b/git-rm.html
@@ -3,7 +3,7 @@
-
+
git-rm(1)
@@ -272,12 +320,12 @@ git-rm(1) Manual Page
SYNOPSIS
-
git rm [-f] [-n] [-r] [--cached] [--ignore-unmatch] [--quiet] [--] <file>…
+
git rm [-f] [-n] [-r] [--cached] [--ignore-unmatch] [--quiet] [--] <file>…
-DESCRIPTION
+DESCRIPTION
-
Remove files from the index, or from the working tree and the index.
-git-rm will not remove a file from just your working directory.
+
Remove files from the index, or from the working tree and the index.
+git-rm will not remove a file from just your working directory.
(There is no option to remove a file only from the work tree
and yet keep it in the index; use /bin/rm if you want to do that.)
The files being removed have to be identical to the tip of the branch,
@@ -285,11 +333,11 @@ and no updates to their contents can be staged in the index,
though that default behavior can be overridden with the -f option.
When --cached is given, the staged content has to
match either the tip of the branch or the file on disk,
-allowing the file to be removed from just the index.
+allowing the file to be removed from just the index.
-OPTIONS
+OPTIONS
-
+
<file>…
@@ -371,26 +419,26 @@ allowing the file to be removed from just the index.
- git-rm normally outputs one line (in the form of an "rm" command)
+ git-rm normally outputs one line (in the form of an "rm" command)
for each file removed. This option suppresses that output.
-
+
-DISCUSSION
+DISCUSSION
-
The <file> list given to the command can be exact pathnames,
+
The <file> list given to the command can be exact pathnames,
file glob patterns, or leading directory names. The command
removes only the paths that are known to git. Giving the name of
-a file that you have not told git about does not remove that file.
-
File globbing matches across directory boundaries. Thus, given
+a file that you have not told git about does not remove that file.
+
File globbing matches across directory boundaries. Thus, given
two directories d and d2 , there is a difference between
using git rm 'd*' and git rm 'd/*' , as the former will
-also remove all of directory d2 .
+also remove all of directory
d2 .
-EXAMPLES
+EXAMPLES
-
+
git rm Documentation/\*.txt
@@ -399,9 +447,9 @@ git rm Documentation/\*.txt
Removes all *.txt files from the index that are under the
Documentation directory and any of its subdirectories.
-Note that the asterisk * is quoted from the shell in this
+
Note that the asterisk * is quoted from the shell in this
example; this lets git, and not the shell, expand the pathnames
-of files and subdirectories under the Documentation/ directory.
+of files and subdirectories under the
Documentation/ directory.
git rm -f git-*.sh
@@ -413,27 +461,27 @@ git rm -f git-*.sh
does not remove subdir/git-foo.sh .
-
+
-SEE ALSO
+SEE ALSO
-Author
+Author
-
Written by Linus Torvalds <torvalds@osdl.org>
+
Written by Linus Torvalds <torvalds@osdl.org>
-Documentation
+Documentation
-
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-rm.txt b/git-rm.txt
index 01b63be38..4d0c495bc 100644
--- a/git-rm.txt
+++ b/git-rm.txt
@@ -12,7 +12,7 @@ SYNOPSIS
DESCRIPTION
-----------
Remove files from the index, or from the working tree and the index.
-`git-rm` will not remove a file from just your working directory.
+'git-rm' will not remove a file from just your working directory.
(There is no option to remove a file only from the work tree
and yet keep it in the index; use `/bin/rm` if you want to do that.)
The files being removed have to be identical to the tip of the branch,
@@ -63,7 +63,7 @@ OPTIONS
-q::
--quiet::
- `git-rm` normally outputs one line (in the form of an "rm" command)
+ 'git-rm' normally outputs one line (in the form of an "rm" command)
for each file removed. This option suppresses that output.
diff --git a/git-send-pack.html b/git-send-pack.html
index 6fda2e417..69434523d 100644
--- a/git-send-pack.html
+++ b/git-send-pack.html
@@ -3,7 +3,7 @@
-
+
git-send-pack(1)
@@ -272,24 +320,24 @@ git-send-pack(1) Manual Page
SYNOPSIS
-
git send-pack [--all] [--dry-run] [--force] [--receive-pack=<git-receive-pack>] [--verbose] [--thin] [<host>:]<directory> [<ref>…]
+
git send-pack [--all] [--dry-run] [--force] [--receive-pack=<git-receive-pack>] [--verbose] [--thin] [<host>:]<directory> [<ref>…]
-DESCRIPTION
+DESCRIPTION
-
Usually you would want to use git-push , which is a
-higher-level wrapper of this command, instead. See git-push(1) .
-
Invokes git-receive-pack on a possibly remote repository, and
-updates it from the current repository, sending named refs.
+
Usually you would want to use git-push , which is a
+higher-level wrapper of this command, instead. See git-push(1) .
+
Invokes git-receive-pack on a possibly remote repository, and
+updates it from the current repository, sending named refs.
-OPTIONS
+OPTIONS
-
+
--receive-pack=<git-receive-pack>
- Path to the git-receive-pack program on the remote
+ Path to the git-receive-pack program on the remote
end. Sometimes useful when pushing to a remote
repository over ssh, and you do not have the program in
a directory on the default $PATH.
@@ -355,7 +403,7 @@ updates it from the current repository, sending named refs.
A remote host to house the repository. When this
- part is specified, git-receive-pack is invoked via
+ part is specified, git-receive-pack is invoked via
ssh.
@@ -375,29 +423,29 @@ updates it from the current repository, sending named refs.
The remote refs to update.
-
+
-Specifying the Refs
+Specifying the Refs
-
There are three ways to specify which refs to update on the
-remote end.
-
With --all flag, all refs that exist locally are transferred to
+
There are three ways to specify which refs to update on the
+remote end.
+
With --all flag, all refs that exist locally are transferred to
the remote side. You cannot specify any <ref> if you use
-this flag.
-
Without --all and without any <ref> , the heads that exist
-both on the local side and on the remote side are updated.
-
When one or more <ref> are specified explicitly, it can be either a
+this flag.
+
Without --all and without any <ref> , the heads that exist
+both on the local side and on the remote side are updated.
+
When one or more <ref> are specified explicitly, it can be either a
single pattern, or a pair of such pattern separated by a colon
":" (this means that a ref name cannot have a colon in it). A
-single pattern <name> is just a shorthand for <name>:<name> .
-
Each pattern pair consists of the source side (before the colon)
+single pattern <name> is just a shorthand for <name>:<name> .
+
Each pattern pair consists of the source side (before the colon)
and the destination side (after the colon). The ref to be
pushed is determined by finding a match that matches the source
side, and where it is pushed is determined by using the
destination side. The rules used to match a ref are the same
-rules used by git-rev-parse to resolve a symbolic ref
-name. See git-rev-parse(1) .
-
+rules used by git-rev-parse to resolve a symbolic ref
+name. See git-rev-parse(1) .
+
It is an error if <src> does not match exactly one of the
@@ -413,7 +461,7 @@ It is an error if <dst> matches more than one remote refs.
If <dst> does not match any remote ref, either
-
-
-
Without --force , the <src> ref is stored at the remote only if
+
+
Without --force , the <src> ref is stored at the remote only if
<dst> does not exist, or <dst> is a proper subset (i.e. an
ancestor) of <src>. This check, known as "fast forward check",
is performed in order to avoid accidentally overwriting the
-remote ref and lose other peoples' commits from there.
-
With --force , the fast forward check is disabled for all refs.
-
Optionally, a <ref> parameter can be prefixed with a plus + sign
-to disable the fast-forward check only on that ref.
+remote ref and lose other peoples' commits from there.
+
With --force , the fast forward check is disabled for all refs.
+
Optionally, a <ref> parameter can be prefixed with a plus + sign
+to disable the fast-forward check only on that ref.
-Author
+Author
-
Written by Linus Torvalds <torvalds@osdl.org>
+
Written by Linus Torvalds <torvalds@osdl.org>
-Documentation
+Documentation
-
Documentation by Junio C Hamano.
+
Documentation by Junio C Hamano.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-send-pack.txt b/git-send-pack.txt
index 410504df4..399821832 100644
--- a/git-send-pack.txt
+++ b/git-send-pack.txt
@@ -12,17 +12,17 @@ SYNOPSIS
DESCRIPTION
-----------
-Usually you would want to use `git-push`, which is a
+Usually you would want to use 'git-push', which is a
higher-level wrapper of this command, instead. See linkgit:git-push[1].
-Invokes `git-receive-pack` on a possibly remote repository, and
+Invokes 'git-receive-pack' on a possibly remote repository, and
updates it from the current repository, sending named refs.
OPTIONS
-------
--receive-pack=::
- Path to the `git-receive-pack` program on the remote
+ Path to the 'git-receive-pack' program on the remote
end. Sometimes useful when pushing to a remote
repository over ssh, and you do not have the program in
a directory on the default $PATH.
@@ -53,7 +53,7 @@ OPTIONS
::
A remote host to house the repository. When this
- part is specified, `git-receive-pack` is invoked via
+ part is specified, 'git-receive-pack' is invoked via
ssh.
::
@@ -86,7 +86,7 @@ and the destination side (after the colon). The ref to be
pushed is determined by finding a match that matches the source
side, and where it is pushed is determined by using the
destination side. The rules used to match a ref are the same
-rules used by `git-rev-parse` to resolve a symbolic ref
+rules used by 'git-rev-parse' to resolve a symbolic ref
name. See linkgit:git-rev-parse[1].
- It is an error if does not match exactly one of the
diff --git a/git-sh-setup.html b/git-sh-setup.html
index 797b60230..d7e63f7fb 100644
--- a/git-sh-setup.html
+++ b/git-sh-setup.html
@@ -3,7 +3,7 @@
-
+
git-sh-setup(1)
@@ -272,27 +320,27 @@ git-sh-setup(1) Manual Page
SYNOPSIS
-
. "$(git --exec-path)/git-sh-setup"
+
. "$(git --exec-path)/git-sh-setup"
-DESCRIPTION
+DESCRIPTION
-
This is not a command the end user would want to run. Ever.
+
This is not a command the end user would want to run. Ever.
This documentation is meant for people who are studying the
-Porcelain-ish scripts and/or are writing new ones.
-
The git-sh-setup scriptlet is designed to be sourced (using
+Porcelain-ish scripts and/or are writing new ones.
+
The git-sh-setup scriptlet is designed to be sourced (using
. ) by other shell scripts to set up some variables pointing at
-the normal git directories and a few helper shell functions.
-
Before sourcing it, your script should set up a few variables;
+the normal git directories and a few helper shell functions.
+
Before sourcing it, your script should set up a few variables;
USAGE (and LONG_USAGE , if any) is used to define message
given by usage() shell function. SUBDIRECTORY_OK can be set
if the script can run from a subdirectory of the working tree
-(some commands do not).
-
The scriptlet sets GIT_DIR and GIT_OBJECT_DIRECTORY shell
-variables, but does not export them to the environment.
+(some commands do not).
+
The scriptlet sets GIT_DIR and GIT_OBJECT_DIRECTORY shell
+variables, but does not export them to the environment.
-FUNCTIONS
+FUNCTIONS
-
+
die
@@ -367,23 +415,23 @@ get_author_ident_from_commit
GIT_AUTHOR_EMAIL and GIT_AUTHOR_DATE variables for a given commit.
-
+
-Author
+Author
-
Written by Linus Torvalds <torvalds@osdl.org>
+
Written by Linus Torvalds <torvalds@osdl.org>
-Documentation
+Documentation
-
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-sh-setup.txt b/git-sh-setup.txt
index 6731f9ac4..18f14b5be 100644
--- a/git-sh-setup.txt
+++ b/git-sh-setup.txt
@@ -16,7 +16,7 @@ This is not a command the end user would want to run. Ever.
This documentation is meant for people who are studying the
Porcelain-ish scripts and/or are writing new ones.
-The `git-sh-setup` scriptlet is designed to be sourced (using
+The 'git-sh-setup' scriptlet is designed to be sourced (using
`.`) by other shell scripts to set up some variables pointing at
the normal git directories and a few helper shell functions.
diff --git a/git-shell.html b/git-shell.html
index 66706ccae..e50b5e3d4 100644
--- a/git-shell.html
+++ b/git-shell.html
@@ -3,7 +3,7 @@
-
+
git-shell(1)
@@ -272,33 +320,33 @@ git-shell(1) Manual Page
SYNOPSIS
-
$(git --exec-path)/git-shell -c <command> <argument>
+
$(git --exec-path)/git-shell -c <command> <argument>
-DESCRIPTION
+DESCRIPTION
-
This is meant to be used as a login shell for SSH accounts you want
+
This is meant to be used as a login shell for SSH accounts you want
to restrict to GIT pull/push access only. It permits execution only
of server-side GIT commands implementing the pull/push functionality.
The commands can be executed only by the -c option; the shell is not
-interactive.
-
Currently, only the git-receive-pack and git-upload-pack commands
-are permitted to be called, with a single required argument.
+interactive.
+
Currently, only the git-receive-pack and git-upload-pack commands
+are permitted to be called, with a single required argument.
-Author
+Author
-
Written by Linus Torvalds <torvalds@osdl.org>
+
Written by Linus Torvalds <torvalds@osdl.org>
-Documentation
+Documentation
-
Documentation by Petr Baudis and the git-list <git@vger.kernel.org>.
+
Documentation by Petr Baudis and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-shell.txt b/git-shell.txt
index 9b2ae7f26..ff420f8f8 100644
--- a/git-shell.txt
+++ b/git-shell.txt
@@ -18,7 +18,7 @@ of server-side GIT commands implementing the pull/push functionality.
The commands can be executed only by the '-c' option; the shell is not
interactive.
-Currently, only the `git-receive-pack` and `git-upload-pack` commands
+Currently, only the 'git-receive-pack' and 'git-upload-pack' commands
are permitted to be called, with a single required argument.
Author
diff --git a/git-shortlog.html b/git-shortlog.html
index 4f86959aa..3f0506106 100644
--- a/git-shortlog.html
+++ b/git-shortlog.html
@@ -3,7 +3,7 @@
-
+
git-shortlog(1)
@@ -266,7 +314,7 @@ git-shortlog(1) Manual Page
NAME
git-shortlog -
- Summarize 'git log' output
+ Summarize 'git-log' output
@@ -276,16 +324,16 @@ git-shortlog(1) Manual Page
git log --pretty=short | git shortlog [-h] [-n] [-s] [-e] [-w]
git shortlog [-n|--numbered] [-s|--summary] [-e|--email] [-w[<width>[,<indent1>[,<indent2>]]]] [<committish>…]
-DESCRIPTION
+DESCRIPTION
-
Summarizes git-log output in a format suitable for inclusion
+
Summarizes git-log output in a format suitable for inclusion
in release announcements. Each commit will be grouped by author and
-the first line of the commit message will be shown.
-
Additionally, "[PATCH]" will be stripped from the commit description.
+the first line of the commit message will be shown.
+
Additionally, "[PATCH]" will be stripped from the commit description.
-OPTIONS
+OPTIONS
-
+
-h
@@ -342,14 +390,14 @@ the first line of the commit message will be shown.
indent1 , and indent2 default to 76, 6 and 9 respectively.
-
+
-FILES
+FILES
-
If the file .mailmap exists, it will be used for mapping author
+
If the file .mailmap exists, it will be used for mapping author
email addresses to a real author name. One mapping per line, first
the author name followed by the email address enclosed by
-< and > . Use hash # for comments. Example:
+
< and
> . Use hash
# for comments. Example:
# Keep alphabetized
@@ -357,21 +405,21 @@ Adam Morrow <adam@localhost.localdomain>
Eve Jones <eve@laptop.(none)>
-Author
+Author
-
Written by Jeff Garzik <jgarzik@pobox.com>
+
Written by Jeff Garzik <jgarzik@pobox.com>
-Documentation
+Documentation
-
Documentation by Junio C Hamano.
+
Documentation by Junio C Hamano.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-shortlog.txt b/git-shortlog.txt
index 6e4cbc4fd..7ccf31ccc 100644
--- a/git-shortlog.txt
+++ b/git-shortlog.txt
@@ -3,7 +3,7 @@ git-shortlog(1)
NAME
----
-git-shortlog - Summarize 'git log' output
+git-shortlog - Summarize 'git-log' output
SYNOPSIS
--------
@@ -13,7 +13,7 @@ git shortlog [-n|--numbered] [-s|--summary] [-e|--email] [-w[[,[
DESCRIPTION
-----------
-Summarizes `git-log` output in a format suitable for inclusion
+Summarizes 'git-log' output in a format suitable for inclusion
in release announcements. Each commit will be grouped by author and
the first line of the commit message will be shown.
diff --git a/git-show-branch.html b/git-show-branch.html
index 596ea4012..d34d82fdd 100644
--- a/git-show-branch.html
+++ b/git-show-branch.html
@@ -3,7 +3,7 @@
-
+
git-show-branch(1)
@@ -278,18 +326,18 @@ git-show-branch(1) Manual Page
[--no-name | --sha1-name] [--topics] [<rev> | <glob>]…
git show-branch (-g|--reflog)[=<n>[,<base>]] [--list] [<ref>]
-DESCRIPTION
+DESCRIPTION
-
Shows the commit ancestry graph starting from the commits named
+
Shows the commit ancestry graph starting from the commits named
with <rev>s or <globs>s (or all refs under $GIT_DIR/refs/heads
-and/or $GIT_DIR/refs/tags) semi-visually.
-
It cannot show more than 29 branches and commits at a time.
-
It uses showbranch.default multi-valued configuration items if
-no <rev> nor <glob> is given on the command line.
+and/or $GIT_DIR/refs/tags) semi-visually.
+
It cannot show more than 29 branches and commits at a time.
+
It uses showbranch.default multi-valued configuration items if
+no <rev> nor <glob> is given on the command line.
-OPTIONS
+OPTIONS
-
+
<rev>
@@ -390,7 +438,7 @@ no <rev> nor <glob> is given on the command line.
Instead of showing the commit list, just act like the
- git-merge-base -a command, except that it can accept
+ git-merge-base -a command, except that it can accept
more than two heads.
@@ -448,24 +496,24 @@ no <rev> nor <glob> is given on the command line.
current branch (or HEAD if it is detached).
-
-
Note that --more, --list, --independent and --merge-base options
-are mutually exclusive.
+
+Note that --more, --list, --independent and --merge-base options
+are mutually exclusive.
-OUTPUT
+OUTPUT
-
Given N <references>, the first N lines are the one-line
+
Given N <references>, the first N lines are the one-line
description from their commit message. The branch head that is
pointed at by $GIT_DIR/HEAD is prefixed with an asterisk *
-character while other heads are prefixed with a ! character.
-
Following these N lines, one-line log for each commit is
+character while other heads are prefixed with a ! character.
+
Following these N lines, one-line log for each commit is
displayed, indented N places. If a commit is on the I-th
branch, the I-th indentation character shows a + sign;
otherwise it shows a space. Merge commits are denoted by
a - sign. Each commit shows a short name that
-can be used as an extended SHA1 to name that commit.
-
The following example shows three branches, "master", "fixes"
-and "mhf":
+can be used as an extended SHA1 to name that commit.
+
The following example shows three branches, "master", "fixes"
+and "mhf":
$ git show-branch master fixes mhf
@@ -485,16 +533,16 @@ and "mhf":
+ [mhf~8] Start adding the $GIT_DIR/remotes/ support.
*++ [master] Add 'git show-branch'.
-
These three branches all forked from a common commit, [master],
+
These three branches all forked from a common commit, [master],
whose commit message is "Add git show-branch . "fixes" branch
adds one commit Introduce "reset type" . "mhf" branch has many
-other commits. The current branch is "master".
+other commits. The current branch is "master".
-EXAMPLE
+EXAMPLE
-
If you keep your primary branches immediately under
+
If you keep your primary branches immediately under
$GIT_DIR/refs/heads , and topic branches in subdirectories of
-it, having the following in the configuration file may help:
+it, having the following in the configuration file may help:
[showbranch]
@@ -502,32 +550,32 @@ it, having the following in the configuration file may help:
default = heads/*
-
With this, git show-branch without extra parameters would show
+
With this, git show-branch without extra parameters would show
only the primary branches. In addition, if you happen to be on
-your topic branch, it is shown as well.
+your topic branch, it is shown as well.
$ git show-branch --reflog='10,1 hour ago' --list master
-
shows 10 reflog entries going back from the tip as of 1 hour ago.
+
shows 10 reflog entries going back from the tip as of 1 hour ago.
Without --list , the output also shows how these tips are
-topologically related with each other.
+topologically related with each other.
-Author
+Author
-
Written by Junio C Hamano <junkio@cox.net>
+
Written by Junio C Hamano <junkio@cox.net>
-Documentation
+Documentation
-
Documentation by Junio C Hamano.
+
Documentation by Junio C Hamano.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-show-branch.txt b/git-show-branch.txt
index 578bdb785..14e10362b 100644
--- a/git-show-branch.txt
+++ b/git-show-branch.txt
@@ -75,7 +75,7 @@ OPTIONS
--merge-base::
Instead of showing the commit list, just act like the
- `git-merge-base -a` command, except that it can accept
+ 'git-merge-base -a' command, except that it can accept
more than two heads.
--independent::
diff --git a/git-show-index.html b/git-show-index.html
index 29ff1070d..c9bac2fec 100644
--- a/git-show-index.html
+++ b/git-show-index.html
@@ -3,7 +3,7 @@
-
+
git-show-index(1)
@@ -272,31 +320,31 @@ git-show-index(1) Manual Page
SYNOPSIS
-
git show-index < idx-file
+
git show-index < idx-file
-DESCRIPTION
+DESCRIPTION
-
Reads given idx file for packed git archive created with
-git-pack-objects command, and dumps its contents.
-
The information it outputs is subset of what you can get from
-git-verify-pack -v ; this command only shows the packfile
-offset and SHA1 of each object.
+
Reads given idx file for packed git archive created with
+git-pack-objects command, and dumps its contents.
+
The information it outputs is subset of what you can get from
+git-verify-pack -v ; this command only shows the packfile
+offset and SHA1 of each object.
-Author
+Author
-
Written by Linus Torvalds <torvalds@osdl.org>
+
Written by Linus Torvalds <torvalds@osdl.org>
-Documentation
+Documentation
-
Documentation by Junio C Hamano
+
Documentation by Junio C Hamano
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-show-index.txt b/git-show-index.txt
index 4ae6ede11..e3285aacf 100644
--- a/git-show-index.txt
+++ b/git-show-index.txt
@@ -14,10 +14,10 @@ SYNOPSIS
DESCRIPTION
-----------
Reads given idx file for packed git archive created with
-`git-pack-objects` command, and dumps its contents.
+'git-pack-objects' command, and dumps its contents.
The information it outputs is subset of what you can get from
-`git-verify-pack -v`; this command only shows the packfile
+'git-verify-pack -v'; this command only shows the packfile
offset and SHA1 of each object.
diff --git a/git-show-ref.html b/git-show-ref.html
index dffd3eded..e33bf3631 100644
--- a/git-show-ref.html
+++ b/git-show-ref.html
@@ -3,7 +3,7 @@
-
+
git-show-ref(1)
@@ -277,20 +325,20 @@ git-show-ref(1) Manual Page
[-s|--hash] [--abbrev] [--tags] [--heads] [--] <pattern>…
git show-ref --exclude-existing[=pattern]
-DESCRIPTION
+DESCRIPTION
-
Displays references available in a local repository along with the associated
+
Displays references available in a local repository along with the associated
commit IDs. Results can be filtered using a pattern and tags can be
dereferenced into object IDs. Additionally, it can be used to test whether a
-particular ref exists.
-
The --exclude-existing form is a filter that does the inverse, it shows the
-refs from stdin that don't exist in the local repository.
-
Use of this utility is encouraged in favor of directly accessing files under
-in the .git directory.
+particular ref exists.
+
The --exclude-existing form is a filter that does the inverse, it shows the
+refs from stdin that don't exist in the local repository.
+
Use of this utility is encouraged in favor of directly accessing files under
+in the .git directory.
-OPTIONS
+OPTIONS
-
+
-h
@@ -381,7 +429,7 @@ in the .git directory.
- Make git-show-ref act as a filter that reads refs from stdin of the
+ Make git-show-ref act as a filter that reads refs from stdin of the
form "(?:<anything>\s)?<refname>(?:\ {})?$" and performs the
following actions on each:
(1) strip "^{}" at the end of line if any;
@@ -399,11 +447,11 @@ in the .git directory.
Show references matching one or more patterns.
-
+
-OUTPUT
+OUTPUT
-
The output is in the format: <SHA-1 ID> <space> <reference name> .
+
The output is in the format: <SHA-1 ID> <space> <reference name> .
$ git show-ref --head --dereference
@@ -416,7 +464,7 @@ in the .git directory.
423325a2d24638ddcc82ce47be5e40be550f4507 refs/tags/v1.0rc4^{}
...
-
When using --hash (and not --dereference) the output format is: <SHA-1 ID>
+
When using --hash (and not --dereference) the output format is: <SHA-1 ID>
$ git show-ref --heads --hash
@@ -426,62 +474,62 @@ in the .git directory.
...
-EXAMPLE
+EXAMPLE
-
To show all references called "master", whether tags or heads or anything
+
To show all references called "master", whether tags or heads or anything
else, and regardless of how deep in the reference naming hierarchy they are,
-use:
+use:
-
This will show "refs/heads/master" but also "refs/remote/other-repo/master",
-if such references exists.
-
When using the --verify flag, the command requires an exact path:
+
This will show "refs/heads/master" but also "refs/remote/other-repo/master",
+if such references exists.
+
When using the --verify flag, the command requires an exact path:
git show-ref --verify refs/heads/master
-
will only match the exact branch called "master".
-
If nothing matches, git-show-ref will return an error code of 1,
-and in the case of verification, it will show an error message.
-
For scripting, you can ask it to be quiet with the "--quiet" flag, which
-allows you to do things like
+
will only match the exact branch called "master".
+
If nothing matches, git-show-ref will return an error code of 1,
+and in the case of verification, it will show an error message.
+
For scripting, you can ask it to be quiet with the "--quiet" flag, which
+allows you to do things like
git show-ref --quiet --verify -- "refs/heads/$headname" ||
echo "$headname is not a valid branch"
-
to check whether a particular branch exists or not (notice how we don't
+
to check whether a particular branch exists or not (notice how we don't
actually want to show any results, and we want to use the full refname for it
-in order to not trigger the problem with ambiguous partial matches).
-
To show only tags, or only proper branch heads, use "--tags" and/or "--heads"
+in order to not trigger the problem with ambiguous partial matches).
+
To show only tags, or only proper branch heads, use "--tags" and/or "--heads"
respectively (using both means that it shows tags and heads, but not other
-random references under the refs/ subdirectory).
-
To do automatic tag object dereferencing, use the "-d" or "--dereference"
-flag, so you can do
+random references under the refs/ subdirectory).
+
To do automatic tag object dereferencing, use the "-d" or "--dereference"
+flag, so you can do
git show-ref --tags --dereference
-
to get a listing of all tags together with what they dereference.
+
to get a listing of all tags together with what they dereference.
-SEE ALSO
+SEE ALSO
-AUTHORS
+AUTHORS
-
Written by Linus Torvalds <torvalds@osdl.org>.
-Man page by Jonas Fonseca <fonseca@diku.dk>.
+
Written by Linus Torvalds <torvalds@osdl.org>.
+Man page by Jonas Fonseca <fonseca@diku.dk>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-show-ref.txt b/git-show-ref.txt
index a78a7dcf7..9a4389981 100644
--- a/git-show-ref.txt
+++ b/git-show-ref.txt
@@ -74,7 +74,7 @@ OPTIONS
--exclude-existing::
--exclude-existing=pattern::
- Make `git-show-ref` act as a filter that reads refs from stdin of the
+ Make 'git-show-ref' act as a filter that reads refs from stdin of the
form "^(?:\s)?(?:\^\{\})?$" and performs the
following actions on each:
(1) strip "^{}" at the end of line if any;
@@ -137,7 +137,7 @@ When using the '--verify' flag, the command requires an exact path:
will only match the exact branch called "master".
-If nothing matches, `git-show-ref` will return an error code of 1,
+If nothing matches, 'git-show-ref' will return an error code of 1,
and in the case of verification, it will show an error message.
For scripting, you can ask it to be quiet with the "--quiet" flag, which
diff --git a/git-show.html b/git-show.html
index 6f69343c4..ac2d52e15 100644
--- a/git-show.html
+++ b/git-show.html
@@ -3,7 +3,7 @@
-
+
git-show(1)
@@ -272,25 +320,25 @@ git-show(1) Manual Page
SYNOPSIS
-
git show [options] <object>…
+
git show [options] <object>…
-DESCRIPTION
+DESCRIPTION
-
Shows one or more objects (blobs, trees, tags and commits).
-
For commits it shows the log message and textual diff. It also
+
Shows one or more objects (blobs, trees, tags and commits).
+
For commits it shows the log message and textual diff. It also
presents the merge commit in a special format as produced by
-git-diff-tree --cc .
-
For tags, it shows the tag message and the referenced objects.
-
For trees, it shows the names (equivalent to git-ls-tree
-with --name-only).
-
For plain blobs, it shows the plain contents.
-
The command takes options applicable to the git-diff-tree command to
-control how the changes the commit introduces are shown.
-
This manual page describes only the most frequently used options.
+
git-diff-tree --cc .
+
For tags, it shows the tag message and the referenced objects.
+
For trees, it shows the names (equivalent to git-ls-tree
+with --name-only).
+
For plain blobs, it shows the plain contents.
+
The command takes options applicable to the git-diff-tree command to
+control how the changes the commit introduces are shown.
+
This manual page describes only the most frequently used options.
-OPTIONS
+OPTIONS
-
+
<object>
@@ -311,8 +359,8 @@ control how the changes the commit introduces are shown.
full , fuller , email , raw and format:<string> .
When omitted, the format defaults to medium .
-Note: you can specify the default pretty format in the repository
-configuration (see git-config(1) ).
+Note: you can specify the default pretty format in the repository
+configuration (see git-config(1) ).
--abbrev-commit
@@ -324,8 +372,8 @@ configuration (see git-config(1) ).
digits can be specified with "--abbrev=<n>" (which also modifies
diff output, if it is displayed).
-This should make "--pretty=oneline" a whole lot more readable for
-people using 80-column terminals.
+This should make "--pretty=oneline" a whole lot more readable for
+people using 80-column terminals.
--encoding[=<encoding>]
@@ -339,11 +387,11 @@ people using 80-column terminals.
defaults to UTF-8.
-
+
-PRETTY FORMATS
+
-
If the commit is a merge, and if the pretty-format
+
If the commit is a merge, and if the pretty-format
is not oneline , email or raw , an additional line is
inserted before the Author: line. This line begins with
"Merge: " and the sha1s of ancestral commits are printed,
@@ -351,9 +399,9 @@ separated by spaces. Note that the listed commits may not
necessarily be the list of the direct parent commits if you
have limited your view of history: for example, if you are
only interested in changes related to a certain directory or
-file.
-
Here are some additional details for each format:
-
+
Here are some additional details for each format:
+
-
This is designed to be as compact as possible.
+
This is designed to be as compact as possible.
@@ -386,7 +434,7 @@ Author: <author>
commit <sha1>
Author: <author>
-Date: <date>
+Date: <author date>
@@ -424,9 +472,9 @@ Commit: <committer>
commit <sha1>
Author: <author>
-AuthorDate: <date & time>
+AuthorDate: <author date>
Commit: <committer>
-CommitDate: <date & time>
+CommitDate: <committer date>
@@ -445,7 +493,7 @@ CommitDate: <date & time>
From <sha1> <date>
From: <author>
-Date: <date & time>
+Date: <author date>
Subject: [PATCH] <title line>
@@ -457,31 +505,31 @@ Subject: [PATCH] <title line>
raw
-
The raw format shows the entire commit exactly as
+
The raw format shows the entire commit exactly as
stored in the commit object. Notably, the SHA1s are
displayed in full, regardless of whether --abbrev or
--no-abbrev are used, and parents information show the
true parent commits, without taking grafts nor history
-simplification into account.
+simplification into account.
format:
-The format: format allows you to specify which information
+
The format: format allows you to specify which information
you want to show. It works a little bit like printf format,
with the notable exception that you get a newline with %n
-instead of \n .
-
E.g, format:"The author of %h was %an, %ar%nThe title was >>%s<<%n"
-would show something like this:
+instead of
\n .
+E.g, format:"The author of %h was %an, %ar%nThe title was >>%s<<%n"
+would show something like this:
The author of fe6e0ee was Junio C Hamano, 23 hours ago
The title was >>t4119: test autocomputing -p<n> for traditional diff input.<<
-The placeholders are:
-
tformat:
-The tformat: format works exactly like format: , except that it
+
The tformat: format works exactly like format: , except that it
provides "terminator" semantics instead of "separator" semantics. In
other words, each commit has the message terminator character (usually a
newline) appended, rather than a separator placed between entries.
This means that the final entry of a single-line format will be properly
terminated with a new line, just as the "oneline" format does.
-For example:
+For example:
$ git log -2 --pretty=format:%h 4da45bef \
@@ -658,11 +706,11 @@ $ git log -2 --pretty=tformat:%h 4da45bef \
7134973
-
+
-
EXAMPLES
+
EXAMPLES
-
+
git show v1.0.0
@@ -699,12 +747,12 @@ git show master:Makefile master:t/Makefile
of the branch master .
-
+
-
Discussion
+
Discussion
-
At the core level, git is character encoding agnostic.
-
+At the core level, git is character encoding agnostic.
+
-
Although we encourage that the commit log messages are encoded
+
+Although we encourage that the commit log messages are encoded
in UTF-8, both the core and git Porcelain are designed not to
force UTF-8 on projects. If all participants of a particular
project find it more convenient to use legacy encodings, git
does not forbid it. However, there are a few things to keep in
-mind.
-
+mind.
+
-git-commit-tree (hence, git-commit which uses it) issues
+git-commit-tree (hence, git-commit which uses it) issues
a warning if the commit log message given to it does not look
like a valid UTF-8 string, unless you explicitly say your
project uses a legacy encoding. The way to say this is to
@@ -749,14 +797,14 @@ mind.
[i18n]
commitencoding = ISO-8859-1
-
Commit objects created with the above setting record the value
+
Commit objects created with the above setting record the value
of i18n.commitencoding in its encoding header. This is to
help other people who look at them later. Lack of this header
-implies that the commit log message is encoded in UTF-8.
+implies that the commit log message is encoded in UTF-8.
-git-log , git-show and friends looks at the encoding
+git-log , git-show and friends looks at the encoding
header of a commit object, and tries to re-code the log
message into UTF-8 unless otherwise specified. You can
specify the desired output encoding with
@@ -767,32 +815,32 @@ implies that the commit log message is encoded in UTF-8.
[i18n]
logoutputencoding = ISO-8859-1
-If you do not have this configuration variable, the value of
-i18n.commitencoding is used instead.
+If you do not have this configuration variable, the value of
+i18n.commitencoding is used instead.
-
-Note that we deliberately chose not to re-code the commit log
+
+Note that we deliberately chose not to re-code the commit log
message when a commit is made to force UTF-8 at the commit
object level, because re-coding to UTF-8 is not necessarily a
-reversible operation.
+reversible operation.
-Author
+Author
-
Written by Linus Torvalds <torvalds@osdl.org> and
+
Written by Linus Torvalds <torvalds@osdl.org> and
Junio C Hamano <junkio@cox.net>. Significantly enhanced by
-Johannes Schindelin <Johannes.Schindelin@gmx.de>.
+Johannes Schindelin <Johannes.Schindelin@gmx.de>.
-Documentation
+Documentation
-
Documentation by David Greaves, Petr Baudis and the git-list <git@vger.kernel.org>.
+
Documentation by David Greaves, Petr Baudis and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-show.txt b/git-show.txt
index 70b54aec2..e0b52bcb3 100644
--- a/git-show.txt
+++ b/git-show.txt
@@ -16,16 +16,16 @@ Shows one or more objects (blobs, trees, tags and commits).
For commits it shows the log message and textual diff. It also
presents the merge commit in a special format as produced by
-`git-diff-tree --cc`.
+'git-diff-tree --cc'.
For tags, it shows the tag message and the referenced objects.
-For trees, it shows the names (equivalent to `git-ls-tree`
+For trees, it shows the names (equivalent to 'git-ls-tree'
with \--name-only).
For plain blobs, it shows the plain contents.
-The command takes options applicable to the `git-diff-tree` command to
+The command takes options applicable to the 'git-diff-tree' command to
control how the changes the commit introduces are shown.
This manual page describes only the most frequently used options.
diff --git a/git-stash.html b/git-stash.html
index ccc71e40b..97aa37e21 100644
--- a/git-stash.html
+++ b/git-stash.html
@@ -3,7 +3,7 @@
-
+
git-stash(1)
@@ -276,28 +324,28 @@ git-stash(1) Manual Page
git stash (list | show [<stash>] | apply [<stash>] | clear | drop [<stash>] | pop [<stash>])
git stash [save [<message>]]
-DESCRIPTION
+DESCRIPTION
-
Use git stash when you want to record the current state of the
+
Use git stash when you want to record the current state of the
working directory and the index, but want to go back to a clean
working directory. The command saves your local modifications away
-and reverts the working directory to match the HEAD commit.
-
The modifications stashed away by this command can be listed with
+and reverts the working directory to match the HEAD commit.
+
The modifications stashed away by this command can be listed with
git stash list , inspected with git stash show , and restored
(potentially on top of a different commit) with git stash apply .
Calling git stash without any arguments is equivalent to git stash save .
A stash is by default listed as "WIP on branchname …", but
you can give a more descriptive message on the command line when
-you create one.
-
The latest stash you created is stored in $GIT_DIR/refs/stash ; older
+you create one.
+
The latest stash you created is stored in $GIT_DIR/refs/stash ; older
stashes are found in the reflog of this reference and can be named using
the usual reflog syntax (e.g. stash@{0} is the most recently
created stash, stash@{1} is the one before it, stash@{2.hours.ago}
-is also possible).
+is also possible).
-OPTIONS
+OPTIONS
-
+
save [<message>]
@@ -325,8 +373,8 @@ list [<options>]
stash@{0}: WIP on submit: 6ebd0e2... Update git-stash documentation
stash@{1}: On master: 9cc0589... Add git-stash
-The command takes options applicable to the git-log
-command to control what is shown and how. See git-log(1) .
+The command takes options applicable to the git-log
+command to control what is shown and how. See git-log(1) .
show [<stash>]
@@ -336,7 +384,7 @@ show [<stash>]
Show the changes recorded in the stash as a diff between the
stashed state and its original parent. When no <stash> is given,
shows the latest one. By default, the command shows the diffstat, but
- it will accept any format known to git-diff (e.g., git stash show
+ it will accept any format known to git-diff (e.g., git stash show
-p stash@{1} to view the second most recent stash in patch form).
@@ -349,12 +397,12 @@ apply [--index] [<stash>]
working tree state. When no <stash> is given, applies the latest
one. The working directory must match the index.
- This operation can fail with conflicts; you need to resolve them
-by hand in the working tree.
-If the --index option is used, then tries to reinstate not only the working
+
This operation can fail with conflicts; you need to resolve them
+by hand in the working tree.
+If the --index option is used, then tries to reinstate not only the working
tree's changes, but also the index's ones. However, this can fail, when you
have conflicts (which are stored in the index, where you therefore can no
-longer apply the changes as they were originally).
+longer apply the changes as they were originally).
clear
@@ -384,28 +432,28 @@ pop [<stash>]
stash@{0} is assumed. See also apply .
-
+
-DISCUSSION
+DISCUSSION
-
A stash is represented as a commit whose tree records the state of the
+
A stash is represented as a commit whose tree records the state of the
working directory, and its first parent is the commit at HEAD when
the stash was created. The tree of the second parent records the
state of the index when the stash is made, and it is made a child of
-the HEAD commit. The ancestry graph looks like this:
+the
HEAD commit. The ancestry graph looks like this:
-
where H is the HEAD commit, I is a commit that records the state
+
where H is the HEAD commit, I is a commit that records the state
of the index, and W is a commit that records the state of the working
-tree.
+tree.
-EXAMPLES
+EXAMPLES
-
+
Pulling into a dirty tree
@@ -416,10 +464,10 @@ upstream changes that are possibly relevant to what you are
doing. When your local changes do not conflict with the changes in
the upstream, a simple git pull will let you move forward.
-However, there are cases in which your local changes do conflict with
+
However, there are cases in which your local changes do conflict with
the upstream changes, and git pull refuses to overwrite your
changes. In such a case, you can stash your changes away,
-perform a pull, and then unstash, like this:
+perform a pull, and then unstash, like this:
$ git pull
@@ -452,7 +500,7 @@ $ git checkout my_wip
$ git reset --soft HEAD^
... continue hacking ...
-You can use git-stash to simplify the above, like this:
+You can use git-stash to simplify the above, like this:
... hack hack hack ...
@@ -463,26 +511,26 @@ $ git stash apply
... continue hacking ...
-
+
-SEE ALSO
+SEE ALSO
-AUTHOR
+AUTHOR
-
Written by Nanako Shiraishi <nanako3@bluebottle.com>
+
Written by Nanako Shiraishi <nanako3@bluebottle.com>
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-stash.txt b/git-stash.txt
index 23ac33129..9b6b91109 100644
--- a/git-stash.txt
+++ b/git-stash.txt
@@ -56,7 +56,7 @@ stash@{0}: WIP on submit: 6ebd0e2... Update git-stash documentation
stash@{1}: On master: 9cc0589... Add git-stash
----------------------------------------------------------------
+
-The command takes options applicable to the `git-log`
+The command takes options applicable to the 'git-log'
command to control what is shown and how. See linkgit:git-log[1].
show []::
@@ -64,7 +64,7 @@ show []::
Show the changes recorded in the stash as a diff between the
stashed state and its original parent. When no `` is given,
shows the latest one. By default, the command shows the diffstat, but
- it will accept any format known to `git-diff` (e.g., `git stash show
+ it will accept any format known to 'git-diff' (e.g., `git stash show
-p stash@\{1}` to view the second most recent stash in patch form).
apply [--index] []::
@@ -158,7 +158,7 @@ $ git reset --soft HEAD^
... continue hacking ...
----------------------------------------------------------------
+
-You can use `git-stash` to simplify the above, like this:
+You can use 'git-stash' to simplify the above, like this:
+
----------------------------------------------------------------
... hack hack hack ...
diff --git a/git-status.html b/git-status.html
index 35677f961..ecbed675c 100644
--- a/git-status.html
+++ b/git-status.html
@@ -3,7 +3,7 @@
-
+
git-status(1)
@@ -272,67 +320,67 @@ git-status(1) Manual Page
SYNOPSIS
-DESCRIPTION
+DESCRIPTION
-
Displays paths that have differences between the index file and the
+
Displays paths that have differences between the index file and the
current HEAD commit, paths that have differences between the working
tree and the index file, and paths in the working tree that are not
tracked by git (and are not ignored by gitignore(5) ). The first
-are what you _would_ commit by running git commit ; the second and
-third are what you _could_ commit by running git-add before running
-git commit .
-
The command takes the same set of options as git-commit ; it
+are what you would commit by running git commit ; the second and
+third are what you could commit by running git-add before running
+git commit .
+
The command takes the same set of options as git-commit ; it
shows what would be committed if the same options are given to
-git-commit .
-
If there is no path that is different between the index file and
+git-commit .
+
If there is no path that is different between the index file and
the current HEAD commit (i.e., there is nothing to commit by running
-git commit ), the command exits with non-zero status.
+
git commit ), the command exits with non-zero status.
-OUTPUT
+OUTPUT
-
The output from this command is designed to be used as a commit
-template comment, and all the output lines are prefixed with # .
-
The paths mentioned in the output, unlike many other git commands, are
+
The output from this command is designed to be used as a commit
+template comment, and all the output lines are prefixed with # .
+
The paths mentioned in the output, unlike many other git commands, are
made relative to the current directory if you are working in a
subdirectory (this is on purpose, to help cutting and pasting). See
-the status.relativePaths config option below.
+the status.relativePaths config option below.
-CONFIGURATION
+CONFIGURATION
-
The command honors color.status (or status.color — they
+
The command honors color.status (or status.color — they
mean the same thing and the latter is kept for backward
compatibility) and color.status.<slot> configuration variables
-to colorize its output.
-
If the config variable status.relativePaths is set to false, then all
+to colorize its output.
+
If the config variable status.relativePaths is set to false, then all
paths shown are relative to the repository root, not to the current
-directory.
-
If status.submodulesummary is set to a non zero number or true (identical
+directory.
+
If status.submodulesummary is set to a non zero number or true (identical
to -1 or an unlimited number), the submodule summary will be enabled and a
summary of commits for modified submodules will be shown (see --summary-limit
-option of git-submodule(1) ).
+option of
git-submodule(1) ).
-SEE ALSO
+SEE ALSO
-Author
+Author
-
Written by Linus Torvalds <torvalds@osdl.org> and
-Junio C Hamano <junkio@cox.net>.
+
Written by Linus Torvalds <torvalds@osdl.org> and
+Junio C Hamano <junkio@cox.net>.
-Documentation
+Documentation
-
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-status.txt b/git-status.txt
index c9d4a046c..57b749823 100644
--- a/git-status.txt
+++ b/git-status.txt
@@ -17,12 +17,12 @@ current HEAD commit, paths that have differences between the working
tree and the index file, and paths in the working tree that are not
tracked by git (and are not ignored by linkgit:gitignore[5]). The first
are what you _would_ commit by running `git commit`; the second and
-third are what you _could_ commit by running `git-add` before running
+third are what you _could_ commit by running 'git-add' before running
`git commit`.
-The command takes the same set of options as `git-commit`; it
+The command takes the same set of options as 'git-commit'; it
shows what would be committed if the same options are given to
-`git-commit`.
+'git-commit'.
If there is no path that is different between the index file and
the current HEAD commit (i.e., there is nothing to commit by running
diff --git a/git-submodule.html b/git-submodule.html
index 8c5a62153..a222a7e4f 100644
--- a/git-submodule.html
+++ b/git-submodule.html
@@ -3,7 +3,7 @@
-
+
git-submodule(1)
@@ -279,9 +327,9 @@ git-submodule(1) Manual Page
git submodule [--quiet] update [--init] [--] [<path>…]
git submodule [--quiet] summary [--summary-limit <n>] [commit] [--] [<path>…]
-COMMANDS
+COMMANDS
-
+
add
@@ -305,11 +353,11 @@ status
Show the status of the submodules. This will print the SHA-1 of the
currently checked out commit for each submodule, along with the
- submodule path and the output of git-describe for the
+ submodule path and the output of git-describe for the
SHA-1. Each SHA-1 will be prefixed with - if the submodule is not
initialized and + if the currently checked out submodule commit
does not match the SHA-1 found in the index of the containing
- repository. This command is the default command for git-submodule .
+ repository. This command is the default command for git-submodule .
@@ -332,9 +380,9 @@ update
checkout the commit specified in the index of the containing repository.
This will make the submodules HEAD be detached.
-If the submodule is not yet initialized, and you just want to use the
+
If the submodule is not yet initialized, and you just want to use the
setting as stored in .gitmodules, you can automatically initialize the
-submodule with the --init option.
+submodule with the --init option.
summary
@@ -347,11 +395,11 @@ summary
index or working tree (switched by --cached) are shown.
-
+
-OPTIONS
+OPTIONS
-
+
-q
@@ -408,27 +456,27 @@ summary
to only operate on the submodules found at the specified paths.
-
+
-FILES
+FILES
-
When initializing submodules, a .gitmodules file in the top-level directory
+
When initializing submodules, a .gitmodules file in the top-level directory
of the containing repository is used to find the url of each submodule.
This file should be formatted in the same way as $GIT_DIR/config . The key
to each submodule url is "submodule.$name.url". See gitmodules(5)
-for details.
+for details.
-AUTHOR
+AUTHOR
-
Written by Lars Hjemli <hjemli@gmail.com>
+
Written by Lars Hjemli <hjemli@gmail.com>
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-submodule.txt b/git-submodule.txt
index 9c4052c58..105fc2dcd 100644
--- a/git-submodule.txt
+++ b/git-submodule.txt
@@ -32,11 +32,11 @@ add::
status::
Show the status of the submodules. This will print the SHA-1 of the
currently checked out commit for each submodule, along with the
- submodule path and the output of `git-describe` for the
+ submodule path and the output of 'git-describe' for the
SHA-1. Each SHA-1 will be prefixed with `-` if the submodule is not
initialized and `+` if the currently checked out submodule commit
does not match the SHA-1 found in the index of the containing
- repository. This command is the default command for `git-submodule`.
+ repository. This command is the default command for 'git-submodule'.
init::
Initialize the submodules, i.e. register in .git/config each submodule
diff --git a/git-svn.html b/git-svn.html
index 6c56d7df1..a740b8a4e 100644
--- a/git-svn.html
+++ b/git-svn.html
@@ -3,7 +3,7 @@
-
+
git-svn(1)
@@ -272,39 +320,39 @@ git-svn(1) Manual Page
SYNOPSIS
-
git svn <command> [options] [arguments]
+
git svn <command> [options] [arguments]
-DESCRIPTION
+DESCRIPTION
-
git-svn is a simple conduit for changesets between Subversion and git.
+
git-svn is a simple conduit for changesets between Subversion and git.
It is not to be confused with git-svnimport(1) , which is
-read-only.
-
git-svn was originally designed for an individual developer who wants a
+read-only.
+
git-svn was originally designed for an individual developer who wants a
bidirectional flow of changesets between a single branch in Subversion
and an arbitrary number of branches in git. Since its inception,
-git-svn has gained the ability to track multiple branches in a manner
-similar to git-svnimport .
-
git-svn is especially useful when it comes to tracking repositories
+git-svn has gained the ability to track multiple branches in a manner
+similar to git-svnimport .
+
git-svn is especially useful when it comes to tracking repositories
not organized in the way Subversion developers recommend (trunk,
-branches, tags directories).
+branches, tags directories).
-COMMANDS
+COMMANDS
-
+
init
Initializes an empty git repository with additional
- metadata directories for git-svn . The Subversion URL
+ metadata directories for git-svn . The Subversion URL
may be specified as a command-line argument, or as full
URL arguments to -T/-t/-b. Optionally, the target
directory to operate on can be specified as a second
argument. Normally this command initializes the current
directory.
-
+
-T<trunk_subdir>
@@ -420,7 +468,7 @@ branches, tags directories).
projects that share a common repository.
-
+
fetch
@@ -457,15 +505,15 @@ branches, tags directories).
This fetches revisions from the SVN parent of the current HEAD
and rebases the current (uncommitted to SVN) work against it.
-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 dcommiting with git-svn .
-This accepts all options that git-svn fetch and git-rebase
+
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 dcommiting with git-svn .
+This accepts all options that git-svn fetch and git-rebase
accept. However, --fetch-all only fetches from the current
-[svn-remote], and not all [svn-remote] definitions.
-
Like git-rebase ; this requires that the working tree be clean
-and have no uncommitted changes.
-
+[svn-remote], and not all [svn-remote] definitions.
+Like git-rebase ; this requires that the working tree be clean
+and have no uncommitted changes.
+
-l
@@ -474,11 +522,11 @@ and have no uncommitted changes.
- Do not fetch remotely; only run git-rebase against the
+ Do not fetch remotely; only run git-rebase against the
last fetched commit from the upstream SVN.
-
+
dcommit
@@ -489,7 +537,7 @@ and have no uncommitted changes.
repository, and then rebase or reset (depending on whether or
not there is a diff between SVN and head). This will create
a revision in SVN for each commit in git.
- It is recommended that you run git-svn fetch and rebase (not
+ It is recommended that you run git-svn fetch and rebase (not
pull or merge) your commits against the latest changes in the
SVN repository.
An optional command-line argument may be specified as an
@@ -497,7 +545,7 @@ and have no uncommitted changes.
This is advantageous over set-tree (below) because it produces
cleaner, more linear history.
-
+
--no-rebase
@@ -506,10 +554,10 @@ and have no uncommitted changes.
After committing, do not rebase or reset.
-
+
-
-
+
+
log
@@ -518,8 +566,8 @@ and have no uncommitted changes.
This should make it easy to look up svn log messages when svn
users refer to -r/--revision numbers.
-The following features from `svn log' are supported:
-
+The following features from `svn log' are supported:
+
--revision=<n>[:<n>]
@@ -555,9 +603,9 @@ and have no uncommitted changes.
supported
-
-
New features:
-
+
+
+
--show-commit
@@ -574,7 +622,7 @@ and have no uncommitted changes.
our version of --pretty=oneline
-
+
@@ -585,7 +633,7 @@ client converts the UTC time to the local time (or based on the TZ=
environment). This command has the same behaviour.
-Any other arguments are passed directly to git-log
+Any other arguments are passed directly to git-log
blame
@@ -594,27 +642,27 @@ environment). This command has the same behaviour.
Show what revision and author last modified each line of a file. The
output of this mode is format-compatible with the output of
- svn blame' by default. Like the SVN blame command,
+ `svn blame' by default. Like the SVN blame command,
local uncommitted changes in the working copy are ignored;
the version of the file in the HEAD revision is annotated. Unknown
- arguments are passed directly to `git-blame .
+ arguments are passed directly to git-blame .
-
+
--git-format
- Produce output in the same format as git-blame , but with
+ Produce output in the same format as git-blame , but with
SVN revision numbers instead of git commit hashes. In this mode,
changes that haven't been committed to SVN (including local
working-copy edits) are shown as revision 0.
-
+
-
-
+
+
find-rev
@@ -637,7 +685,7 @@ environment). This command has the same behaviour.
absolutely no attempts to do patching when committing to SVN, it
simply overwrites files with those specified in the tree or
commit. All merging is assumed to have taken place
- independently of git-svn functions.
+ independently of git-svn functions.
@@ -668,12 +716,12 @@ environment). This command has the same behaviour.
Commits the diff of two tree-ish arguments from the
command-line. This command is intended for interoperability with
- git-svnimport and does not rely on being inside an git-svn
+ git-svnimport and does not rely on being inside an git-svn
init -ed repository. This command takes three arguments, (a) the
original tree to diff against, (b) the new tree result, (c) the
URL of the target Subversion repository. The final argument
- (URL) may be omitted if you are working from a git-svn -aware
- repository (that has been init -ed with git-svn ).
+ (URL) may be omitted if you are working from a git-svn -aware
+ repository (that has been init -ed with git-svn ).
The -r<revision> option is required for this.
@@ -716,11 +764,11 @@ environment). This command has the same behaviour.
specific revision.
-
+
-OPTIONS
+OPTIONS
-
+
--shared[={false|true|umask|group|all|world|everybody}]
@@ -730,7 +778,7 @@ environment). This command has the same behaviour.
Only used with the init command.
- These are passed directly to git-init .
+ These are passed directly to git-init .
@@ -743,12 +791,12 @@ environment). This command has the same behaviour.
Used with the fetch command.
-This allows revision ranges for partial/cauterized history
+
This allows revision ranges for partial/cauterized history
to be supported. $NUMBER, $NUMBER1:$NUMBER2 (numeric ranges),
-$NUMBER:HEAD, and BASE:$NUMBER are all supported.
-
This can allow you to make partial mirrors when running fetch;
+$NUMBER:HEAD, and BASE:$NUMBER are all supported.
+This can allow you to make partial mirrors when running fetch;
but is generally not recommended because history will be skipped
-and lost.
+and lost.
-
@@ -760,9 +808,9 @@ and lost.
Only used with the set-tree command.
-Read a list of commits from stdin and commit them in reverse
+
Read a list of commits from stdin and commit them in reverse
order. Only the leading sha1 is read from each line, so
-git-rev-list --pretty=oneline output can be used.
+
git-rev-list --pretty=oneline output can be used.
--rmdir
@@ -771,12 +819,12 @@ order. Only the leading sha1 is read from each line, so
Only used with the dcommit , set-tree and commit-diff commands.
-Remove directories from the SVN tree if there are no files left
+
Remove directories from the SVN tree if there are no files left
behind. SVN can version empty directories, and they are not
removed by default if there are no files left in them. git
cannot version empty directories. Enabling this flag will make
-the commit to SVN act like git.
-
config key: svn.rmdir
+the commit to SVN act like git.
+
-e
@@ -788,10 +836,10 @@ the commit to SVN act like git.
Only used with the dcommit , set-tree and commit-diff commands.
-Edit the commit message before committing to SVN. This is off by
+
Edit the commit message before committing to SVN. This is off by
default for objects that are commits, and forced on when committing
-tree objects.
-
config key: svn.edit
+tree objects.
+
-l<num>
@@ -803,8 +851,8 @@ tree objects.
Only used with the dcommit , set-tree and commit-diff commands.
-They are both passed directly to git-diff-tree ; see
-git-diff-tree(1) for more information.
+They are both passed directly to git-diff-tree ; see
+git-diff-tree(1) for more information.
config key: svn.l
config key: svn.findcopiesharder
@@ -817,19 +865,19 @@ config key: svn.findcopiesharder
-Syntax is compatible with the files used by git-svnimport and
-git-cvsimport :
+Syntax is compatible with the files used by git-svnimport and
+git-cvsimport :
loginname = Joe User <user@example.com>
-If this option is specified and git-svn encounters an SVN
-committer name that does not exist in the authors-file, git-svn
+
If this option is specified and git-svn encounters an SVN
+committer name that does not exist in the authors-file, git-svn
will abort operation. The user will then have to add the
-appropriate entry. Re-running the previous git-svn command
-after the authors-file is modified should continue operation.
-
config key: svn.authorsfile
+appropriate entry. Re-running the previous
git-svn command
+after the authors-file is modified should continue operation.
+config key: svn.authorsfile
-q
@@ -839,7 +887,7 @@ after the authors-file is modified should continue operation.
- Make git-svn less verbose.
+ Make git-svn less verbose.
@@ -853,10 +901,10 @@ after the authors-file is modified should continue operation.
These should help keep disk usage sane for large fetches
with many revisions.
---repack takes an optional argument for the number of revisions
+
--repack takes an optional argument for the number of revisions
to fetch before repacking. This defaults to repacking every
-1000 commits fetched if no argument is specified.
-
--repack-flags are passed directly to git-repack .
+1000 commits fetched if no argument is specified.
+--repack-flags are passed directly to git-repack .
config key: svn.repack
config key: svn.repackflags
@@ -877,8 +925,8 @@ config key: svn.repackflags
These are only used with the dcommit and rebase commands.
-Passed directly to git-rebase when using dcommit if a
-git-reset cannot be used (see dcommit ).
+Passed directly to git-rebase when using dcommit if a
+git-reset cannot be used (see dcommit ).
-n
@@ -890,17 +938,17 @@ These are only used with the dcommit and rebase commands.
This can be used with the dcommit and rebase commands.
-For dcommit , print out the series of git arguments that would show
-which diffs would be committed to SVN.
-For rebase , display the local branch associated with the upstream svn
+
For dcommit , print out the series of git arguments that would show
+which diffs would be committed to SVN.
+For rebase , display the local branch associated with the upstream svn
repository associated with the current branch and the URL of svn
-repository that will be fetched from.
+repository that will be fetched from.
-
+
-ADVANCED OPTIONS
+ADVANCED OPTIONS
-
+
-i<GIT_SVN_ID>
@@ -939,13 +987,13 @@ no longer require this switch as an argument.
descended from. This feature is enabled by default, use
--no-follow-parent to disable it.
-config key: svn.followparent
+config key: svn.followparent
-
+
-CONFIG FILE-ONLY OPTIONS
+CONFIG FILE-ONLY OPTIONS
-
+
svn.noMetadata
@@ -956,12 +1004,12 @@ svn-remote.<name>.noMetadata
This gets rid of the git-svn-id: lines at the end of every commit.
-If you lose your .git/svn/git-svn/.rev_db file, git-svn will not
+
If you lose your .git/svn/git-svn/.rev_db file, git-svn will not
be able to rebuild it and you won't be able to fetch again,
-either. This is fine for one-shot imports.
-
The git-svn log command will not work on repositories using
+either. This is fine for one-shot imports.
+The git-svn log command will not work on repositories using
this, either. Using this conflicts with the useSvmProps
-option for (hopefully) obvious reasons.
+option for (hopefully) obvious reasons.
svn.useSvmProps
@@ -971,16 +1019,16 @@ svn-remote.<name>.useSvmProps
-This allows git-svn to re-map repository URLs and UUIDs from
+This allows git-svn to re-map repository URLs and UUIDs from
mirrors created using SVN::Mirror (or svk) for metadata.
-If an SVN revision has a property, "svm:headrev", it is likely
+
If an SVN revision has a property, "svm:headrev", it is likely
that the revision was created by SVN::Mirror (also used by SVK).
The property contains a repository UUID and a revision. We want
to make it look like we are mirroring the original URL, so
introduce a helper function that returns the original identity
URL and UUID, and use it when generating metadata in commit
-messages.
+messages.
svn.useSvnsyncProps
@@ -1001,23 +1049,23 @@ svn-remote.<name>.rewriteRoot
This allows users to create repositories from alternate
- URLs. For example, an administrator could run git-svn on the
+ URLs. For example, an administrator could run git-svn on the
server locally (accessing via file://) but wish to distribute
the repository with a public http:// or svn:// URL in the
metadata so users of it will see the public URL.
-
-
Since the noMetadata, rewriteRoot, useSvnsyncProps and useSvmProps
-options all affect the metadata generated and used by git-svn ; they
+
+Since the noMetadata, rewriteRoot, useSvnsyncProps and useSvmProps
+options all affect the metadata generated and used by git-svn ; they
must be set in the configuration file before any history is imported
-and these settings should never be changed once they are set.
-
Additionally, only one of these four options can be used per-svn-remote
-section because they affect the git-svn-id: metadata line.
+and these settings should never be changed once they are set.
+Additionally, only one of these four options can be used per-svn-remote
+section because they affect the git-svn-id: metadata line.
-BASIC EXAMPLES
+BASIC EXAMPLES
-
Tracking and contributing to the trunk of a Subversion-managed project:
+
Tracking and contributing to the trunk of a Subversion-managed project:
# Clone a repo (like git clone):
@@ -1037,8 +1085,8 @@ section because they affect the git-svn-id: metadata line.
# Append svn:ignore settings to the default git exclude file:
git svn show-ignore >> .git/info/exclude
-
Tracking and contributing to an entire Subversion-managed project
-(complete with a trunk, tags and branches):
+
Tracking and contributing to an entire Subversion-managed project
+(complete with a trunk, tags and branches):
# Clone a repo (like git clone):
@@ -1051,12 +1099,12 @@ section because they affect the git-svn-id: metadata line.
# You may only dcommit to one branch/tag/trunk at a time. The usage
# of dcommit/rebase/show-ignore should be the same as above.
-
The initial git-svn clone can be quite time-consuming
+
The initial git-svn clone can be quite time-consuming
(especially for large Subversion repositories). If multiple
people (or one person with multiple machines) want to use
-git-svn to interact with the same Subversion repository, you can
-do the initial git-svn clone to a repository on a server and
-have each person clone that repository with git-clone :
+
git-svn to interact with the same Subversion repository, you can
+do the initial
git-svn clone to a repository on a server and
+have each person clone that repository with
git-clone :
# Do the initial import on a server
@@ -1074,76 +1122,76 @@ have each person clone that repository with git-clone :
git svn rebase
-REBASE VS. PULL/MERGE
+REBASE VS. PULL/MERGE
-
Originally, git-svn recommended that the remotes/git-svn branch be
+
Originally, git-svn recommended that the remotes/git-svn branch be
pulled or merged from. This is because the author favored
git svn set-tree B to commit a single head rather than the
-git svn set-tree A..B notation to commit multiple commits.
-
If you use git svn set-tree A..B to commit several diffs and you do
+git svn set-tree A..B notation to commit multiple commits.
+
If you use git svn set-tree A..B to commit several diffs and you do
not have the latest remotes/git-svn merged into my-branch, you should
use git svn rebase to update your work branch instead of git pull or
git merge . pull /`merge' can cause non-linear history to be flattened
when committing into SVN, which can lead to merge commits reversing
-previous commits in SVN.
+previous commits in SVN.
-DESIGN PHILOSOPHY
+DESIGN PHILOSOPHY
-
Merge tracking in Subversion is lacking and doing branched development
-with Subversion can be cumbersome as a result. While git-svn can track
+
Merge tracking in Subversion is lacking and doing branched development
+with Subversion can be cumbersome as a result. While git-svn can track
copy history (including branches and tags) for repositories adopting a
standard layout, it cannot yet represent merge history that happened
inside git back upstream to SVN users. Therefore it is advised that
users keep history as linear as possible inside git to ease
-compatibility with SVN (see the CAVEATS section below).
+compatibility with SVN (see the CAVEATS section below).
-CAVEATS
+CAVEATS
-
For the sake of simplicity and interoperating with a less-capable system
-(SVN), it is recommended that all git-svn users clone, fetch and dcommit
-directly from the SVN server, and avoid all git-clone /pull /merge /push
+
For the sake of simplicity and interoperating with a less-capable system
+(SVN), it is recommended that all git-svn users clone, fetch and dcommit
+directly from the SVN server, and avoid all git-clone /pull /merge /push
operations between git repositories and branches. The recommended
method of exchanging code between git branches and users is
-git-format-patch and git-am , or just 'dcommit'ing to the SVN repository.
-
Running git-merge or git-pull is NOT recommended on a branch you
+git-format-patch and git-am , or just 'dcommit'ing to the SVN repository.
+
Running git-merge or git-pull is NOT recommended on a branch you
plan to dcommit from. Subversion does not represent merges in any
reasonable or useful fashion; so users using Subversion cannot see any
merges you've made. Furthermore, if you merge or pull from a git branch
that is a mirror of an SVN branch, dcommit may commit to the wrong
-branch.
-
git-clone does not clone branches under the refs/remotes/ hierarchy or
-any git-svn metadata, or config. So repositories created and managed with
-using git-svn should use rsync for cloning, if cloning is to be done
-at all.
-
Since dcommit uses rebase internally, any git branches you git-push to
+branch.
+
git-clone does not clone branches under the refs/remotes/ hierarchy or
+any git-svn metadata, or config. So repositories created and managed with
+using git-svn should use rsync for cloning, if cloning is to be done
+at all.
+
Since dcommit uses rebase internally, any git branches you git-push to
before dcommit on will require forcing an overwrite of the existing ref
on the remote repository. This is generally considered bad practice,
-see the git-push(1) documentation for details.
-
Do not use the --amend option of git-commit(1) on a change you've
+see the git-push(1) documentation for details.
+
Do not use the --amend option of git-commit(1) on a change you've
already dcommitted. It is considered bad practice to --amend commits
you've already pushed to a remote repository for other users, and
-dcommit with SVN is analogous to that.
+dcommit with SVN is analogous to that.
-BUGS
+BUGS
-
We ignore all SVN properties except svn:executable. Any unhandled
-properties are logged to $GIT_DIR/svn/<refname>/unhandled.log
-
Renamed and copied directories are not detected by git and hence not
+
We ignore all SVN properties except svn:executable. Any unhandled
+properties are logged to $GIT_DIR/svn/<refname>/unhandled.log
+
Renamed and copied directories are not detected by git and hence not
tracked when committing to SVN. I do not plan on adding support for
this as it's quite difficult and time-consuming to get working for all
the possible corner cases (git doesn't do it, either). Committing
renamed and copied files are fully supported if they're similar enough
-for git to detect them.
+for git to detect them.
-CONFIGURATION
+CONFIGURATION
-
git-svn stores [svn-remote] configuration information in the
+
git-svn stores [svn-remote] configuration information in the
repository .git/config file. It is similar the core git
[remote] sections except fetch keys do not accept glob
arguments; but they are instead handled by the branches
and tags keys. Since some SVN repositories are oddly
configured with multiple projects glob expansions such those
-listed below are allowed:
+listed below are allowed:
[svn-remote "project-a"]
@@ -1152,28 +1200,28 @@ listed below are allowed:
tags = tags/*/project-a:refs/remotes/project-a/tags/*
trunk = trunk/project-a:refs/remotes/project-a/trunk
-
Keep in mind that the (asterisk) wildcard of the local ref
+
Keep in mind that the (asterisk) wildcard of the local ref
(right of the : ) *must be the farthest right path component;
however the remote wildcard may be anywhere as long as it's own
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 .
+should be manually entered with a text-editor or using
git-config .
-SEE ALSO
+SEE ALSO
-Author
+Author
-
Written by Eric Wong <normalperson@yhbt.net>.
+
Written by Eric Wong <normalperson@yhbt.net>.
-Documentation
+Documentation
-
Written by Eric Wong <normalperson@yhbt.net>.
+
Written by Eric Wong <normalperson@yhbt.net>.
diff --git a/git-svn.txt b/git-svn.txt
index 6caa13061..e7c0f1c95 100644
--- a/git-svn.txt
+++ b/git-svn.txt
@@ -11,17 +11,17 @@ SYNOPSIS
DESCRIPTION
-----------
-`git-svn` is a simple conduit for changesets between Subversion and git.
+'git-svn' is a simple conduit for changesets between Subversion and git.
It is not to be confused with linkgit:git-svnimport[1], which is
read-only.
-`git-svn` was originally designed for an individual developer who wants a
+'git-svn' was originally designed for an individual developer who wants a
bidirectional flow of changesets between a single branch in Subversion
and an arbitrary number of branches in git. Since its inception,
-`git-svn` has gained the ability to track multiple branches in a manner
-similar to `git-svnimport`.
+'git-svn' has gained the ability to track multiple branches in a manner
+similar to 'git-svnimport'.
-`git-svn` is especially useful when it comes to tracking repositories
+'git-svn' is especially useful when it comes to tracking repositories
not organized in the way Subversion developers recommend (trunk,
branches, tags directories).
@@ -31,7 +31,7 @@ COMMANDS
'init'::
Initializes an empty git repository with additional
- metadata directories for `git-svn`. The Subversion URL
+ metadata directories for 'git-svn'. The Subversion URL
may be specified as a command-line argument, or as full
URL arguments to -T/-t/-b. Optionally, the target
directory to operate on can be specified as a second
@@ -107,20 +107,20 @@ COMMANDS
This fetches revisions from the SVN parent of the current HEAD
and rebases the current (uncommitted to SVN) work against it.
-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 dcommiting with `git-svn`.
+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 dcommiting with 'git-svn'.
-This accepts all options that `git-svn fetch` and `git-rebase`
+This accepts all options that 'git-svn fetch' and 'git-rebase'
accept. However, '--fetch-all' only fetches from the current
[svn-remote], and not all [svn-remote] definitions.
-Like `git-rebase`; this requires that the working tree be clean
+Like 'git-rebase'; this requires that the working tree be clean
and have no uncommitted changes.
-l;;
--local;;
- Do not fetch remotely; only run `git-rebase` against the
+ Do not fetch remotely; only run 'git-rebase' against the
last fetched commit from the upstream SVN.
'dcommit'::
@@ -128,7 +128,7 @@ and have no uncommitted changes.
repository, and then rebase or reset (depending on whether or
not there is a diff between SVN and head). This will create
a revision in SVN for each commit in git.
- It is recommended that you run `git-svn` fetch and rebase (not
+ It is recommended that you run 'git-svn' fetch and rebase (not
pull or merge) your commits against the latest changes in the
SVN repository.
An optional command-line argument may be specified as an
@@ -173,7 +173,7 @@ NOTE: SVN itself only stores times in UTC and nothing else. The regular svn
client converts the UTC time to the local time (or based on the TZ=
environment). This command has the same behaviour.
+
-Any other arguments are passed directly to `git-log`
+Any other arguments are passed directly to 'git-log'
'blame'::
Show what revision and author last modified each line of a file. The
@@ -181,10 +181,10 @@ Any other arguments are passed directly to `git-log`
`svn blame' by default. Like the SVN blame command,
local uncommitted changes in the working copy are ignored;
the version of the file in the HEAD revision is annotated. Unknown
- arguments are passed directly to `git-blame`.
+ arguments are passed directly to 'git-blame'.
+
--git-format;;
- Produce output in the same format as `git-blame`, but with
+ Produce output in the same format as 'git-blame', but with
SVN revision numbers instead of git commit hashes. In this mode,
changes that haven't been committed to SVN (including local
working-copy edits) are shown as revision 0.
@@ -203,7 +203,7 @@ Any other arguments are passed directly to `git-log`
absolutely no attempts to do patching when committing to SVN, it
simply overwrites files with those specified in the tree or
commit. All merging is assumed to have taken place
- independently of `git-svn` functions.
+ independently of 'git-svn' functions.
'create-ignore'::
Recursively finds the svn:ignore property on directories and
@@ -219,12 +219,12 @@ Any other arguments are passed directly to `git-log`
'commit-diff'::
Commits the diff of two tree-ish arguments from the
command-line. This command is intended for interoperability with
- `git-svnimport` and does not rely on being inside an `git-svn
+ 'git-svnimport' and does not rely on being inside an `git-svn
init`-ed repository. This command takes three arguments, (a) the
original tree to diff against, (b) the new tree result, (c) the
URL of the target Subversion repository. The final argument
- (URL) may be omitted if you are working from a `git-svn`-aware
- repository (that has been `init`-ed with `git-svn`).
+ (URL) may be omitted if you are working from a 'git-svn'-aware
+ repository (that has been `init`-ed with 'git-svn').
The -r option is required for this.
'info'::
@@ -255,7 +255,7 @@ OPTIONS
--shared[={false|true|umask|group|all|world|everybody}]::
--template=::
Only used with the 'init' command.
- These are passed directly to `git-init`.
+ These are passed directly to 'git-init'.
-r ::
--revision ::
@@ -277,7 +277,7 @@ Only used with the 'set-tree' command.
Read a list of commits from stdin and commit them in reverse
order. Only the leading sha1 is read from each line, so
-`git-rev-list --pretty=oneline` output can be used.
+'git-rev-list --pretty=oneline' output can be used.
--rmdir::
@@ -307,7 +307,7 @@ config key: svn.edit
Only used with the 'dcommit', 'set-tree' and 'commit-diff' commands.
-They are both passed directly to `git-diff-tree`; see
+They are both passed directly to 'git-diff-tree'; see
linkgit:git-diff-tree[1] for more information.
[verse]
@@ -317,24 +317,24 @@ config key: svn.findcopiesharder
-A::
--authors-file=::
-Syntax is compatible with the files used by `git-svnimport` and
-`git-cvsimport`:
+Syntax is compatible with the files used by 'git-svnimport' and
+'git-cvsimport':
------------------------------------------------------------------------
loginname = Joe User
------------------------------------------------------------------------
-If this option is specified and `git-svn` encounters an SVN
-committer name that does not exist in the authors-file, `git-svn`
+If this option is specified and 'git-svn' encounters an SVN
+committer name that does not exist in the authors-file, 'git-svn'
will abort operation. The user will then have to add the
-appropriate entry. Re-running the previous `git-svn` command
+appropriate entry. Re-running the previous 'git-svn' command
after the authors-file is modified should continue operation.
config key: svn.authorsfile
-q::
--quiet::
- Make `git-svn` less verbose.
+ Make 'git-svn' less verbose.
--repack[=]::
--repack-flags=::
@@ -346,7 +346,7 @@ with many revisions.
to fetch before repacking. This defaults to repacking every
1000 commits fetched if no argument is specified.
---repack-flags are passed directly to `git-repack`.
+--repack-flags are passed directly to 'git-repack'.
[verse]
config key: svn.repack
@@ -359,8 +359,8 @@ config key: svn.repackflags
These are only used with the 'dcommit' and 'rebase' commands.
-Passed directly to `git-rebase` when using 'dcommit' if a
-`git-reset` cannot be used (see 'dcommit').
+Passed directly to 'git-rebase' when using 'dcommit' if a
+'git-reset' cannot be used (see 'dcommit').
-n::
--dry-run::
@@ -413,18 +413,18 @@ svn-remote..noMetadata::
This gets rid of the 'git-svn-id:' lines at the end of every commit.
-If you lose your .git/svn/git-svn/.rev_db file, `git-svn` will not
+If you lose your .git/svn/git-svn/.rev_db file, 'git-svn' will not
be able to rebuild it and you won't be able to fetch again,
either. This is fine for one-shot imports.
-The `git-svn log` command will not work on repositories using
+The 'git-svn log' command will not work on repositories using
this, either. Using this conflicts with the 'useSvmProps'
option for (hopefully) obvious reasons.
svn.useSvmProps::
svn-remote..useSvmProps::
-This allows `git-svn` to re-map repository URLs and UUIDs from
+This allows 'git-svn' to re-map repository URLs and UUIDs from
mirrors created using SVN::Mirror (or svk) for metadata.
If an SVN revision has a property, "svm:headrev", it is likely
@@ -443,7 +443,7 @@ svn-remote..useSvnsyncprops::
svn-remote..rewriteRoot::
This allows users to create repositories from alternate
- URLs. For example, an administrator could run `git-svn` on the
+ URLs. For example, an administrator could run 'git-svn' on the
server locally (accessing via file://) but wish to distribute
the repository with a public http:// or svn:// URL in the
metadata so users of it will see the public URL.
@@ -451,7 +451,7 @@ svn-remote..rewriteRoot::
--
Since the noMetadata, rewriteRoot, useSvnsyncProps and useSvmProps
-options all affect the metadata generated and used by `git-svn`; they
+options all affect the metadata generated and used by 'git-svn'; they
*must* be set in the configuration file before any history is imported
and these settings should never be changed once they are set.
@@ -498,12 +498,12 @@ Tracking and contributing to an entire Subversion-managed project
# of dcommit/rebase/show-ignore should be the same as above.
------------------------------------------------------------------------
-The initial `git-svn clone` can be quite time-consuming
+The initial 'git-svn clone' can be quite time-consuming
(especially for large Subversion repositories). If multiple
people (or one person with multiple machines) want to use
-`git-svn` to interact with the same Subversion repository, you can
-do the initial `git-svn clone` to a repository on a server and
-have each person clone that repository with `git-clone`:
+'git-svn' to interact with the same Subversion repository, you can
+do the initial 'git-svn clone' to a repository on a server and
+have each person clone that repository with 'git-clone':
------------------------------------------------------------------------
# Do the initial import on a server
@@ -524,7 +524,7 @@ have each person clone that repository with `git-clone`:
REBASE VS. PULL/MERGE
---------------------
-Originally, `git-svn` recommended that the 'remotes/git-svn' branch be
+Originally, 'git-svn' recommended that the 'remotes/git-svn' branch be
pulled or merged from. This is because the author favored
`git svn set-tree B` to commit a single head rather than the
`git svn set-tree A..B` notation to commit multiple commits.
@@ -539,7 +539,7 @@ previous commits in SVN.
DESIGN PHILOSOPHY
-----------------
Merge tracking in Subversion is lacking and doing branched development
-with Subversion can be cumbersome as a result. While `git-svn` can track
+with Subversion can be cumbersome as a result. While 'git-svn' can track
copy history (including branches and tags) for repositories adopting a
standard layout, it cannot yet represent merge history that happened
inside git back upstream to SVN users. Therefore it is advised that
@@ -550,25 +550,25 @@ CAVEATS
-------
For the sake of simplicity and interoperating with a less-capable system
-(SVN), it is recommended that all `git-svn` users clone, fetch and dcommit
-directly from the SVN server, and avoid all `git-clone`/`pull`/`merge`/`push`
+(SVN), it is recommended that all 'git-svn' users clone, fetch and dcommit
+directly from the SVN server, and avoid all 'git-clone'/'pull'/'merge'/'push'
operations between git repositories and branches. The recommended
method of exchanging code between git branches and users is
-`git-format-patch` and `git-am`, or just 'dcommit'ing to the SVN repository.
+'git-format-patch' and 'git-am', or just 'dcommit'ing to the SVN repository.
-Running `git-merge` or `git-pull` is NOT recommended on a branch you
+Running 'git-merge' or 'git-pull' is NOT recommended on a branch you
plan to 'dcommit' from. Subversion does not represent merges in any
reasonable or useful fashion; so users using Subversion cannot see any
merges you've made. Furthermore, if you merge or pull from a git branch
that is a mirror of an SVN branch, 'dcommit' may commit to the wrong
branch.
-`git-clone` does not clone branches under the refs/remotes/ hierarchy or
-any `git-svn` metadata, or config. So repositories created and managed with
-using `git-svn` should use `rsync` for cloning, if cloning is to be done
+'git-clone' does not clone branches under the refs/remotes/ hierarchy or
+any 'git-svn' metadata, or config. So repositories created and managed with
+using 'git-svn' should use 'rsync' for cloning, if cloning is to be done
at all.
-Since 'dcommit' uses rebase internally, any git branches you `git-push` to
+Since 'dcommit' uses rebase internally, any git branches you 'git-push' to
before 'dcommit' on will require forcing an overwrite of the existing ref
on the remote repository. This is generally considered bad practice,
see the linkgit:git-push[1] documentation for details.
@@ -594,7 +594,7 @@ for git to detect them.
CONFIGURATION
-------------
-`git-svn` stores [svn-remote] configuration information in the
+'git-svn' stores [svn-remote] configuration information in the
repository .git/config file. It is similar the core git
[remote] sections except 'fetch' keys do not accept glob
arguments; but they are instead handled by the 'branches'
@@ -615,7 +615,7 @@ Keep in mind that the '*' (asterisk) wildcard of the local ref
however the remote wildcard may be anywhere as long as it's own
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`.
+should be manually entered with a text-editor or using 'git-config'.
SEE ALSO
--------
diff --git a/git-symbolic-ref.html b/git-symbolic-ref.html
index 548a51517..d6a740880 100644
--- a/git-symbolic-ref.html
+++ b/git-symbolic-ref.html
@@ -3,7 +3,7 @@
-
+
git-symbolic-ref(1)
@@ -272,23 +320,23 @@ git-symbolic-ref(1) Manual Page
SYNOPSIS
-
git symbolic-ref [-q] [-m <reason>] <name> [<ref>]
+
git symbolic-ref [-q] [-m <reason>] <name> [<ref>]
-DESCRIPTION
+DESCRIPTION
-
Given one argument, reads which branch head the given symbolic
+
Given one argument, reads which branch head the given symbolic
ref refers to and outputs its path, relative to the .git/
directory. Typically you would give HEAD as the <name>
-argument to see on which branch your working tree is on.
-
Give two arguments, create or update a symbolic ref <name> to
-point at the given branch <ref>.
-
A symbolic ref is a regular file that stores a string that
+argument to see on which branch your working tree is on.
+
Give two arguments, create or update a symbolic ref <name> to
+point at the given branch <ref>.
+
A symbolic ref is a regular file that stores a string that
begins with ref: refs/ . For example, your .git/HEAD is
-a regular file whose contents is ref: refs/heads/master .
+a regular file whose contents is
ref: refs/heads/master .
-OPTIONS
+OPTIONS
-
+
-q
@@ -311,11 +359,11 @@ a regular file whose contents is ref: refs/heads/master .
when creating or updating a symbolic ref.
-
+
-NOTES
+NOTES
-
In the past, .git/HEAD was a symbolic link pointing at
+
In the past, .git/HEAD was a symbolic link pointing at
refs/heads/master . When we wanted to switch to another branch,
we did ln -sf refs/heads/newbranch .git/HEAD , and when we wanted
to find out which branch we are on, we did readlink .git/HEAD .
@@ -324,22 +372,22 @@ default, but on platforms that do not have working symlinks,
or that do not have the readlink(1) command, this was a bit
cumbersome. On some platforms, ln -sf does not even work as
advertised (horrors). Therefore symbolic links are now deprecated
-and symbolic refs are used by default.
-
git-symbolic-ref will exit with status 0 if the contents of the
+and symbolic refs are used by default.
+
git-symbolic-ref will exit with status 0 if the contents of the
symbolic ref were printed correctly, with status 1 if the requested
-name is not a symbolic ref, or 128 if another error occurs.
+name is not a symbolic ref, or 128 if another error occurs.
-Author
+Author
-
Written by Junio C Hamano <junkio@cox.net>
+
Written by Junio C Hamano <junkio@cox.net>
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-symbolic-ref.txt b/git-symbolic-ref.txt
index a4962413d..6266e6f65 100644
--- a/git-symbolic-ref.txt
+++ b/git-symbolic-ref.txt
@@ -49,7 +49,7 @@ cumbersome. On some platforms, `ln -sf` does not even work as
advertised (horrors). Therefore symbolic links are now deprecated
and symbolic refs are used by default.
-`git-symbolic-ref` will exit with status 0 if the contents of the
+'git-symbolic-ref' will exit with status 0 if the contents of the
symbolic ref were printed correctly, with status 1 if the requested
name is not a symbolic ref, or 128 if another error occurs.
diff --git a/git-tag.html b/git-tag.html
index ad0f3dcb8..da821292b 100644
--- a/git-tag.html
+++ b/git-tag.html
@@ -3,7 +3,7 @@
-
+
git-tag(1)
@@ -278,27 +326,27 @@ git-tag(1) Manual Page
git tag [-n[<num>]] -l [<pattern>]
git tag -v <name>…
-DESCRIPTION
+DESCRIPTION
-
Adds a tag reference in .git/refs/tags/
-
Unless -f is given, the tag must not yet exist in
-.git/refs/tags/ directory.
-
If one of -a , -s , or -u <key-id> is passed, the command
+
Adds a tag reference in .git/refs/tags/
+
Unless -f is given, the tag must not yet exist in
+.git/refs/tags/ directory.
+
If one of -a , -s , or -u <key-id> is passed, the command
creates a tag object, and requires the tag message. Unless
-m <msg> or -F <file> is given, an editor is started for the user to type
-in the tag message.
-
If -m <msg> or -F <file> is given and -a , -s , and -u <key-id>
-are absent, -a is implied.
-
Otherwise just the SHA1 object name of the commit object is
-written (i.e. a lightweight tag).
-
A GnuPG signed tag object will be created when -s or -u
+in the tag message.
+
If -m <msg> or -F <file> is given and -a , -s , and -u <key-id>
+are absent, -a is implied.
+
Otherwise just the SHA1 object name of the commit object is
+written (i.e. a lightweight tag).
+
A GnuPG signed tag object will be created when -s or -u
<key-id> is used. When -u <key-id> is not used, the
committer identity for the current user is used to find the
-GnuPG key for signing.
+GnuPG key for signing.
-OPTIONS
+OPTIONS
-
+
-a
@@ -390,31 +438,31 @@ GnuPG key for signing.
is given.
-
+
-CONFIGURATION
+CONFIGURATION
-
By default, git-tag in sign-with-default mode (-s) will use your
+
By default, git-tag in sign-with-default mode (-s) will use your
committer identity (of the form "Your Name <your@email.address>") to
find a key. If you want to use a different default key, you can specify
-it in the repository configuration as follows:
+it in the repository configuration as follows:
[user]
signingkey = <gpg-key-id>
-DISCUSSION
+DISCUSSION
-
On Re-tagging
-
What should you do when you tag a wrong commit and you would
-want to re-tag?
-
If you never pushed anything out, just re-tag it. Use "-f" to
-replace the old one. And you're done.
-
But if you have pushed things out (or others could just read
+
On Re-tagging
+
What should you do when you tag a wrong commit and you would
+want to re-tag?
+
If you never pushed anything out, just re-tag it. Use "-f" to
+replace the old one. And you're done.
+
But if you have pushed things out (or others could just read
your repository directly), then others will have already seen
-the old tag. In that case you can do one of two things:
-
+the old tag. In that case you can do one of two things:
+
The sane thing.
@@ -429,21 +477,21 @@ and be done with it.
The insane thing.
You really want to call the new version "X" too, even though
-others have already seen the old one. So just use git-tag -f
+others have already seen the old one. So just use git-tag -f
again, as if you hadn't already published the old one.
-
-
However, Git does not (and it should not) change tags behind
+
+
However, Git does not (and it should not) change tags behind
users back. So if somebody already got the old tag, doing a
-git-pull on your tree shouldn't just make them overwrite the old
-one.
-
If somebody got a release tag from you, you cannot just change
+git-pull on your tree shouldn't just make them overwrite the old
+one.
+
If somebody got a release tag from you, you cannot just change
the tag for them by updating your own one. This is a big
security issue, in that people MUST be able to trust their
tag-names. If you really want to do the insane thing, you need
to just fess up to it, and tell people that you messed up. You
-can do that by making a very public announcement saying:
+can do that by making a very public announcement saying:
Ok, I messed up, and I pushed out an earlier version tagged as X. I
@@ -465,24 +513,24 @@ which should return 0123456789abcdef.. if you have the new version.
Sorry for inconvenience.
-
Does this seem a bit complicated? It should be. There is no
+
Does this seem a bit complicated? It should be. There is no
way that it would be correct to just "fix" it behind peoples
backs. People need to know that their tags might have been
-changed.
-
On Automatic following
-
If you are following somebody else's tree, you are most likely
+changed.
+
On Automatic following
+
If you are following somebody else's tree, you are most likely
using tracking branches (refs/heads/origin in traditional
layout, or refs/remotes/origin/master in the separate-remote
-layout). You usually want the tags from the other end.
-
On the other hand, if you are fetching because you would want a
+layout). You usually want the tags from the other end.
+
On the other hand, if you are fetching because you would want a
one-shot merge from somebody else, you typically do not want to
get tags from there. This happens more often for people near
the toplevel but not limited to them. Mere mortals when pulling
from each other do not necessarily want to automatically get
-private anchor point tags from the other person.
-
You would notice "please pull" messages on the mailing list says
+private anchor point tags from the other person.
+
You would notice "please pull" messages on the mailing list says
repo URL and branch name alone. This is designed to be easily
-cut&pasted to a git-fetch command line:
+cut&pasted to a
git-fetch command line:
Linus, please pull from
@@ -491,21 +539,21 @@ cut&pasted to a git-fetch command line:
to get the following updates...
-
becomes:
+
$ git pull git://git..../proj.git master
-
In such a case, you do not want to automatically follow other's
-tags.
-
One important aspect of git is it is distributed, and being
+
In such a case, you do not want to automatically follow other's
+tags.
+
One important aspect of git is it is distributed, and being
distributed largely means there is no inherent "upstream" or
"downstream" in the system. On the face of it, the above
example might seem to indicate that the tag namespace is owned
by upper echelon of people and tags only flow downwards, but
that is not the case. It only shows that the usage pattern
-determines who are interested in whose tags.
-
A one-shot pull is a sign that a commit history is now crossing
+determines who are interested in whose tags.
+
A one-shot pull is a sign that a commit history is now crossing
the boundary between one circle of people (e.g. "people who are
primarily interested in networking part of the kernel") who may
have their own set of tags (e.g. "this is the third release
@@ -515,44 +563,44 @@ consumption with 2.6.21 release") to another circle of people
The latter are usually not interested in the detailed tags used
internally in the former group (that is what "internal" means).
That is why it is desirable not to follow tags automatically in
-this case.
-
It may well be that among networking people, they may want to
+this case.
+
It may well be that among networking people, they may want to
exchange the tags internal to their group, but in that workflow
they are most likely tracking with each other's progress by
having tracking branches. Again, the heuristic to automatically
-follow such tags is a good thing.
-
On Backdating Tags
-
If you have imported some changes from another VCS and would like
+follow such tags is a good thing.
+
+
If you have imported some changes from another VCS and would like
to add tags for major releases of your work, it is useful to be able
to specify the date to embed inside of the tag object. The data in
the tag object affects, for example, the ordering of tags in the
-gitweb interface.
-
To set the date used in future tag objects, set the environment
+gitweb interface.
+
To set the date used in future tag objects, set the environment
variable GIT_COMMITTER_DATE to one or more of the date and time. The
date and time can be specified in a number of ways; the most common
-is "YYYY-MM-DD HH:MM".
-
An example follows.
+is "YYYY-MM-DD HH:MM".
+
$ GIT_COMMITTER_DATE="2006-10-02 10:31" git tag -s v1.0.1
-Author
+Author
-
Written by Linus Torvalds <torvalds@osdl.org>,
-Junio C Hamano <junkio@cox.net> and Chris Wright <chrisw@osdl.org>.
+
Written by Linus Torvalds <torvalds@osdl.org>,
+Junio C Hamano <junkio@cox.net> and Chris Wright <chrisw@osdl.org>.
-Documentation
+Documentation
-
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-tag.txt b/git-tag.txt
index 1db98e2d0..b605e6caa 100644
--- a/git-tag.txt
+++ b/git-tag.txt
@@ -82,7 +82,7 @@ OPTIONS
CONFIGURATION
-------------
-By default, `git-tag` in sign-with-default mode (-s) will use your
+By default, 'git-tag' in sign-with-default mode (-s) will use your
committer identity (of the form "Your Name ") to
find a key. If you want to use a different default key, you can specify
it in the repository configuration as follows:
@@ -118,12 +118,12 @@ and be done with it.
. The insane thing.
You really want to call the new version "X" too, 'even though'
-others have already seen the old one. So just use `git-tag -f`
+others have already seen the old one. So just use 'git-tag -f'
again, as if you hadn't already published the old one.
However, Git does *not* (and it should not) change tags behind
users back. So if somebody already got the old tag, doing a
-`git-pull` on your tree shouldn't just make them overwrite the old
+'git-pull' on your tree shouldn't just make them overwrite the old
one.
If somebody got a release tag from you, you cannot just change
@@ -177,7 +177,7 @@ private anchor point tags from the other person.
You would notice "please pull" messages on the mailing list says
repo URL and branch name alone. This is designed to be easily
-cut&pasted to a `git-fetch` command line:
+cut&pasted to a 'git-fetch' command line:
------------
Linus, please pull from
diff --git a/git-tar-tree.html b/git-tar-tree.html
index a65ac83eb..48418477b 100644
--- a/git-tar-tree.html
+++ b/git-tar-tree.html
@@ -3,7 +3,7 @@
-
+
git-tar-tree(1)
@@ -272,25 +320,25 @@ git-tar-tree(1) Manual Page
SYNOPSIS
-
git tar-tree [--remote=<repo>] <tree-ish> [ <base> ]
+
git tar-tree [--remote=<repo>] <tree-ish> [ <base> ]
-DESCRIPTION
+DESCRIPTION
-
THIS COMMAND IS DEPRECATED. Use git-archive with --format=tar
-option instead (and move the <base> argument to --prefix=base/ ).
-
Creates a tar archive containing the tree structure for the named tree.
+
THIS COMMAND IS DEPRECATED. Use git-archive with --format=tar
+option instead (and move the <base> argument to --prefix=base/ ).
+
Creates a tar archive containing the tree structure for the named tree.
When <base> is specified it is added as a leading path to the files in the
-generated tar archive.
-
git-tar-tree behaves differently when given a tree ID versus when given
+generated tar archive.
+
git-tar-tree behaves differently when given a tree ID versus when given
a commit ID or tag ID. In the first case the current time is used as
modification time of each file in the archive. In the latter case the
commit time as recorded in the referenced commit object is used instead.
Additionally the commit ID is stored in a global extended pax header.
-It can be extracted using git-get-tar-commit-id .
+It can be extracted using
git-get-tar-commit-id .
-OPTIONS
+OPTIONS
-
+
<tree-ish>
@@ -317,11 +365,11 @@ It can be extracted using git-get-tar-commit-id .
retrieve a tar archive from a remote repository.
-
+
-CONFIGURATION
+CONFIGURATION
-
+
tar.umask
@@ -334,11 +382,11 @@ tar.umask
details.
-
+
-EXAMPLES
+EXAMPLES
-
+
git tar-tree HEAD junk | (cd /var/tmp/ && tar xf -)
@@ -383,23 +431,23 @@ git tar-tree HEAD:Documentation/ git-docs > git-1.4.0-docs.tar
into git-1.4.0-docs.tar , with the prefix git-docs/ .
-
+
-Author
+Author
-
Written by Rene Scharfe.
+
-Documentation
+Documentation
-
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-tar-tree.txt b/git-tar-tree.txt
index b3097aa79..a5d9558dd 100644
--- a/git-tar-tree.txt
+++ b/git-tar-tree.txt
@@ -12,19 +12,19 @@ SYNOPSIS
DESCRIPTION
-----------
-THIS COMMAND IS DEPRECATED. Use `git-archive` with `--format=tar`
+THIS COMMAND IS DEPRECATED. Use 'git-archive' with `--format=tar`
option instead (and move the argument to `--prefix=base/`).
Creates a tar archive containing the tree structure for the named tree.
When is specified it is added as a leading path to the files in the
generated tar archive.
-`git-tar-tree` behaves differently when given a tree ID versus when given
+'git-tar-tree' behaves differently when given a tree ID versus when given
a commit ID or tag ID. In the first case the current time is used as
modification time of each file in the archive. In the latter case the
commit time as recorded in the referenced commit object is used instead.
Additionally the commit ID is stored in a global extended pax header.
-It can be extracted using `git-get-tar-commit-id`.
+It can be extracted using 'git-get-tar-commit-id'.
OPTIONS
-------
diff --git a/git-update-index.html b/git-update-index.html
index cc6b77816..be8215530 100644
--- a/git-update-index.html
+++ b/git-update-index.html
@@ -3,7 +3,7 @@
-
+
git-update-index(1)
@@ -286,19 +334,19 @@ git-update-index(1) Manual Page
[--verbose]
[--] [<file>]*
-DESCRIPTION
+DESCRIPTION
-
Modifies the index or directory cache. Each file mentioned is updated
+
Modifies the index or directory cache. Each file mentioned is updated
into the index and any unmerged or needs updating state is
-cleared.
-
See also git-add(1) for a more user-friendly way to do some of
-the most common operations on the index.
-
The way git-update-index handles files it is told about can be modified
-using the various options:
+cleared.
+
See also git-add(1) for a more user-friendly way to do some of
+the most common operations on the index.
+
The way git-update-index handles files it is told about can be modified
+using the various options:
-OPTIONS
+OPTIONS
-
+
--add
@@ -335,21 +383,21 @@ using the various options:
Quiet. If --refresh finds that the index needs an update, the
default behavior is to error out. This option makes
- git-update-index continue anyway.
+ git-update-index continue anyway.
-
-
--ignore-submodules:
+
+--ignore-submodules:
Do not try to update submodules. This option is only respected
- when passed before --refresh.
-
+ when passed before --refresh.
+
--unmerged
If --refresh finds unmerged changes in the index, the default
- behavior is to error out. This option makes git-update-index
+ behavior is to error out. This option makes git-update-index
continue anyway.
@@ -413,7 +461,7 @@ using the various options:
- Runs git-update-index itself on the paths whose index
+ Runs git-update-index itself on the paths whose index
entries are different from those from the HEAD commit.
@@ -451,7 +499,7 @@ using the various options:
By default, when a file path exists in the index,
- git-update-index refuses an attempt to add path/file .
+ git-update-index refuses an attempt to add path/file .
Similarly if a file path/file exists, a file path
cannot be added. With --replace flag, existing entries
that conflicts with the entry being added are
@@ -505,76 +553,76 @@ using the various options:
The same applies to directories ending / and paths with //
-
+
-Using --refresh
+Using --refresh
-
--refresh does not calculate a new sha1 file or bring the index
+
--refresh does not calculate a new sha1 file or bring the index
up-to-date for mode/content changes. But what it does do is to
"re-match" the stat information of a file with the index, so that you
can refresh the index for a file that hasn't been changed but where
-the stat entry is out of date.
-
For example, you'd want to do this after doing a git-read-tree , to link
-up the stat index details with the proper files.
+the stat entry is out of date.
+
For example, you'd want to do this after doing a git-read-tree , to link
+up the stat index details with the proper files.
-Using --cacheinfo or --info-only
+Using --cacheinfo or --info-only
-
--cacheinfo is used to register a file that is not in the
+
--cacheinfo is used to register a file that is not in the
current working directory. This is useful for minimum-checkout
-merging.
-
To pretend you have a file with mode and sha1 at path, say:
+merging.
+
To pretend you have a file with mode and sha1 at path, say:
$ git update-index --cacheinfo mode sha1 path
-
--info-only is used to register files without placing them in the object
-database. This is useful for status-only repositories.
-
Both --cacheinfo and --info-only behave similarly: the index is updated
+
--info-only is used to register files without placing them in the object
+database. This is useful for status-only repositories.
+
Both --cacheinfo and --info-only behave similarly: the index is updated
but the object database isn't. --cacheinfo is useful when the object is
in the database but the file isn't available locally. --info-only is
useful when the file is available, but you do not wish to update the
-object database.
+object database.
-Using --index-info
+Using --index-info
-
--index-info is a more powerful mechanism that lets you feed
+
--index-info is a more powerful mechanism that lets you feed
multiple entry definitions from the standard input, and designed
-specifically for scripts. It can take inputs of three formats:
-
+specifically for scripts. It can take inputs of three formats:
+
mode SP sha1 TAB path
-The first format is what "git-apply --index-info"
+
The first format is what "git-apply --index-info"
reports, and used to reconstruct a partial tree
that is used for phony merge base tree when falling
-back on 3-way merge.
+back on 3-way merge.
mode SP type SP sha1 TAB path
-The second format is to stuff git-ls-tree output
-into the index file.
+The second format is to stuff git-ls-tree output
+into the index file.
mode SP sha1 SP stage TAB path
-This format is to put higher order stages into the
-index file and matches git-ls-files --stage output.
+This format is to put higher order stages into the
+index file and matches git-ls-files --stage output.
-
-
To place a higher stage entry to the index, the path should
+
+
To place a higher stage entry to the index, the path should
first be removed by feeding a mode=0 entry for the path, and
-then feeding necessary input lines in the third format.
-
For example, starting with this index:
+then feeding necessary input lines in the third format.
+
For example, starting with this index:
$ git ls-files -s
100644 8a1218a1024a212bb3db30becd860315f9f3ac52 0 frotz
-
you can feed the following input to --index-info :
+
you can feed the following input to --index-info :
$ git update-index --index-info
@@ -582,10 +630,10 @@ then feeding necessary input lines in the third format.
100644 8a1218a1024a212bb3db30becd860315f9f3ac52 1 frotz
100755 8a1218a1024a212bb3db30becd860315f9f3ac52 2 frotz
-
The first line of the input feeds 0 as the mode to remove the
+
The first line of the input feeds 0 as the mode to remove the
path; the SHA1 does not matter as long as it is well formatted.
Then the second and third line feeds stage 1 and stage 2 entries
-for that path. After the above, we would end up with this:
+for that path. After the above, we would end up with this:
$ git ls-files -s
@@ -593,9 +641,9 @@ for that path. After the above, we would end up with this:
100755 8a1218a1024a212bb3db30becd860315f9f3ac52 2 frotz
-Using “assume unchanged” bit
+Using “assume unchanged” bit
-
Many operations in git depend on your filesystem to have an
+
Many operations in git depend on your filesystem to have an
efficient lstat(2) implementation, so that st_mtime
information for working tree files can be cheaply checked to see
if the file contents have changed from the version recorded in
@@ -607,27 +655,27 @@ path does not mean git will check the contents of the file to
see if it has changed — it makes git to omit any checking and
assume it has not changed. When you make changes to working
tree files, you have to explicitly tell git about it by dropping
-"assume unchanged" bit, either before or after you modify them.
-
In order to set "assume unchanged" bit, use --assume-unchanged
-option. To unset, use --no-assume-unchanged .
-
The command looks at core.ignorestat configuration variable. When
+"assume unchanged" bit, either before or after you modify them.
+
In order to set "assume unchanged" bit, use --assume-unchanged
+option. To unset, use --no-assume-unchanged .
+
The command looks at core.ignorestat configuration variable. When
this is true, paths updated with git update-index paths… and
paths updated with other git commands that update both index and
-working tree (e.g. git-apply --index , git-checkout-index -u ,
-and git-read-tree -u ) are automatically marked as "assume
+working tree (e.g. git-apply --index , git-checkout-index -u ,
+and git-read-tree -u ) are automatically marked as "assume
unchanged". Note that "assume unchanged" bit is not set if
git update-index --refresh finds the working tree file matches
the index (use git update-index --really-refresh if you want
-to mark them as "assume unchanged").
+to mark them as "assume unchanged").
-Examples
+Examples
-
To update and refresh only the files already checked out:
+
To update and refresh only the files already checked out:
$ git checkout-index -n -f -a && git update-index --ignore-missing --refresh
-
+
On an inefficient filesystem with core.ignorestat set
@@ -648,7 +696,7 @@ $ git update-index --no-assume-unchanged foo.c (8)
$ git diff --name-only (9)
M foo.c
-
+
forces lstat(2) to set "assume unchanged" bits for paths that match index.
@@ -694,46 +742,46 @@ you can tell about the change after the fact.
now it checks with lstat(2) and finds it has been changed.
-
+
-
+
-Configuration
+Configuration
-
The command honors core.filemode configuration variable. If
+
The command honors core.filemode configuration variable. If
your repository is on an filesystem whose executable bits are
unreliable, this should be set to false (see git-config(1) ).
This causes the command to ignore differences in file modes recorded
in the index and the file mode on the filesystem if they differ only on
executable bit. On such an unfortunate filesystem, you may
-need to use git-update-index --chmod= .
-
Quite similarly, if core.symlinks configuration variable is set
+need to use git-update-index --chmod= .
+
Quite similarly, if core.symlinks configuration variable is set
to false (see git-config(1) ), symbolic links are checked out
as plain files, and this command does not modify a recorded file mode
-from symbolic link to regular file.
-
The command looks at core.ignorestat configuration variable. See
-Using "assume unchanged" bit section above.
+from symbolic link to regular file.
+
The command looks at core.ignorestat configuration variable. See
+Using "assume unchanged" bit section above.
-SEE ALSO
+SEE ALSO
-Author
+Author
-
Written by Linus Torvalds <torvalds@osdl.org>
+
Written by Linus Torvalds <torvalds@osdl.org>
-Documentation
+Documentation
-
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-update-index.txt b/git-update-index.txt
index 999e9a7c8..a91fd214d 100644
--- a/git-update-index.txt
+++ b/git-update-index.txt
@@ -31,7 +31,7 @@ cleared.
See also linkgit:git-add[1] for a more user-friendly way to do some of
the most common operations on the index.
-The way `git-update-index` handles files it is told about can be modified
+The way 'git-update-index' handles files it is told about can be modified
using the various options:
OPTIONS
@@ -53,7 +53,7 @@ OPTIONS
-q::
Quiet. If --refresh finds that the index needs an update, the
default behavior is to error out. This option makes
- `git-update-index` continue anyway.
+ 'git-update-index' continue anyway.
--ignore-submodules:
Do not try to update submodules. This option is only respected
@@ -61,7 +61,7 @@ OPTIONS
--unmerged::
If --refresh finds unmerged changes in the index, the default
- behavior is to error out. This option makes `git-update-index`
+ behavior is to error out. This option makes 'git-update-index'
continue anyway.
--ignore-missing::
@@ -91,7 +91,7 @@ OPTIONS
-g::
--again::
- Runs `git-update-index` itself on the paths whose index
+ Runs 'git-update-index' itself on the paths whose index
entries are different from those from the `HEAD` commit.
--unresolve::
@@ -109,7 +109,7 @@ OPTIONS
--replace::
By default, when a file `path` exists in the index,
- `git-update-index` refuses an attempt to add `path/file`.
+ 'git-update-index' refuses an attempt to add `path/file`.
Similarly if a file `path/file` exists, a file `path`
cannot be added. With --replace flag, existing entries
that conflicts with the entry being added are
@@ -145,7 +145,7 @@ up-to-date for mode/content changes. But what it *does* do is to
can refresh the index for a file that hasn't been changed but where
the stat entry is out of date.
-For example, you'd want to do this after doing a `git-read-tree`, to link
+For example, you'd want to do this after doing a 'git-read-tree', to link
up the stat index details with the proper files.
Using --cacheinfo or --info-only
@@ -186,13 +186,13 @@ back on 3-way merge.
. mode SP type SP sha1 TAB path
+
-The second format is to stuff `git-ls-tree` output
+The second format is to stuff 'git-ls-tree' output
into the index file.
. mode SP sha1 SP stage TAB path
+
This format is to put higher order stages into the
-index file and matches `git-ls-files --stage` output.
+index file and matches 'git-ls-files --stage' output.
To place a higher stage entry to the index, the path should
first be removed by feeding a mode=0 entry for the path, and
@@ -249,8 +249,8 @@ option. To unset, use `--no-assume-unchanged`.
The command looks at `core.ignorestat` configuration variable. When
this is true, paths updated with `git update-index paths...` and
paths updated with other git commands that update both index and
-working tree (e.g. `git-apply --index`, `git-checkout-index -u`,
-and `git-read-tree -u`) are automatically marked as "assume
+working tree (e.g. 'git-apply --index', 'git-checkout-index -u',
+and 'git-read-tree -u') are automatically marked as "assume
unchanged". Note that "assume unchanged" bit is *not* set if
`git update-index --refresh` finds the working tree file matches
the index (use `git update-index --really-refresh` if you want
@@ -303,7 +303,7 @@ unreliable, this should be set to 'false' (see linkgit:git-config[1]).
This causes the command to ignore differences in file modes recorded
in the index and the file mode on the filesystem if they differ only on
executable bit. On such an unfortunate filesystem, you may
-need to use `git-update-index --chmod=`.
+need to use 'git-update-index --chmod='.
Quite similarly, if `core.symlinks` configuration variable is set
to 'false' (see linkgit:git-config[1]), symbolic links are checked out
diff --git a/git-upload-archive.html b/git-upload-archive.html
index 3d35ea458..a1f0736e9 100644
--- a/git-upload-archive.html
+++ b/git-upload-archive.html
@@ -3,7 +3,7 @@
-
+
git-upload-archive(1)
@@ -272,19 +320,19 @@ git-upload-archive(1) Manual Page
SYNOPSIS
-
git upload-archive <directory>
+
git upload-archive <directory>
-DESCRIPTION
+DESCRIPTION
-
Invoked by git-archive --remote and sends a generated archive to the
-other end over the git protocol.
-
This command is usually not invoked directly by the end user. The UI
-for the protocol is on the git-archive side, and the program pair
-is meant to be used to get an archive from a remote repository.
+
Invoked by git-archive --remote and sends a generated archive to the
+other end over the git protocol.
+
This command is usually not invoked directly by the end user. The UI
+for the protocol is on the git-archive side, and the program pair
+is meant to be used to get an archive from a remote repository.
-OPTIONS
+OPTIONS
-
+
<directory>
@@ -293,23 +341,23 @@ is meant to be used to get an archive from a remote repository.
The repository to get a tar archive from.
-
+
-Author
+Author
-
Written by Franck Bui-Huu.
+
Written by Franck Bui-Huu.
-Documentation
+Documentation
-
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-upload-archive.txt b/git-upload-archive.txt
index 526e5bdd2..bbd761758 100644
--- a/git-upload-archive.txt
+++ b/git-upload-archive.txt
@@ -16,7 +16,7 @@ Invoked by 'git-archive --remote' and sends a generated archive to the
other end over the git protocol.
This command is usually not invoked directly by the end user. The UI
-for the protocol is on the `git-archive` side, and the program pair
+for the protocol is on the 'git-archive' side, and the program pair
is meant to be used to get an archive from a remote repository.
OPTIONS
diff --git a/git-upload-pack.html b/git-upload-pack.html
index 8cba080e0..b869781c9 100644
--- a/git-upload-pack.html
+++ b/git-upload-pack.html
@@ -3,7 +3,7 @@
-
+
git-upload-pack(1)
@@ -272,20 +320,20 @@ git-upload-pack(1) Manual Page
SYNOPSIS
-
git upload-pack [--strict] [--timeout=<n>] <directory>
+
git upload-pack [--strict] [--timeout=<n>] <directory>
-DESCRIPTION
+DESCRIPTION
-
Invoked by git-fetch-pack , learns what
-objects the other side is missing, and sends them after packing.
-
This command is usually not invoked directly by the end user.
-The UI for the protocol is on the git-fetch-pack side, and the
+
Invoked by git-fetch-pack , learns what
+objects the other side is missing, and sends them after packing.
+
This command is usually not invoked directly by the end user.
+The UI for the protocol is on the git-fetch-pack side, and the
program pair is meant to be used to pull updates from a remote
-repository. For push operations, see git-send-pack .
+repository. For push operations, see
git-send-pack .
-OPTIONS
+OPTIONS
-
+
--strict
@@ -310,23 +358,23 @@ repository. For push operations, see git-send-pack .
The repository to sync from.
-
+
-Author
+Author
-
Written by Linus Torvalds <torvalds@osdl.org>
+
Written by Linus Torvalds <torvalds@osdl.org>
-Documentation
+Documentation
-
Documentation by Junio C Hamano.
+
Documentation by Junio C Hamano.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-upload-pack.txt b/git-upload-pack.txt
index 52724d4c6..b8e49dce4 100644
--- a/git-upload-pack.txt
+++ b/git-upload-pack.txt
@@ -12,13 +12,13 @@ SYNOPSIS
DESCRIPTION
-----------
-Invoked by `git-fetch-pack`, learns what
+Invoked by 'git-fetch-pack', learns what
objects the other side is missing, and sends them after packing.
This command is usually not invoked directly by the end user.
-The UI for the protocol is on the `git-fetch-pack` side, and the
+The UI for the protocol is on the 'git-fetch-pack' side, and the
program pair is meant to be used to pull updates from a remote
-repository. For push operations, see `git-send-pack`.
+repository. For push operations, see 'git-send-pack'.
OPTIONS
diff --git a/git-var.html b/git-var.html
index e2eea383e..c563a9dd0 100644
--- a/git-var.html
+++ b/git-var.html
@@ -3,7 +3,7 @@
-
+
git-var(1)
@@ -272,15 +320,15 @@ git-var(1) Manual Page
SYNOPSIS
-
git var [ -l | <variable> ]
+
git var [ -l | <variable> ]
-DESCRIPTION
+DESCRIPTION
-
Prints a git logical variable.
+
Prints a git logical variable.
-OPTIONS
+OPTIONS
-
+
-l
@@ -289,12 +337,12 @@ git-var(1) Manual Page
Cause the logical variables to be listed. In addition, all the
variables of the git configuration file .git/config are listed
as well. (However, the configuration variables listing functionality
- is deprecated in favor of git-config -l .)
+ is deprecated in favor of git-config -l .)
-
+
-EXAMPLE
+EXAMPLE
@@ -302,9 +350,9 @@ git-var(1) Manual Page
Eric W. Biederman <ebiederm@lnxi.com> 1121223278 -0600
-VARIABLES
+VARIABLES
-
+
GIT_AUTHOR_IDENT
@@ -321,11 +369,11 @@ GIT_COMMITTER_IDENT
The person who put a piece of code into git.
-
+
-Diagnostics
+Diagnostics
-
+
You don't exist. Go away!
@@ -350,29 +398,29 @@ Your sysadmin must hate you!
The password(5) name field is longer than a giant static buffer.
-
+
-SEE ALSO
+SEE ALSO
-Author
+Author
-
Written by Eric Biederman <ebiederm@xmission.com>
+
Written by Eric Biederman <ebiederm@xmission.com>
-Documentation
+Documentation
-
Documentation by Eric Biederman and the git-list <git@vger.kernel.org>.
+
Documentation by Eric Biederman and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-var.txt b/git-var.txt
index 10d1e19cc..3647dd6c8 100644
--- a/git-var.txt
+++ b/git-var.txt
@@ -20,7 +20,7 @@ OPTIONS
Cause the logical variables to be listed. In addition, all the
variables of the git configuration file .git/config are listed
as well. (However, the configuration variables listing functionality
- is deprecated in favor of `git-config -l`.)
+ is deprecated in favor of 'git-config -l'.)
EXAMPLE
--------
diff --git a/git-verify-pack.html b/git-verify-pack.html
index 1cb36b722..df25b0fee 100644
--- a/git-verify-pack.html
+++ b/git-verify-pack.html
@@ -3,7 +3,7 @@
-
+
git-verify-pack(1)
@@ -272,17 +320,17 @@ git-verify-pack(1) Manual Page
SYNOPSIS
-
git verify-pack [-v] [--] <pack>.idx …
+
git verify-pack [-v] [--] <pack>.idx …
-DESCRIPTION
+DESCRIPTION
-
Reads given idx file for packed git archive created with the
-git-pack-objects command and verifies idx file and the
-corresponding pack file.
+
Reads given idx file for packed git archive created with the
+git-pack-objects command and verifies idx file and the
+corresponding pack file.
-OPTIONS
+OPTIONS
-
+
<pack>.idx …
@@ -308,37 +356,37 @@ corresponding pack file.
Do not interpret any more arguments as options.
-
+
-OUTPUT FORMAT
+
-
When specifying the -v option the format used is:
+
When specifying the -v option the format used is:
SHA1 type size size-in-pack-file offset-in-packfile
-
for objects that are not deltified in the pack, and
+
for objects that are not deltified in the pack, and
SHA1 type size size-in-packfile offset-in-packfile depth base-SHA1
-
for objects that are deltified.
+
for objects that are deltified.
-Author
+Author
-
Written by Junio C Hamano <junkio@cox.net>
+
Written by Junio C Hamano <junkio@cox.net>
-Documentation
+Documentation
-
Documentation by Junio C Hamano
+
Documentation by Junio C Hamano
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-verify-pack.txt b/git-verify-pack.txt
index 4d95c6c89..53a9ce308 100644
--- a/git-verify-pack.txt
+++ b/git-verify-pack.txt
@@ -14,7 +14,7 @@ SYNOPSIS
DESCRIPTION
-----------
Reads given idx file for packed git archive created with the
-`git-pack-objects` command and verifies idx file and the
+'git-pack-objects' command and verifies idx file and the
corresponding pack file.
OPTIONS
diff --git a/git-verify-tag.html b/git-verify-tag.html
index b0bcaed01..6b0e06fba 100644
--- a/git-verify-tag.html
+++ b/git-verify-tag.html
@@ -3,7 +3,7 @@
-
+
git-verify-tag(1)
@@ -272,15 +320,15 @@ git-verify-tag(1) Manual Page
SYNOPSIS
-DESCRIPTION
+DESCRIPTION
-
Validates the gpg signature created by git-tag .
+
Validates the gpg signature created by git-tag .
-OPTIONS
+OPTIONS
-
+
<tag>
@@ -289,23 +337,23 @@ git-verify-tag(1) Manual Page
SHA1 identifier of a git tag object.
-
+
-Author
+Author
-
Written by Jan Harkes <jaharkes@cs.cmu.edu> and Eric W. Biederman <ebiederm@xmission.com>
+
Written by Jan Harkes <jaharkes@cs.cmu.edu> and Eric W. Biederman <ebiederm@xmission.com>
-Documentation
+Documentation
-
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
+
Documentation by Junio C Hamano and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-verify-tag.txt b/git-verify-tag.txt
index de4a89a10..ba837df4b 100644
--- a/git-verify-tag.txt
+++ b/git-verify-tag.txt
@@ -11,7 +11,7 @@ SYNOPSIS
DESCRIPTION
-----------
-Validates the gpg signature created by `git-tag`.
+Validates the gpg signature created by 'git-tag'.
OPTIONS
-------
diff --git a/git-web--browse.html b/git-web--browse.html
index fe72da313..a1e2511e9 100644
--- a/git-web--browse.html
+++ b/git-web--browse.html
@@ -3,7 +3,7 @@
-
+
git-web--browse(1)
@@ -272,15 +320,15 @@ git-web--browse(1) Manual Page
SYNOPSIS
-
git web--browse [OPTIONS] URL/FILE …
+
git web--browse [OPTIONS] URL/FILE …
-DESCRIPTION
+DESCRIPTION
-
This script tries, as much as possible, to display the URLs and FILEs
+
This script tries, as much as possible, to display the URLs and FILEs
that are passed as arguments, as HTML pages in new tabs on an already
-opened web browser.
-
The following browsers (or commands) are currently supported:
-
+
The following browsers (or commands) are currently supported:
+
-
Custom commands may also be specified.
+
+
Custom commands may also be specified.
-OPTIONS
+OPTIONS
-
+
-b BROWSER
@@ -362,38 +410,38 @@ open (this is the default under Mac OS X GUI)
then its value specify the browser that should be used.
-
+
-CONFIGURATION VARIABLES
+CONFIGURATION VARIABLES
-
CONF.VAR (from -c option) and web.browser
-
The web browser can be specified using a configuration variable passed
+
CONF.VAR (from -c option) and web.browser
+
The web browser can be specified using a configuration variable passed
with the -c (or --config) command line option, or the web.browser
-configuration variable if the former is not used.
-
browser.<tool>.path
-
You can explicitly provide a full path to your preferred browser by
+configuration variable if the former is not used.
+
+
You can explicitly provide a full path to your preferred browser by
setting the configuration variable browser.<tool>.path . For example,
you can configure the absolute path to firefox by setting
-browser.firefox.path . Otherwise, git-web--browse assumes the tool
-is available in PATH.
-
browser.<tool>.cmd
-
When the browser, specified by options or configuration variables, is
+browser.firefox.path . Otherwise, git-web--browse assumes the tool
+is available in PATH.
+
+
When the browser, specified by options or configuration variables, is
not among the supported ones, then the corresponding
browser.<tool>.cmd configuration variable will be looked up. If this
-variable exists then git-web--browse will treat the specified tool
+variable exists then git-web--browse will treat the specified tool
as a custom command and will use a shell eval to run the command with
-the URLs passed as arguments.
+the URLs passed as arguments.
-Note about konqueror
+Note about konqueror
-
When konqueror is specified by the a command line option or a
+
When konqueror is specified by the a command line option or a
configuration variable, we launch kfmclient to try to open the HTML
-man page on an already opened konqueror in a new tab if possible.
-
For consistency, we also try such a trick if browser.konqueror.path is
+man page on an already opened konqueror in a new tab if possible.
+
For consistency, we also try such a trick if browser.konqueror.path is
set to something like A_PATH_TO/konqueror . That means we will try to
-launch A_PATH_TO/kfmclient instead.
-
If you really want to use konqueror , then you can use something like
-the following:
+launch
A_PATH_TO/kfmclient instead.
+
If you really want to use konqueror , then you can use something like
+the following:
[web]
@@ -402,33 +450,33 @@ the following:
[browser "konq"]
cmd = A_PATH_TO/konqueror
-
Note about git-config --global
-
Note that these configuration variables should probably be set using
-the --global flag, for example like this:
+
Note about git-config --global
+
Note that these configuration variables should probably be set using
+the --global flag, for example like this:
$ git config --global web.browser firefox
-
as they are probably more user specific than repository specific.
-See git-config(1) for more information about this.
+
as they are probably more user specific than repository specific.
+See git-config(1) for more information about this.
-Author
+Author
-
Written by Christian Couder <chriscool@tuxfamily.org> and the git-list
-<git@vger.kernel.org>, based on git-mergetool by Theodore Y. Ts'o.
+
Written by Christian Couder <chriscool@tuxfamily.org> and the git-list
+<git@vger.kernel.org>, based on git-mergetool by Theodore Y. Ts'o.
-Documentation
+Documentation
-
Documentation by Christian Couder <chriscool@tuxfamily.org> and the
-git-list <git@vger.kernel.org>.
+
Documentation by Christian Couder <chriscool@tuxfamily.org> and the
+git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-web--browse.txt b/git-web--browse.txt
index fefa6fd38..36afad8d4 100644
--- a/git-web--browse.txt
+++ b/git-web--browse.txt
@@ -61,7 +61,7 @@ browser..path
You can explicitly provide a full path to your preferred browser by
setting the configuration variable 'browser..path'. For example,
you can configure the absolute path to firefox by setting
-'browser.firefox.path'. Otherwise, `git-web--browse` assumes the tool
+'browser.firefox.path'. Otherwise, 'git-web--browse' assumes the tool
is available in PATH.
browser..cmd
@@ -70,7 +70,7 @@ browser..cmd
When the browser, specified by options or configuration variables, is
not among the supported ones, then the corresponding
'browser..cmd' configuration variable will be looked up. If this
-variable exists then `git-web--browse` will treat the specified tool
+variable exists then 'git-web--browse' will treat the specified tool
as a custom command and will use a shell eval to run the command with
the URLs passed as arguments.
@@ -112,7 +112,7 @@ See linkgit:git-config[1] for more information about this.
Author
------
Written by Christian Couder and the git-list
-, based on `git-mergetool` by Theodore Y. Ts'o.
+, based on 'git-mergetool' by Theodore Y. Ts'o.
Documentation
-------------
diff --git a/git-whatchanged.html b/git-whatchanged.html
index 47989e5eb..622487484 100644
--- a/git-whatchanged.html
+++ b/git-whatchanged.html
@@ -3,7 +3,7 @@
-
+
git-whatchanged(1)
@@ -272,19 +320,19 @@ git-whatchanged(1) Manual Page
SYNOPSIS
-
git whatchanged <option>…
+
git whatchanged <option>…
-DESCRIPTION
+DESCRIPTION
-
Shows commit logs and diff output each commit introduces. The
-command internally invokes git-rev-list piped to
-git-diff-tree , and takes command line options for both of
-these commands.
-
This manual page describes only the most frequently used options.
+
Shows commit logs and diff output each commit introduces. The
+command internally invokes git-rev-list piped to
+git-diff-tree , and takes command line options for both of
+these commands.
+
This manual page describes only the most frequently used options.
-OPTIONS
+OPTIONS
-
+
-p
@@ -330,8 +378,8 @@ these commands.
With this flag, show differences to that commit from all
of its parents.
-However, it is not very useful in general, although it
-is useful on a file-by-file basis.
+However, it is not very useful in general, although it
+is useful on a file-by-file basis.
--pretty[=<format> ]
@@ -343,8 +391,8 @@ these commands.
full , fuller , email , raw and format:<string> .
When omitted, the format defaults to medium .
-Note: you can specify the default pretty format in the repository
-configuration (see git-config(1) ).
+Note: you can specify the default pretty format in the repository
+configuration (see git-config(1) ).
--abbrev-commit
@@ -356,8 +404,8 @@ configuration (see git-config(1) ).
digits can be specified with "--abbrev=<n>" (which also modifies
diff output, if it is displayed).
-This should make "--pretty=oneline" a whole lot more readable for
-people using 80-column terminals.
+This should make "--pretty=oneline" a whole lot more readable for
+people using 80-column terminals.
--encoding[=<encoding>]
@@ -371,11 +419,11 @@ people using 80-column terminals.
defaults to UTF-8.
-
+
-PRETTY FORMATS
+
-
If the commit is a merge, and if the pretty-format
+
If the commit is a merge, and if the pretty-format
is not oneline , email or raw , an additional line is
inserted before the Author: line. This line begins with
"Merge: " and the sha1s of ancestral commits are printed,
@@ -383,9 +431,9 @@ separated by spaces. Note that the listed commits may not
necessarily be the list of the direct parent commits if you
have limited your view of history: for example, if you are
only interested in changes related to a certain directory or
-file.
-
Here are some additional details for each format:
-
+
Here are some additional details for each format:
+
-
This is designed to be as compact as possible.
+
This is designed to be as compact as possible.
@@ -418,7 +466,7 @@ Author: <author>
commit <sha1>
Author: <author>
-Date: <date>
+Date: <author date>
@@ -456,9 +504,9 @@ Commit: <committer>
commit <sha1>
Author: <author>
-AuthorDate: <date & time>
+AuthorDate: <author date>
Commit: <committer>
-CommitDate: <date & time>
+CommitDate: <committer date>
@@ -477,7 +525,7 @@ CommitDate: <date & time>
From <sha1> <date>
From: <author>
-Date: <date & time>
+Date: <author date>
Subject: [PATCH] <title line>
@@ -489,31 +537,31 @@ Subject: [PATCH] <title line>
raw
-
The raw format shows the entire commit exactly as
+
The raw format shows the entire commit exactly as
stored in the commit object. Notably, the SHA1s are
displayed in full, regardless of whether --abbrev or
--no-abbrev are used, and parents information show the
true parent commits, without taking grafts nor history
-simplification into account.
+simplification into account.
format:
-The format: format allows you to specify which information
+
The format: format allows you to specify which information
you want to show. It works a little bit like printf format,
with the notable exception that you get a newline with %n
-instead of \n .
-
E.g, format:"The author of %h was %an, %ar%nThe title was >>%s<<%n"
-would show something like this:
+instead of
\n .
+E.g, format:"The author of %h was %an, %ar%nThe title was >>%s<<%n"
+would show something like this:
The author of fe6e0ee was Junio C Hamano, 23 hours ago
The title was >>t4119: test autocomputing -p<n> for traditional diff input.<<
-The placeholders are:
-
tformat:
-The tformat: format works exactly like format: , except that it
+
The tformat: format works exactly like format: , except that it
provides "terminator" semantics instead of "separator" semantics. In
other words, each commit has the message terminator character (usually a
newline) appended, rather than a separator placed between entries.
This means that the final entry of a single-line format will be properly
terminated with a new line, just as the "oneline" format does.
-For example:
+For example:
$ git log -2 --pretty=format:%h 4da45bef \
@@ -690,11 +738,11 @@ $ git log -2 --pretty=tformat:%h 4da45bef \
7134973
-
+
-
Examples
+
Examples
-
+
git whatchanged -p v2.6.12.. include/scsi drivers/scsi
@@ -714,24 +762,24 @@ git whatchanged --since="2 weeks ago" -- gitk
gitk
-
+
-
Author
+
Author
-
Written by Linus Torvalds <torvalds@osdl.org> and
-Junio C Hamano <junkio@cox.net>
+
Written by Linus Torvalds <torvalds@osdl.org> and
+Junio C Hamano <junkio@cox.net>
-
Documentation
+
Documentation
-
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
-
GIT
+
GIT
-
Part of the git(1) suite
+
diff --git a/git-whatchanged.txt b/git-whatchanged.txt
index 3b0ea2c59..d7fad1532 100644
--- a/git-whatchanged.txt
+++ b/git-whatchanged.txt
@@ -13,8 +13,8 @@ SYNOPSIS
DESCRIPTION
-----------
Shows commit logs and diff output each commit introduces. The
-command internally invokes `git-rev-list` piped to
-`git-diff-tree`, and takes command line options for both of
+command internally invokes 'git-rev-list' piped to
+'git-diff-tree', and takes command line options for both of
these commands.
This manual page describes only the most frequently used options.
diff --git a/git-write-tree.html b/git-write-tree.html
index 55a99e91d..76c3a6305 100644
--- a/git-write-tree.html
+++ b/git-write-tree.html
@@ -3,7 +3,7 @@
-
+
git-write-tree(1)
@@ -272,27 +320,27 @@ git-write-tree(1) Manual Page
SYNOPSIS
-
git write-tree [--missing-ok] [--prefix=<prefix>/]
+
git write-tree [--missing-ok] [--prefix=<prefix>/]
-DESCRIPTION
+DESCRIPTION
-
Creates a tree object using the current index.
-
The index must be in a fully merged state.
-
Conceptually, git-write-tree sync()s the current index contents
+
Creates a tree object using the current index.
+
The index must be in a fully merged state.
+
Conceptually, git-write-tree sync()s the current index contents
into a set of tree files.
In order to have that match what is actually in your directory right
-now, you need to have done a git-update-index phase before you did the
-git-write-tree .
+now, you need to have done a
git-update-index phase before you did the
+
git-write-tree .
-OPTIONS
+OPTIONS
-
+
--missing-ok
- Normally git-write-tree ensures that the objects referenced by the
+ Normally git-write-tree ensures that the objects referenced by the
directory exist in the object database. This option disables this
check.
@@ -307,23 +355,23 @@ now, you need to have done a git-update-index phase before you did the
for a subproject that is in the named subdirectory.
-
+
-Author
+Author
-
Written by Linus Torvalds <torvalds@osdl.org>
+
Written by Linus Torvalds <torvalds@osdl.org>
-Documentation
+Documentation
-
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
+
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git-write-tree.txt b/git-write-tree.txt
index 19d979bcc..26d3850e7 100644
--- a/git-write-tree.txt
+++ b/git-write-tree.txt
@@ -16,17 +16,17 @@ Creates a tree object using the current index.
The index must be in a fully merged state.
-Conceptually, `git-write-tree` sync()s the current index contents
+Conceptually, 'git-write-tree' sync()s the current index contents
into a set of tree files.
In order to have that match what is actually in your directory right
-now, you need to have done a `git-update-index` phase before you did the
-`git-write-tree`.
+now, you need to have done a 'git-update-index' phase before you did the
+'git-write-tree'.
OPTIONS
-------
--missing-ok::
- Normally `git-write-tree` ensures that the objects referenced by the
+ Normally 'git-write-tree' ensures that the objects referenced by the
directory exist in the object database. This option disables this
check.
diff --git a/git.html b/git.html
index 298fe7a07..97a27e19b 100644
--- a/git.html
+++ b/git.html
@@ -3,7 +3,7 @@
-
+
git(1)
@@ -278,26 +326,26 @@ git(1) Manual Page
[--bare] [--git-dir=GIT_DIR] [--work-tree=GIT_WORK_TREE]
[--help] COMMAND [ARGS]
-DESCRIPTION
+DESCRIPTION
-
Git is a fast, scalable, distributed revision control system with an
+
Git is a fast, scalable, distributed revision control system with an
unusually rich command set that provides both high-level operations
-and full access to internals.
-
See gittutorial(7) to get started, then see
+and full access to internals.
+
See gittutorial(7) to get started, then see
Everyday Git for a useful minimum set of commands, and
"man git-commandname" for documentation of each command. CVS users may
also want to read gitcvs-migration(7) . See
the Git User's Manual for a more in-depth
-introduction.
-
The COMMAND is either a name of a Git command (see below) or an alias
-as defined in the configuration file (see git-config(1) ).
-
Formatted and hyperlinked version of the latest git
+introduction.
+
The COMMAND is either a name of a Git command (see below) or an alias
+as defined in the configuration file (see git-config(1) ).
+
Formatted and hyperlinked version of the latest git
documentation can be viewed at
-http://www.kernel.org/pub/software/scm/git/docs/ .
+
http://www.kernel.org/pub/software/scm/git/docs/ .
-OPTIONS
+OPTIONS
-
+
--version
@@ -316,10 +364,10 @@ documentation can be viewed at
available commands are printed. If a git command is named this
option will bring up the manual page for that command.
-Other options are available to control how the manual page is
+
Other options are available to control how the manual page is
displayed. See git-help(1) for more information,
-because git --help … is converted internally into git
-help … .
+because
git --help … is converted internally into
git
+help … .
--exec-path
@@ -328,7 +376,7 @@ help ….
Path to wherever your core git programs are installed.
This can also be controlled by setting the GIT_EXEC_PATH
- environment variable. If no path is given git will print
+ environment variable. If no path is given, git will print
the current setting and then exit.
@@ -389,31 +437,31 @@ help ….
directory.
-
+
-FURTHER DOCUMENTATION
+FURTHER DOCUMENTATION
-GIT COMMANDS
+GIT COMMANDS
-
We divide git into high level ("porcelain") commands and low level
-("plumbing") commands.
+
We divide git into high level ("porcelain") commands and low level
+("plumbing") commands.
-High-level commands (porcelain)
+High-level commands (porcelain)
-
We separate the porcelain commands into the main commands and some
-ancillary user utilities.
-
Main porcelain commands
-
+We separate the porcelain commands into the main commands and some
+ancillary user utilities.
+Main porcelain commands
+
git-add(1)
@@ -651,7 +699,7 @@ ancillary user utilities.
- Summarize git log output.
+ Summarize git-log output.
@@ -702,10 +750,10 @@ ancillary user utilities.
The git repository browser.
-
-
Ancillary Commands
-
Manipulators:
-
+
+Ancillary Commands
+
+
git-config(1)
@@ -810,9 +858,9 @@ ancillary user utilities.
(deprecated) Get and set repository or global options.
-
-
Interrogators:
-
+
+
+
git-annotate(1)
@@ -925,11 +973,11 @@ ancillary user utilities.
Show logs with difference each commit introduces.
-
-
Interacting with Others
-
These commands are to interact with foreign SCM and with other
-people via patch over e-mail.
-
+
+Interacting with Others
+These commands are to interact with foreign SCM and with other
+people via patch over e-mail.
+
git-archimport(1)
@@ -1002,28 +1050,28 @@ people via patch over e-mail.
Bidirectional operation between a single Subversion branch and git.
-
+
-Low-level commands (plumbing)
+Low-level commands (plumbing)
-
Although git includes its
+
Although git includes its
own porcelain layer, its low-level commands are sufficient to support
development of alternative porcelains. Developers of such porcelains
might start by reading about git-update-index(1) and
-git-read-tree(1) .
-
The interface (input, output, set of options and the semantics)
+git-read-tree(1) .
+
The interface (input, output, set of options and the semantics)
to these low-level commands are meant to be a lot more stable
than Porcelain level commands, because these commands are
primarily for scripted use. The interface to Porcelain commands
on the other hand are subject to change in order to improve the
-end user experience.
-
The following description divides
+end user experience.
+
The following description divides
the low-level commands into commands that manipulate objects (in
the repository, index, and working tree), commands that interrogate and
compare objects, and commands that move objects and references between
-repositories.
-
Manipulation commands
-
+repositories.
+
Manipulation commands
+
git-apply(1)
@@ -1160,9 +1208,9 @@ repositories.
Create a tree object from the current index.
-
-
Interrogation commands
-
+
+
Interrogation commands
+
git-cat-file(1)
@@ -1307,11 +1355,11 @@ repositories.
Validate packed git archive files.
-
-
In general, the interrogate commands do not touch the files in
-the working tree.
-
Synching repositories
-
+
+
In general, the interrogate commands do not touch the files in
+the working tree.
+
Synching repositories
+
git-daemon(1)
@@ -1344,10 +1392,10 @@ the working tree.
Update auxiliary info file to help dumb servers.
-
-
The following are helper programs used by the above; end users
-typically do not use them directly.
-
+
+
The following are helper programs used by the above; end users
+typically do not use them directly.
+
git-http-fetch(1)
@@ -1404,11 +1452,11 @@ typically do not use them directly.
Send objects packed back to git-fetch-pack.
-
-
Internal helper commands
-
These are internal helper commands used by other commands; end
-users typically do not use them directly.
-
+
+
Internal helper commands
+
These are internal helper commands used by other commands; end
+users typically do not use them directly.
+
git-check-attr(1)
@@ -1489,14 +1537,14 @@ users typically do not use them directly.
Filter out empty lines.
-
+
-Configuration Mechanism
+Configuration Mechanism
-
Starting from 0.99.9 (actually mid 0.99.8.GIT), .git/config file
+
Starting from 0.99.9 (actually mid 0.99.8.GIT), .git/config file
is used to hold per-repository configuration options. It is a
simple text file modeled after .ini format familiar to some
-people. Here is an example:
+people. Here is an example:
#
@@ -1514,12 +1562,12 @@ people. Here is an example:
email = "junkio@twinsun.com"
-
Various commands read from the configuration file and adjust
-their operation accordingly.
+
Various commands read from the configuration file and adjust
+their operation accordingly.
-Identifier Terminology
+Identifier Terminology
-
+
<object>
@@ -1592,13 +1640,13 @@ their operation accordingly.
root of the tree structure GIT_INDEX_FILE describes.
-
+
-Symbolic Identifiers
+Symbolic Identifiers
-
Any git command accepting any <object> can also use the following
-symbolic notation:
-
+Any git command accepting any <object> can also use the following
+symbolic notation:
+
HEAD
@@ -1626,29 +1674,29 @@ HEAD
(i.e. the contents of $GIT_DIR/refs/heads/<head> ).
-
-
For a more complete list of ways to spell object names, see
-"SPECIFYING REVISIONS" section in git-rev-parse(1) .
+
+For a more complete list of ways to spell object names, see
+"SPECIFYING REVISIONS" section in git-rev-parse(1) .
-File/Directory Structure
+File/Directory Structure
-
Please see the gitrepository-layout(5) document.
-
Read githooks(5) for more details about each hook.
-
Higher level SCMs may provide and manage additional information in the
-$GIT_DIR .
+
+
+
Higher level SCMs may provide and manage additional information in the
+$GIT_DIR .
-Terminology
+Terminology
-
Please see gitglossary(7) .
+
-Environment Variables
+Environment Variables
-
Various git commands use the following environment variables:
-
The git Repository
-
These environment variables apply to all core git commands. Nb: it
+
Various git commands use the following environment variables:
+
The git Repository
+
These environment variables apply to all core git commands. Nb: it
is worth noting that they may be used/overridden by SCMS sitting above
-git so take care if using Cogito etc.
-
+git so take care if using Cogito etc.
+
GIT_INDEX_FILE
@@ -1704,9 +1752,9 @@ git so take care if using Cogito etc.
option and the core.worktree configuration variable.
-
-
git Commits
-
+
+
git Commits
+
GIT_AUTHOR_NAME
@@ -1733,9 +1781,9 @@ git so take care if using Cogito etc.
see git-commit-tree(1)
-
-
git Diffs
-
+
+
git Diffs
+
GIT_DIFF_OPTS
@@ -1761,7 +1809,7 @@ git so take care if using Cogito etc.
path old-file old-hex old-mode new-file new-hex new-mode
-
where:
+
@@ -1789,17 +1837,17 @@ are the octal representation of the file modes.
-
The file parameters can point at the user's working file
+
The file parameters can point at the user's working file
(e.g. new-file in "git-diff-files"), /dev/null (e.g. old-file
when a new file is added), or a temporary file (e.g. old-file in the
index). GIT_EXTERNAL_DIFF should not worry about unlinking the
-temporary file --- it is removed when GIT_EXTERNAL_DIFF exits.
-
For a path that is unmerged, GIT_EXTERNAL_DIFF is called with 1
-parameter, <path>.
+temporary file --- it is removed when
GIT_EXTERNAL_DIFF exits.
+
For a path that is unmerged, GIT_EXTERNAL_DIFF is called with 1
+parameter, <path>.
-
-
other
-
+
+other
+
GIT_MERGE_VERBOSITY
@@ -1825,19 +1873,19 @@ parameter, <path>.
- If this environment variable is set then git-fetch
- and git-push will use this command instead
- of ssh when they need to connect to a remote system.
+ If this environment variable is set then git-fetch
+ and git-push will use this command instead
+ of ssh when they need to connect to a remote system.
The $GIT_SSH command will be given exactly two arguments:
the username@host (or just host ) from the URL and the
shell command to execute on that remote system.
-To pass options to the program that you want to list in GIT_SSH
+
To pass options to the program that you want to list in GIT_SSH
you will need to wrap the program and options into a shell script,
-then set GIT_SSH to refer to the shell script.
-
Usually it is easier to configure any desired options through your
+then set GIT_SSH to refer to the shell script.
+Usually it is easier to configure any desired options through your
personal .ssh/config file. Please consult your ssh documentation
-for further details.
+for further details.
GIT_FLUSH
@@ -1845,8 +1893,8 @@ for further details.
If this environment variable is set to "1", then commands such
- as git-blame (in incremental mode), git-rev-list , git-log ,
- and git-whatchanged will force a flush of the output stream
+ as git-blame (in incremental mode), git-rev-list , git-log ,
+ and git-whatchanged will force a flush of the output stream
after each commit-oriented record have been flushed. If this
variable is set to "0", the output of these commands will be done
using completely buffered I/O. If this environment variable is
@@ -1873,55 +1921,55 @@ for further details.
into it.
-
+
-Discussion
+Discussion
-
More detail on the following is available from the
+
+
A git project normally consists of a working directory with a ".git"
subdirectory at the top level. The .git directory contains, among other
things, a compressed object database representing the complete history
of the project, an "index" file which links that history to the current
contents of the working tree, and named pointers into that history such
-as tags and branch heads.
-
The object database contains objects of three main types: blobs, which
+as tags and branch heads.
+
The object database contains objects of three main types: blobs, which
hold file data; trees, which point to blobs and other trees to build up
directory hierarchies; and commits, which each reference a single tree
-and some number of parent commits.
-
The commit, equivalent to what other systems call a "changeset" or
+and some number of parent commits.
+
The commit, equivalent to what other systems call a "changeset" or
"version", represents a step in the project's history, and each parent
represents an immediately preceding step. Commits with more than one
-parent represent merges of independent lines of development.
-
All objects are named by the SHA1 hash of their contents, normally
+parent represent merges of independent lines of development.
+
All objects are named by the SHA1 hash of their contents, normally
written as a string of 40 hex digits. Such names are globally unique.
The entire history leading up to a commit can be vouched for by signing
just that commit. A fourth object type, the tag, is provided for this
-purpose.
-
When first created, objects are stored in individual files, but for
-efficiency may later be compressed together into "pack files".
-
Named pointers called refs mark interesting points in history. A ref
+purpose.
+
When first created, objects are stored in individual files, but for
+efficiency may later be compressed together into "pack files".
+
Named pointers called refs mark interesting points in history. A ref
may contain the SHA1 name of an object or the name of another ref. Refs
with names beginning ref/head/ contain the SHA1 name of the most
recent commit (or "head") of a branch under development. SHA1 names of
tags of interest are stored under ref/tags/ . A special ref named
-HEAD contains the name of the currently checked-out branch.
-
The index file is initialized with a list of all paths and, for each
+HEAD contains the name of the currently checked-out branch.
+
The index file is initialized with a list of all paths and, for each
path, a blob object and a set of attributes. The blob object represents
the contents of the file as of the head of the current branch. The
attributes (last modified time, size, etc.) are taken from the
corresponding file in the working tree. Subsequent changes to the
working tree can be found by comparing these attributes. The index may
be updated with new content, and new commits may be created from the
-content stored in the index.
-
The index is also capable of storing multiple entries (called "stages")
+content stored in the index.
+
The index is also capable of storing multiple entries (called "stages")
for a given pathname. These stages are used to hold the various
-unmerged version of a file when a merge is in progress.
+unmerged version of a file when a merge is in progress.
-Authors
+Authors
-
+
git's founding father is Linus Torvalds <torvalds@osdl.org>.
@@ -1942,28 +1990,28 @@ The git potty was written by Andreas Ericsson <ae@op5.se>.
General upbringing is handled by the git-list <git@vger.kernel.org>.
-
+
-Documentation
+Documentation
-
The documentation for git suite was started by David Greaves
+
The documentation for git suite was started by David Greaves
<david@dgreaves.com>, and later enhanced greatly by the
-contributors on the git-list <git@vger.kernel.org>.
+contributors on the git-list <git@vger.kernel.org>.
-SEE ALSO
+SEE ALSO
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/git.txt b/git.txt
index 22702c260..adc027ce4 100644
--- a/git.txt
+++ b/git.txt
@@ -43,9 +43,10 @@ unreleased) version of git, that is available from 'master'
branch of the `git.git` repository.
Documentation for older releases are available here:
-* link:v1.5.6.1/git.html[documentation for release 1.5.6.1]
+* link:v1.5.6.2/git.html[documentation for release 1.5.6.2]
* release notes for
+ link:RelNotes-1.5.6.2.txt[1.5.6.2].
link:RelNotes-1.5.6.1.txt[1.5.6.1].
link:RelNotes-1.5.6.txt[1.5.6].
@@ -135,13 +136,13 @@ OPTIONS
+
Other options are available to control how the manual page is
displayed. See linkgit:git-help[1] for more information,
-because 'git --help ...' is converted internally into 'git
-help ...'.
+because `git --help ...` is converted internally into `git
+help ...`.
--exec-path::
Path to wherever your core git programs are installed.
This can also be controlled by setting the GIT_EXEC_PATH
- environment variable. If no path is given 'git' will print
+ environment variable. If no path is given, 'git' will print
the current setting and then exit.
-p::
@@ -483,9 +484,9 @@ other
a pager.
'GIT_SSH'::
- If this environment variable is set then `git-fetch`
- and `git-push` will use this command instead
- of `ssh` when they need to connect to a remote system.
+ If this environment variable is set then 'git-fetch'
+ and 'git-push' will use this command instead
+ of 'ssh' when they need to connect to a remote system.
The '$GIT_SSH' command will be given exactly two arguments:
the 'username@host' (or just 'host') from the URL and the
shell command to execute on that remote system.
@@ -500,8 +501,8 @@ for further details.
'GIT_FLUSH'::
If this environment variable is set to "1", then commands such
- as `git-blame` (in incremental mode), `git-rev-list`, `git-log`,
- and `git-whatchanged` will force a flush of the output stream
+ as 'git-blame' (in incremental mode), 'git-rev-list', 'git-log',
+ and 'git-whatchanged' will force a flush of the output stream
after each commit-oriented record have been flushed. If this
variable is set to "0", the output of these commands will be done
using completely buffered I/O. If this environment variable is
diff --git a/gitattributes.html b/gitattributes.html
index 49663c8a7..67924d0b9 100644
--- a/gitattributes.html
+++ b/gitattributes.html
@@ -3,7 +3,7 @@
-
+
gitattributes(5)
@@ -272,23 +320,23 @@ gitattributes(5) Manual Page
SYNOPSIS
-
$GIT_DIR/info/attributes, gitattributes
+
$GIT_DIR/info/attributes, gitattributes
-DESCRIPTION
+DESCRIPTION
-
A gitattributes file is a simple text file that gives
-attributes to pathnames.
-
Each line in gitattributes file is of form:
+
A gitattributes file is a simple text file that gives
+attributes to pathnames.
+
Each line in gitattributes file is of form:
-
That is, a glob pattern followed by an attributes list,
+
That is, a glob pattern followed by an attributes list,
separated by whitespaces. When the glob pattern matches the
path in question, the attributes listed on the line are given to
-the path.
-
Each attribute can be in one of these states for a given path:
-
+the path.
+
Each attribute can be in one of these states for a given path:
+
Set
@@ -330,40 +378,40 @@ Unspecified
attribute for the path is said to be Unspecified.
-
-
When more than one glob pattern matches the path, a later line
+
+
When more than one glob pattern matches the path, a later line
overrides an earlier line. This overriding is done per
-attribute.
-
When deciding what attributes are assigned to a path, git
+attribute.
+
When deciding what attributes are assigned to a path, git
consults $GIT_DIR/info/attributes file (which has the highest
precedence), .gitattributes file in the same directory as the
path in question, and its parent directories (the further the
directory that contains .gitattributes is from the path in
-question, the lower its precedence).
-
If you wish to affect only a single repository (i.e., to assign
+question, the lower its precedence).
+
If you wish to affect only a single repository (i.e., to assign
attributes to files that are particular to one user's workflow), then
attributes should be placed in the $GIT_DIR/info/attributes file.
Attributes which should be version-controlled and distributed to other
repositories (i.e., attributes of interest to all users) should go into
-.gitattributes files.
-
Sometimes you would need to override an setting of an attribute
+.gitattributes files.
+
Sometimes you would need to override an setting of an attribute
for a path to unspecified state. This can be done by listing
-the name of the attribute prefixed with an exclamation point ! .
+the name of the attribute prefixed with an exclamation point
! .
-EFFECTS
+EFFECTS
-
Certain operations by git can be influenced by assigning
+
Certain operations by git can be influenced by assigning
particular attributes to a path. Currently, the following
-operations are attributes-aware.
-
Checking-out and checking-in
-
These attributes affect how the contents stored in the
+operations are attributes-aware.
+
Checking-out and checking-in
+
These attributes affect how the contents stored in the
repository are copied to the working tree files when commands
-such as git-checkout and git-merge run. They also affect how
+such as git-checkout and git-merge run. They also affect how
git stores the contents you prepare in the working tree in the
-repository upon git-add and git-commit .
-
crlf
-
This attribute controls the line-ending convention.
-
+repository upon git-add and git-commit .
+
crlf
+
This attribute controls the line-ending convention.
+
Set
@@ -405,36 +453,36 @@ Set to string value "input"
input for the path.
-
-
Any other value set to crlf attribute is ignored and git acts
-as if the attribute is left unspecified.
-
The core.autocrlf conversion
-
If the configuration variable core.autocrlf is false, no
-conversion is done.
-
When core.autocrlf is true, it means that the platform wants
+
+
Any other value set to crlf attribute is ignored and git acts
+as if the attribute is left unspecified.
+
The core.autocrlf conversion
+
If the configuration variable core.autocrlf is false, no
+conversion is done.
+
When core.autocrlf is true, it means that the platform wants
CRLF line endings for files in the working tree, and you want to
convert them back to the normal LF line endings when checking
-in to the repository.
-
When core.autocrlf is set to "input", line endings are
+in to the repository.
+
When core.autocrlf is set to "input", line endings are
converted to LF upon checkin, but there is no conversion done
-upon checkout.
-
If core.safecrlf is set to "true" or "warn", git verifies if
+upon checkout.
+
If core.safecrlf is set to "true" or "warn", git verifies if
the conversion is reversible for the current setting of
core.autocrlf . For "true", git rejects irreversible
conversions; for "warn", git only prints a warning but accepts
an irreversible conversion. The safety triggers to prevent such
a conversion done to the files in the work tree, but there are a
-few exceptions. Even though…
-
+few exceptions. Even though…
+
-git-add itself does not touch the files in the work tree, the
+git-add itself does not touch the files in the work tree, the
next checkout would, so the safety triggers;
-git-apply to update a text file with a patch does touch the files
+git-apply to update a text file with a patch does touch the files
in the work tree, but the operation is about text files and CRLF
conversion is about fixing the line ending inconsistencies, so the
safety does not trigger;
@@ -442,52 +490,52 @@ few exceptions. Even though…
-git-diff itself does not touch the files in the work tree, it is
- often run to inspect the changes you intend to next git-add . To
+git-diff itself does not touch the files in the work tree, it is
+ often run to inspect the changes you intend to next git-add . To
catch potential problems early, safety triggers.
-
-
ident
-
When the attribute ident is set to a path, git replaces
+
+
ident
+
When the attribute ident is set to a path, git replaces
$Id$ in the blob object with $Id: , followed by
40-character hexadecimal blob object name, followed by a dollar
sign $ upon checkout. Any byte sequence that begins with
$Id: and ends with $ in the worktree file is replaced
-with $Id$ upon check-in.
-
filter
-
A filter attribute can be set to a string value that names a
-filter driver specified in the configuration.
-
A filter driver consists of a clean command and a smudge
+with $Id$ upon check-in.
+
filter
+
A filter attribute can be set to a string value that names a
+filter driver specified in the configuration.
+
A filter driver consists of a clean command and a smudge
command, either of which can be left unspecified. Upon
checkout, when the smudge command is specified, the command is
fed the blob object from its standard input, and its standard
output is used to update the worktree file. Similarly, the
clean command is used to convert the contents of worktree file
-upon checkin.
-
A missing filter driver definition in the config is not an error
-but makes the filter a no-op passthru.
-
The content filtering is done to massage the content into a
+upon checkin.
+
A missing filter driver definition in the config is not an error
+but makes the filter a no-op passthru.
+
The content filtering is done to massage the content into a
shape that is more convenient for the platform, filesystem, and
the user to use. The key phrase here is "more convenient" and not
"turning something unusable into usable". In other words, the
intent is that if someone unsets the filter driver definition,
or does not have the appropriate filter program, the project
-should still be usable.
-
Interaction between checkin/checkout attributes
-
In the check-in codepath, the worktree file is first converted
+should still be usable.
+
Interaction between checkin/checkout attributes
+
In the check-in codepath, the worktree file is first converted
with filter driver (if specified and corresponding driver
defined), then the result is processed with ident (if
specified), and then finally with crlf (again, if specified
-and applicable).
-
In the check-out codepath, the blob content is first converted
-with crlf , and then ident and fed to filter .
-
Generating diff text
-
The attribute diff affects if git-diff generates textual
+and applicable).
+
In the check-out codepath, the blob content is first converted
+with crlf , and then ident and fed to filter .
+
Generating diff text
+
The attribute diff affects if git-diff generates textual
patch for the path or just says Binary files differ . It also
can affect what line is shown on the hunk header @@ -k,l +n,m @@
-line.
-
+line.
+
Set
@@ -530,72 +578,72 @@ String
selection.
-
-
Defining a custom diff driver
-
The definition of a diff driver is done in gitconfig , not
+
+
Defining a custom diff driver
+
The definition of a diff driver is done in gitconfig , not
gitattributes file, so strictly speaking this manual page is a
-wrong place to talk about it. However…
-
To define a custom diff driver jcdiff , add a section to your
-$GIT_DIR/config file (or $HOME/.gitconfig file) like this:
+wrong place to talk about it. However…
+
To define a custom diff driver jcdiff , add a section to your
+$GIT_DIR/config file (or $HOME/.gitconfig file) like this:
[diff "jcdiff"]
command = j-c-diff
-
When git needs to show you a diff for the path with diff
+
When git needs to show you a diff for the path with diff
attribute set to jcdiff , it calls the command you specified
with the above configuration, i.e. j-c-diff , with 7
parameters, just like GIT_EXTERNAL_DIFF program is called.
-See git(1) for details.
-
Defining a custom hunk-header
-
Each group of changes (called "hunk") in the textual diff output
-is prefixed with a line of the form:
+See
git(1) for details.
+
+
Each group of changes (called "hunk") in the textual diff output
+is prefixed with a line of the form:
-
The text is called hunk header , and by default a line that
+
The text is called hunk header , and by default a line that
begins with an alphabet, an underscore or a dollar sign is used,
-which matches what GNU diff -p output uses. This default
+which matches what GNU diff -p output uses. This default
selection however is not suited for some contents, and you can
-use customized pattern to make a selection.
-
First in .gitattributes, you would assign the diff attribute
-for paths.
+use customized pattern to make a selection.
+
First in .gitattributes, you would assign the diff attribute
+for paths.
-
Then, you would define "diff.tex.funcname" configuration to
+
Then, you would define "diff.tex.funcname" configuration to
specify a regular expression that matches a line that you would
-want to appear as the hunk header, like this:
+want to appear as the hunk header, like this:
[diff "tex"]
funcname = "^\\(\\\\\\(sub\\)*section{.*\\)$"
-
Note. A single level of backslashes are eaten by the
+
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 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
+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
configuration file (you still need to enable this with the
attribute mechanism, via .gitattributes ). Another built-in
pattern is defined for java that defines a pattern suitable
-for program text in Java language.
-
Performing a three-way merge
-
The attribute merge affects how three versions of a file is
+for program text in Java language.
+
+
The attribute merge affects how three versions of a file is
merged when a file-level merge is necessary during git merge ,
-and other programs such as git revert and git cherry-pick .
-
+and other programs such as git revert and git cherry-pick .
+
Set
Built-in 3-way merge driver is used to merge the
- contents in a way similar to merge command of RCS
+ contents in a way similar to merge command of RCS
suite. This is suitable for ordinary text files.
@@ -634,11 +682,11 @@ String
requested with "binary".
-
-
Built-in merge drivers
-
There are a few built-in low-level merge drivers defined that
-can be asked for via the merge attribute.
-
+
+
Built-in merge drivers
+
There are a few built-in low-level merge drivers defined that
+can be asked for via the merge attribute.
+
text
@@ -675,13 +723,13 @@ union
understand the implications.
-
-
Defining a custom merge driver
-
The definition of a merge driver is done in the .git/config
+
+
Defining a custom merge driver
+
The definition of a merge driver is done in the .git/config
file, not in the gitattributes file, so strictly speaking this
-manual page is a wrong place to talk about it. However…
-
To define a custom merge driver filfre , add a section to your
-$GIT_DIR/config file (or $HOME/.gitconfig file) like this:
+manual page is a wrong place to talk about it. However…
+
To define a custom merge driver filfre , add a section to your
+$GIT_DIR/config file (or $HOME/.gitconfig file) like this:
[merge "filfre"]
@@ -689,30 +737,30 @@ manual page is a wrong place to talk about it. However…
driver = filfre %O %A %B
recursive = binary
-
The merge.*.name variable gives the driver a human-readable
-name.
-
The merge.*.driver variable's value is used to construct a
+
The merge.*.name variable gives the driver a human-readable
+name.
+
The merge.*.driver variable's value is used to construct a
command to run to merge ancestor's version (%O ), current
version (%A ) and the other branches' version (%B ). These
three tokens are replaced with the names of temporary files that
hold the contents of these versions when the command line is
-built.
-
The merge driver is expected to leave the result of the merge in
+built.
+
The merge driver is expected to leave the result of the merge in
the file named with %A by overwriting it, and exit with zero
status if it managed to merge them cleanly, or non-zero if there
-were conflicts.
-
The merge.*.recursive variable specifies what other merge
+were conflicts.
+
The merge.*.recursive variable specifies what other merge
driver to use when the merge driver is called for an internal
merge between common ancestors, when there are more than one.
When left unspecified, the driver itself is used for both
-internal merge and the final merge.
-
Checking whitespace errors
-
whitespace
-
The core.whitespace configuration variable allows you to define what
-diff and apply should consider whitespace errors for all paths in
+internal merge and the final merge.
+
Checking whitespace errors
+
whitespace
+
The core.whitespace configuration variable allows you to define what
+diff and apply should consider whitespace errors for all paths in
the project (See git-config(1) ). This attribute gives you finer
-control per path.
-
+control per path.
+
Set
@@ -748,11 +796,25 @@ String
variable.
-
+
+
Creating an archive
+
export-ignore
+
Files and directories with the attribute export-ignore won't be added to
+archive files.
+
export-subst
+
If the attribute export-subst is set for a file then git will expand
+several placeholders when adding this file to an archive. The
+expansion depends on the availability of a commit ID, i.e., if
+git-archive(1) has been given a tree instead of a commit or a
+tag then no replacement will be done. The placeholders are the same
+as those for the option --pretty=format: of git-log(1) ,
+except that they need to be wrapped like this: $Format:PLACEHOLDERS$
+in the file. E.g. the string $Format:%H$ will be replaced by the
+commit hash.
-EXAMPLE
+EXAMPLE
-
If you have these three gitattributes file:
+
If you have these three gitattributes file:
(in $GIT_DIR/info/attributes)
@@ -767,8 +829,8 @@ ab* merge=filfre
abc -foo -bar
*.c frotz
-
the attributes given to path t/abc are computed as follows:
-
+the attributes given to path t/abc are computed as follows:
+
By examining t/.gitattributes (which is in the same
@@ -795,8 +857,8 @@ Finally it examines $GIT_DIR/info/attributes . This file
state, and baz is unset.
-
-
As the result, the attributes assignment to t/abc becomes:
+
+As the result, the attributes assignment to t/abc becomes:
foo set to true
@@ -805,28 +867,14 @@ baz set to false
merge set to string value "filfre"
frotz unspecified
-Creating an archive
-export-ignore
-Files and directories with the attribute export-ignore won't be added to
-archive files.
-export-subst
-If the attribute export-subst is set for a file then git will expand
-several placeholders when adding this file to an archive. The
-expansion depends on the availability of a commit ID, i.e., if
-git-archive has been given a tree instead of a commit or a
-tag then no replacement will be done. The placeholders are the same
-as those for the option --pretty=format: of git-log(1) ,
-except that they need to be wrapped like this: $Format:PLACEHOLDERS$
-in the file. E.g. the string $Format:%H$ will be replaced by the
-commit hash.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/gitattributes.txt b/gitattributes.txt
index 124170a96..d7b41142d 100644
--- a/gitattributes.txt
+++ b/gitattributes.txt
@@ -87,9 +87,9 @@ Checking-out and checking-in
These attributes affect how the contents stored in the
repository are copied to the working tree files when commands
-such as `git-checkout` and `git-merge` run. They also affect how
+such as 'git-checkout' and 'git-merge' run. They also affect how
git stores the contents you prepare in the working tree in the
-repository upon `git-add` and `git-commit`.
+repository upon 'git-add' and 'git-commit'.
`crlf`
^^^^^^
@@ -148,16 +148,16 @@ an irreversible conversion. The safety triggers to prevent such
a conversion done to the files in the work tree, but there are a
few exceptions. Even though...
-- `git-add` itself does not touch the files in the work tree, the
+- 'git-add' itself does not touch the files in the work tree, the
next checkout would, so the safety triggers;
-- `git-apply` to update a text file with a patch does touch the files
+- 'git-apply' to update a text file with a patch does touch the files
in the work tree, but the operation is about text files and CRLF
conversion is about fixing the line ending inconsistencies, so the
safety does not trigger;
-- `git-diff` itself does not touch the files in the work tree, it is
- often run to inspect the changes you intend to next `git-add`. To
+- 'git-diff' itself does not touch the files in the work tree, it is
+ often run to inspect the changes you intend to next 'git-add'. To
catch potential problems early, safety triggers.
@@ -214,7 +214,7 @@ with `crlf`, and then `ident` and fed to `filter`.
Generating diff text
~~~~~~~~~~~~~~~~~~~~
-The attribute `diff` affects if `git-diff` generates textual
+The attribute `diff` affects if 'git-diff' generates textual
patch for the path or just says `Binary files differ`. It also
can affect what line is shown on the hunk header `@@ -k,l +n,m @@`
line.
@@ -278,7 +278,7 @@ is prefixed with a line of the form:
The text is called 'hunk header', and by default a line that
begins with an alphabet, an underscore or a dollar sign is used,
-which matches what GNU `diff -p` output uses. This default
+which matches what GNU 'diff -p' output uses. This default
selection however is not suited for some contents, and you can
use customized pattern to make a selection.
@@ -322,7 +322,7 @@ and other programs such as `git revert` and `git cherry-pick`.
Set::
Built-in 3-way merge driver is used to merge the
- contents in a way similar to `merge` command of `RCS`
+ contents in a way similar to 'merge' command of `RCS`
suite. This is suitable for ordinary text files.
Unset::
@@ -426,7 +426,7 @@ Checking whitespace errors
^^^^^^^^^^^^
The `core.whitespace` configuration variable allows you to define what
-`diff` and `apply` should consider whitespace errors for all paths in
+'diff' and 'apply' should consider whitespace errors for all paths in
the project (See linkgit:git-config[1]). This attribute gives you finer
control per path.
@@ -450,6 +450,29 @@ String::
variable.
+Creating an archive
+~~~~~~~~~~~~~~~~~~~
+
+`export-ignore`
+^^^^^^^^^^^^^^^
+
+Files and directories with the attribute `export-ignore` won't be added to
+archive files.
+
+`export-subst`
+^^^^^^^^^^^^^^
+
+If the attribute `export-subst` is set for a file then git will expand
+several placeholders when adding this file to an archive. The
+expansion depends on the availability of a commit ID, i.e., if
+linkgit:git-archive[1] has been given a tree instead of a commit or a
+tag then no replacement will be done. The placeholders are the same
+as those for the option `--pretty=format:` of linkgit:git-log[1],
+except that they need to be wrapped like this: `$Format:PLACEHOLDERS$`
+in the file. E.g. the string `$Format:%H$` will be replaced by the
+commit hash.
+
+
EXAMPLE
-------
@@ -499,28 +522,6 @@ frotz unspecified
----------------------------------------------------------------
-Creating an archive
-~~~~~~~~~~~~~~~~~~~
-
-`export-ignore`
-^^^^^^^^^^^^^^^
-
-Files and directories with the attribute `export-ignore` won't be added to
-archive files.
-
-`export-subst`
-^^^^^^^^^^^^^^
-
-If the attribute `export-subst` is set for a file then git will expand
-several placeholders when adding this file to an archive. The
-expansion depends on the availability of a commit ID, i.e., if
-`git-archive` has been given a tree instead of a commit or a
-tag then no replacement will be done. The placeholders are the same
-as those for the option `--pretty=format:` of linkgit:git-log[1],
-except that they need to be wrapped like this: `$Format:PLACEHOLDERS$`
-in the file. E.g. the string `$Format:%H$` will be replaced by the
-commit hash.
-
GIT
---
diff --git a/gitcore-tutorial.html b/gitcore-tutorial.html
index 4d31bd94a..fb37259cb 100644
--- a/gitcore-tutorial.html
+++ b/gitcore-tutorial.html
@@ -3,7 +3,7 @@
-
+
gitcore-tutorial(7)
@@ -272,21 +320,21 @@ gitcore-tutorial(7) Manual Page
SYNOPSIS
-DESCRIPTION
+DESCRIPTION
-
This tutorial explains how to use the "core" git programs to set up and
-work with a git repository.
-
If you just need to use git as a revision control system you may prefer
+
This tutorial explains how to use the "core" git programs to set up and
+work with a git repository.
+
If you just need to use git as a revision control system you may prefer
to start with "A Tutorial Introduction to GIT" (gittutorial(7) ) or
-the GIT User Manual .
-
However, an understanding of these low-level tools can be helpful if
-you want to understand git's internals.
-
The core git is often called "plumbing", with the prettier user
+the GIT User Manual .
+
However, an understanding of these low-level tools can be helpful if
+you want to understand git's internals.
+
The core git is often called "plumbing", with the prettier user
interfaces on top of it called "porcelain". You may not want to use the
plumbing directly very often, but it can be good to know what the
-plumbing does for when the porcelain isn't flushing.
+plumbing does for when the porcelain isn't flushing.
@@ -297,43 +345,43 @@ skip on your first reading.
-Creating a git repository
+Creating a git repository
-
Creating a new git repository couldn't be easier: all git repositories start
+
Creating a new git repository couldn't be easier: all git repositories start
out empty, and the only thing you need to do is find yourself a
subdirectory that you want to use as a working tree - either an empty
one for a totally new project, or an existing working tree that you want
-to import into git.
-
For our first example, we're going to start a totally new repository from
-scratch, with no pre-existing files, and we'll call it git-tutorial .
+to import into git.
+
For our first example, we're going to start a totally new repository from
+scratch, with no pre-existing files, and we'll call it git-tutorial .
To start up, create a subdirectory for it, change into that
-subdirectory, and initialize the git infrastructure with git-init :
+subdirectory, and initialize the git infrastructure with
git-init :
$ mkdir git-tutorial
$ cd git-tutorial
$ git init
-
to which git will reply
+
Initialized empty Git repository in .git/
-
which is just git's way of saying that you haven't been doing anything
+
which is just git's way of saying that you haven't been doing anything
strange, and that it will have created a local .git directory setup for
your new project. You will now have a .git directory, and you can
-inspect that with ls . For your new empty project, it should show you
-three entries, among other things:
-
+inspect that with ls . For your new empty project, it should show you
+three entries, among other things:
+
a file called HEAD , that has ref: refs/heads/master in it.
This is similar to a symbolic link and points at
refs/heads/master relative to the HEAD file.
-Don't worry about the fact that the file that the HEAD link points to
+
Don't worry about the fact that the file that the HEAD link points to
doesn't even exist yet — you haven't created the commit that will
-start your HEAD development branch yet.
+start your
HEAD development branch yet.
@@ -348,22 +396,22 @@ a subdirectory called objects , which will contain all the
a subdirectory called refs , which contains references to objects.
-
-
In particular, the refs subdirectory will contain two other
+
+
In particular, the refs subdirectory will contain two other
subdirectories, named heads and tags respectively. They do
exactly what their names imply: they contain references to any number
of different heads of development (aka branches ), and to any
tags that you have created to name specific versions in your
-repository.
-
One note: the special master head is the default branch, which is
+repository.
+
One note: the special master head is the default branch, which is
why the .git/HEAD file was created points to it even if it
doesn't yet exist. Basically, the HEAD link is supposed to always
point to the branch you are working on right now, and you always
-start out expecting to work on the master branch.
-
However, this is only a convention, and you can name your branches
+start out expecting to work on the master branch.
+
However, this is only a convention, and you can name your branches
anything you want, and don't have to ever even have a master
branch. A number of the git tools will assume that .git/HEAD is
-valid, though.
+valid, though.
@@ -388,24 +436,24 @@ populating your tree.
after finishing this tutorial.
-
You have now created your first git repository. Of course, since it's
-empty, that's not very useful, so let's start populating it with data.
+
You have now created your first git repository. Of course, since it's
+empty, that's not very useful, so let's start populating it with data.
-Populating a git repository
+Populating a git repository
-
We'll keep this simple and stupid, so we'll start off with populating a
-few trivial files just to get a feel for it.
-
Start off with just creating any random files that you want to maintain
+
We'll keep this simple and stupid, so we'll start off with populating a
+few trivial files just to get a feel for it.
+
Start off with just creating any random files that you want to maintain
in your git repository. We'll start off with a few bad examples, just to
-get a feel for how this works:
+get a feel for how this works:
$ echo "Hello World" >hello
$ echo "Silly example" >example
-
you have now created two files in your working tree (aka working directory ),
-but to actually check in your hard work, you will have to go through two steps:
-
+you have now created two files in your working tree (aka working directory ),
+but to actually check in your hard work, you will have to go through two steps:
+
-
The first step is trivial: when you want to tell git about any changes
-to your working tree, you use the git-update-index program. That
+
+The first step is trivial: when you want to tell git about any changes
+to your working tree, you use the git-update-index program. That
program normally just takes a list of filenames you want to update, but
to avoid trivial mistakes, it refuses to add new entries to the index
(or remove existing ones) unless you explicitly tell it that you're
adding a new entry with the --add flag (or removing an entry with the
---remove ) flag.
-
So to populate the index with the two files you just created, you can do
+
--remove ) flag.
+So to populate the index with the two files you just created, you can do
$ git update-index --add hello example
-and you have now told git to track those two files.
-In fact, as you did that, if you now look into your object directory,
+
and you have now told git to track those two files.
+In fact, as you did that, if you now look into your object directory,
you'll notice that git will have added two new objects to the object
-database. If you did exactly the steps above, you should now be able to do
+database. If you did exactly the steps above, you should now be able to do
-and see two files:
+
.git/objects/55/7db03de997c86a4a028e1ebd3a1ceb225be238
.git/objects/f2/4c74a2e500f5ee1332c86b94199f52b1d1d962
-which correspond with the objects with names of 557db… and
-f24c7… respectively.
-If you want to, you can use git-cat-file to look at those objects, but
-you'll have to use the object name, not the filename of the object:
+which correspond with the objects with names of 557db… and
+f24c7… respectively.
+If you want to, you can use git-cat-file to look at those objects, but
+you'll have to use the object name, not the filename of the object:
$ git cat-file -t 557db03de997c86a4a028e1ebd3a1ceb225be238
-where the -t tells git-cat-file to tell you what the "type" of the
+
where the -t tells git-cat-file to tell you what the "type" of the
object is. git will tell you that you have a "blob" object (i.e., just a
-regular file), and you can see the contents with
+regular file), and you can see the contents with
$ git cat-file "blob" 557db03
-which will print out "Hello World". The object 557db03 is nothing
-more than the contents of your file hello .
+which will print out "Hello World". The object 557db03 is nothing
+more than the contents of your file hello .
@@ -482,39 +530,39 @@ abbreviate the object name to only the first several
hexadecimal digits in most places.
-Anyway, as we mentioned previously, you normally never actually take a
+
Anyway, as we mentioned previously, you normally never actually take a
look at the objects themselves, and typing long 40-character hex
names is not something you'd normally want to do. The above digression
-was just to show that git-update-index did something magical, and
+was just to show that git-update-index did something magical, and
actually saved away the contents of your files into the git object
-database.
-
Updating the index did something else too: it created a .git/index
+database.
+Updating the index did something else too: it created a .git/index
file. This is the index that describes your current working tree, and
something you should be very aware of. Again, you normally never worry
about the index file itself, but you should be aware of the fact that
you have not actually really "checked in" your files into git so far,
-you've only told git about them.
-
However, since git knows about them, you can now start using some of the
-most basic git commands to manipulate the files or look at their status.
-
In particular, let's not even check in the two files into git yet, we'll
-start off by adding another line to hello first:
+you've only
told git about them.
+However, since git knows about them, you can now start using some of the
+most basic git commands to manipulate the files or look at their status.
+In particular, let's not even check in the two files into git yet, we'll
+start off by adding another line to hello first:
$ echo "It's a new day for git" >>hello
-and you can now, since you told git about the previous state of hello , ask
+
and you can now, since you told git about the previous state of hello , ask
git what has changed in the tree compared to your old index, using the
-git-diff-files command:
+
git-diff-files command:
-Oops. That wasn't very readable. It just spit out its own internal
-version of a diff , but that internal version really just tells you
+
Oops. That wasn't very readable. It just spit out its own internal
+version of a diff , but that internal version really just tells you
that it has noticed that "hello" has been modified, and that the old object
-contents it had have been replaced with something else.
-
To make it readable, we can tell git-diff-files to output the
-differences as a patch, using the -p flag:
+contents it had have been replaced with something else.
+To make it readable, we can tell git-diff-files to output the
+differences as a patch, using the -p flag:
$ git diff-files -p
@@ -526,12 +574,12 @@ index 557db03..263414f 100644
Hello World
+It's a new day for git
-i.e. the diff of the change we caused by adding another line to hello .
-In other words, git-diff-files always shows us the difference between
+
i.e. the diff of the change we caused by adding another line to hello .
+In other words, git-diff-files always shows us the difference between
what is recorded in the index, and what is currently in the working
-tree. That's very useful.
-
A common shorthand for git diff-files -p is to just write git
-diff , which will do the same thing.
+tree. That's very useful.
+A common shorthand for git diff-files -p is to just write git
+diff , which will do the same thing.
$ git diff
@@ -544,196 +592,196 @@ index 557db03..263414f 100644
+It's a new day for git
-Committing git state
+Committing git state
-
Now, we want to go to the next stage in git, which is to take the files
+
Now, we want to go to the next stage in git, which is to take the files
that git knows about in the index, and commit them as a real tree. We do
that in two phases: creating a tree object, and committing that tree
object as a commit object together with an explanation of what the
-tree was all about, along with information of how we came to that state.
-
Creating a tree object is trivial, and is done with git-write-tree .
+tree was all about, along with information of how we came to that state.
+
Creating a tree object is trivial, and is done with git-write-tree .
There are no options or other input: git write-tree will take the
current index state, and write an object that describes that whole
index. In other words, we're now tying together all the different
filenames with their contents (and their permissions), and we're
-creating the equivalent of a git "directory" object:
+creating the equivalent of a git "directory" object:
-
and this will just output the name of the resulting tree, in this case
-(if you have done exactly as I've described) it should be
+
and this will just output the name of the resulting tree, in this case
+(if you have done exactly as I've described) it should be
8988da15d077d4829fc51d8544c097def6644dbb
-
which is another incomprehensible object name. Again, if you want to,
+
which is another incomprehensible object name. Again, if you want to,
you can use git cat-file -t 8988d... to see that this time the object
is not a "blob" object, but a "tree" object (you can also use
git cat-file to actually output the raw object contents, but you'll see
-mainly a binary mess, so that's less interesting).
-
However — normally you'd never use git-write-tree on its own, because
+mainly a binary mess, so that's less interesting).
+
However — normally you'd never use git-write-tree on its own, because
normally you always commit a tree into a commit object using the
-git-commit-tree command. In fact, it's easier to not actually use
-git-write-tree on its own at all, but to just pass its result in as an
-argument to git-commit-tree .
-
git-commit-tree normally takes several arguments — it wants to know
+git-commit-tree command. In fact, it's easier to not actually use
+git-write-tree on its own at all, but to just pass its result in as an
+argument to git-commit-tree .
+
git-commit-tree normally takes several arguments — it wants to know
what the parent of a commit was, but since this is the first commit
ever in this new repository, and it has no parents, we only need to pass in
-the object name of the tree. However, git-commit-tree also wants to get a
+the object name of the tree. However, git-commit-tree also wants to get a
commit message on its standard input, and it will write out the resulting
-object name for the commit to its standard output.
-
And this is where we create the .git/refs/heads/master file
+object name for the commit to its standard output.
+
And this is where we create the .git/refs/heads/master file
which is pointed at by HEAD . This file is supposed to contain
the reference to the top-of-tree of the master branch, and since
-that's exactly what git-commit-tree spits out, we can do this
-all with a sequence of simple shell commands:
+that's exactly what
git-commit-tree spits out, we can do this
+all with a sequence of simple shell commands:
$ tree=$(git write-tree)
$ commit=$(echo 'Initial commit' | git commit-tree $tree)
$ git update-ref HEAD $commit
-
In this case this creates a totally new commit that is not related to
+
In this case this creates a totally new commit that is not related to
anything else. Normally you do this only once for a project ever, and
-all later commits will be parented on top of an earlier commit.
-
Again, normally you'd never actually do this by hand. There is a
+all later commits will be parented on top of an earlier commit.
+
Again, normally you'd never actually do this by hand. There is a
helpful script called git commit that will do all of this for you. So
you could have just written git commit
-instead, and it would have done the above magic scripting for you.
+instead, and it would have done the above magic scripting for you.
-Making a change
+Making a change
-
Remember how we did the git-update-index on file hello and then we
+
Remember how we did the git-update-index on file hello and then we
changed hello afterward, and could compare the new state of hello with the
-state we saved in the index file?
-
Further, remember how I said that git-write-tree writes the contents
+state we saved in the index file?
+
Further, remember how I said that git-write-tree writes the contents
of the index file to the tree, and thus what we just committed was in
fact the original contents of the file hello , not the new ones. We did
that on purpose, to show the difference between the index state, and the
state in the working tree, and how they don't have to match, even
-when we commit things.
-
As before, if we do git diff-files -p in our git-tutorial project,
+when we commit things.
+
As before, if we do git diff-files -p in our git-tutorial project,
we'll still see the same difference we saw last time: the index file
hasn't changed by the act of committing anything. However, now that we
have committed something, we can also learn to use a new command:
-git-diff-index .
-
Unlike git-diff-files , which showed the difference between the index
-file and the working tree, git-diff-index shows the differences
+git-diff-index .
+
Unlike git-diff-files , which showed the difference between the index
+file and the working tree, git-diff-index shows the differences
between a committed tree and either the index file or the working
-tree. In other words, git-diff-index wants a tree to be diffed
+tree. In other words, git-diff-index wants a tree to be diffed
against, and before we did the commit, we couldn't do that, because we
-didn't have anything to diff against.
-
But now we can do
+didn't have anything to diff against.
+
-
(where -p has the same meaning as it did in git-diff-files ), and it
+
(where -p has the same meaning as it did in git-diff-files ), and it
will show us the same difference, but for a totally different reason.
Now we're comparing the working tree not against the index file,
but against the tree we just wrote. It just so happens that those two
-are obviously the same, so we get the same result.
-
Again, because this is a common operation, you can also just shorthand
-it with
+are obviously the same, so we get the same result.
+
Again, because this is a common operation, you can also just shorthand
+it with
-
which ends up doing the above for you.
-
In other words, git-diff-index normally compares a tree against the
+
which ends up doing the above for you.
+
In other words, git-diff-index normally compares a tree against the
working tree, but when given the --cached flag, it is told to
instead compare against just the index cache contents, and ignore the
current working tree state entirely. Since we just wrote the index
file to HEAD, doing git diff-index --cached -p HEAD should thus return
-an empty set of differences, and that's exactly what it does.
+an empty set of differences, and that's exactly what it does.
Note
-git-diff-index really always uses the index for its
+
git-diff-index really always uses the index for its
comparisons, and saying that it compares a tree against the working
tree is thus not strictly accurate. In particular, the list of
files to compare (the "meta-data") always comes from the index file,
regardless of whether the --cached flag is used or not. The --cached
flag really only determines whether the file contents to be compared
-come from the working tree or not.
-
This is not hard to understand, as soon as you realize that git simply
+come from the working tree or not.
+This is not hard to understand, as soon as you realize that git simply
never knows (or cares) about files that it is not told about
explicitly. git will never go looking for files to compare, it
expects you to tell it what the files are, and that's what the index
-is there for.
+is there for.
-
However, our next step is to commit the change we did, and again, to
+
However, our next step is to commit the change we did, and again, to
understand what's going on, keep in mind the difference between "working
tree contents", "index file" and "committed tree". We have changes
in the working tree that we want to commit, and we always have to
work through the index file, so the first thing we need to do is to
-update the index cache:
+update the index cache:
-
(note how we didn't need the --add flag this time, since git knew
-about the file already).
-
Note what happens to the different git-diff-* versions here. After
+
(note how we didn't need the --add flag this time, since git knew
+about the file already).
+
Note what happens to the different git-diff-* versions here. After
we've updated hello in the index, git diff-files -p now shows no
differences, but git diff-index -p HEAD still *does* show that the
current state is different from the state we committed. In fact, now
-git-diff-index shows the same difference whether we use the --cached
-flag or not, since now the index is coherent with the working tree.
-
Now, since we've updated hello in the index, we can commit the new
+git-diff-index shows the same difference whether we use the --cached
+flag or not, since now the index is coherent with the working tree.
+
Now, since we've updated hello in the index, we can commit the new
version. We could do it by writing the tree by hand again, and
committing the tree (this time we'd have to use the -p HEAD flag to
tell commit that the HEAD was the parent of the new commit, and that
this wasn't an initial commit any more), but you've done that once
-already, so let's just use the helpful script this time:
+already, so let's just use the helpful script this time:
-
which starts an editor for you to write the commit message and tells you
-a bit about what you have done.
-
Write whatever message you want, and all the lines that start with #
+
which starts an editor for you to write the commit message and tells you
+a bit about what you have done.
+
Write whatever message you want, and all the lines that start with #
will be pruned out, and the rest will be used as the commit message for
the change. If you decide you don't want to commit anything after all at
this point (you can continue to edit things and update the index), you
can just leave an empty message. Otherwise git commit will commit
-the change for you.
-
You've now made your first real git commit. And if you're interested in
+the change for you.
+
You've now made your first real git commit. And if you're interested in
looking at what git commit really does, feel free to investigate:
it's a few very simple shell scripts to generate the helpful (?) commit
message headers, and a few one-liners that actually do the
-commit itself (git-commit ).
+commit itself (
git-commit ).
-Inspecting Changes
+Inspecting Changes
-
While creating changes is useful, it's even more useful if you can tell
+
While creating changes is useful, it's even more useful if you can tell
later what changed. The most useful command for this is another of the
-diff family, namely git-diff-tree .
-
git-diff-tree can be given two arbitrary trees, and it will tell you the
+diff family, namely git-diff-tree .
+
git-diff-tree can be given two arbitrary trees, and it will tell you the
differences between them. Perhaps even more commonly, though, you can
give it just a single commit object, and it will figure out the parent
of that commit itself, and show the difference directly. Thus, to get
-the same diff that we've already seen several times, we can now do
+the same diff that we've already seen several times, we can now do
-
(again, -p means to show the difference as a human-readable patch),
-and it will show what the last commit (in HEAD ) actually changed.
+
(again, -p means to show the difference as a human-readable patch),
+and it will show what the last commit (in HEAD ) actually changed.
Note
-Here is an ASCII art by Jon Loeliger that illustrates how
-various diff-* commands compare things.
+Here is an ASCII art by Jon Loeliger that illustrates how
+various diff-* commands compare things.
diff-tree
@@ -768,31 +816,31 @@ diff-index | V
-
More interestingly, you can also give git-diff-tree the --pretty flag,
+
More interestingly, you can also give git-diff-tree the --pretty flag,
which tells it to also show the commit message and author and date of the
commit, and you can tell it to show a whole series of diffs.
Alternatively, you can tell it to be "silent", and not show the diffs at
-all, but just show the actual commit message.
-
In fact, together with the git-rev-list program (which generates a
-list of revisions), git-diff-tree ends up being a veritable fount of
-changes. A trivial (but very useful) script called git-whatchanged is
+all, but just show the actual commit message.
+
In fact, together with the git-rev-list program (which generates a
+list of revisions), git-diff-tree ends up being a veritable fount of
+changes. A trivial (but very useful) script called git-whatchanged is
included with git which does exactly this, and shows a log of recent
-activities.
-
To see the whole history of our pitiful little git-tutorial project, you
-can do
+activities.
+
To see the whole history of our pitiful little git-tutorial project, you
+can do
-
which shows just the log messages, or if we want to see the log together
+
which shows just the log messages, or if we want to see the log together
with the associated patches use the more complex (and much more
-powerful)
+powerful)
-
and you will see exactly what has changed in the repository over its
-short history.
+
and you will see exactly what has changed in the repository over its
+short history.
@@ -802,69 +850,69 @@ short history.
If this is a problem because it is huge, you can hide it by setting
the log.showroot configuration variable to false. Having this, you
can still show it for each command just adding the --root option,
-which is a flag for git-diff-tree accepted by both commands.
+which is a flag for git-diff-tree accepted by both commands.
-
With that, you should now be having some inkling of what git does, and
-can explore on your own.
+
With that, you should now be having some inkling of what git does, and
+can explore on your own.
Note
Most likely, you are not directly using the core
-git Plumbing commands, but using Porcelain such as git-add , `git-rm'
+git Plumbing commands, but using Porcelain such as git-add , `git-rm'
and `git-commit'.
-Tagging a version
+Tagging a version
-
In git, there are two kinds of tags, a "light" one, and an "annotated tag".
-
A "light" tag is technically nothing more than a branch, except we put
+
In git, there are two kinds of tags, a "light" one, and an "annotated tag".
+
A "light" tag is technically nothing more than a branch, except we put
it in the .git/refs/tags/ subdirectory instead of calling it a head .
-So the simplest form of tag involves nothing more than
+So the simplest form of tag involves nothing more than
-
which just writes the current HEAD into the .git/refs/tags/my-first-tag
+
which just writes the current HEAD into the .git/refs/tags/my-first-tag
file, after which point you can then use this symbolic name for that
-particular state. You can, for example, do
+particular state. You can, for example, do
-
to diff your current state against that tag which at this point will
+
to diff your current state against that tag which at this point will
obviously be an empty diff, but if you continue to develop and commit
stuff, you can use your tag as an "anchor-point" to see what has changed
-since you tagged it.
-
An "annotated tag" is actually a real git object, and contains not only a
+since you tagged it.
+
An "annotated tag" is actually a real git object, and contains not only a
pointer to the state you want to tag, but also a small tag name and
message, along with optionally a PGP signature that says that yes,
you really did
that tag. You create these annotated tags with either the -a or
--s flag to git tag :
+
-s flag to
git-tag :
-
which will sign the current HEAD (but you can also give it another
+
which will sign the current HEAD (but you can also give it another
argument that specifies the thing to tag, i.e., you could have tagged the
-current mybranch point by using git tag <tagname> mybranch ).
-
You normally only do signed tags for major releases or things
+current mybranch point by using git tag <tagname> mybranch ).
+
You normally only do signed tags for major releases or things
like that, while the light-weight tags are useful for any marking you
want to do — any time you decide that you want to remember a certain
point, just create a private tag for it, and you have a nice symbolic
-name for the state at that point.
+name for the state at that point.
-Copying repositories
+Copying repositories
-
git repositories are normally totally self-sufficient and relocatable.
+
git repositories are normally totally self-sufficient and relocatable.
Unlike CVS, for example, there is no separate notion of
"repository" and "working tree". A git repository normally is the
working tree, with the local git information hidden in the .git
-subdirectory. There is nothing else. What you see is what you got.
+subdirectory. There is nothing else. What you see is what you got.
@@ -878,8 +926,8 @@ the working tree that it describes" may not be technically 100%
accurate, but it's a good model for all normal use.
-
This has two implications:
-
+This has two implications:
+
-and it will be gone. There's no external repository, and there's no
-history outside the project you created.
+and it will be gone. There's no external repository, and there's no
+history outside the project you created.
if you want to move or duplicate a git repository, you can do so. There
- is git clone command, but if all you want to do is just to
+ is git-clone command, but if all you want to do is just to
create a copy of your repository (with all the full history that
went along with it), you can do so with a regular
cp -a git-tutorial new-git-tutorial .
-Note that when you've moved or copied a git repository, your git index
+
Note that when you've moved or copied a git repository, your git index
file (which caches various information, notably some of the "stat"
information for the files involved) will likely need to be refreshed.
-So after you do a cp -a to create a new copy, you'll want to do
+So after you do a
cp -a to create a new copy, you'll want to do
$ git update-index --refresh
-in the new repository to make sure that the index file is up-to-date.
+in the new repository to make sure that the index file is up-to-date.
-
-
Note that the second point is true even across machines. You can
+
+Note that the second point is true even across machines. You can
duplicate a remote git repository with any regular copy mechanism, be it
-scp , rsync or wget .
-
When copying a remote repository, you'll want to at a minimum update the
+scp , rsync or wget .
+When copying a remote repository, you'll want to at a minimum update the
index cache when you do this, and especially with other peoples'
repositories you often want to make sure that the index cache is in some
known state (you don't know what they've done and not yet checked in),
-so usually you'll precede the git-update-index with a
+so usually you'll precede the
git-update-index with a
$ git read-tree --reset HEAD
$ git update-index --refresh
-which will force a total index re-build from the tree pointed to by HEAD .
-It resets the index contents to HEAD , and then the git-update-index
+
which will force a total index re-build from the tree pointed to by HEAD .
+It resets the index contents to HEAD , and then the git-update-index
makes sure to match up all index entries with the checked-out files.
If the original repository had uncommitted changes in its
working tree, git update-index --refresh notices them and
-tells you they need to be updated.
-
The above can also be written as simply
+tells you they need to be updated.
+The above can also be written as simply
-and in fact a lot of the common git command combinations can be scripted
+
and in fact a lot of the common git command combinations can be scripted
with the git xyz interfaces. You can learn things by just looking
at what the various git scripts do. For example, git reset used to be
-the above two lines implemented in git-reset , but some things like
-git-status and git-commit are slightly more complex scripts around
-the basic git commands.
-
Many (most?) public remote repositories will not contain any of
+the above two lines implemented in git-reset , but some things like
+git-status and git-commit are slightly more complex scripts around
+the basic git commands.
+Many (most?) public remote repositories will not contain any of
the checked out files or even an index file, and will only contain the
actual core git files. Such a repository usually doesn't even have the
.git subdirectory, but has all the git files directly in the
-repository.
-
To create your own local live copy of such a "raw" git repository, you'd
+repository.
+To create your own local live copy of such a "raw" git repository, you'd
first create your own subdirectory for the project, and then copy the
raw repository contents into the .git directory. For example, to
-create your own copy of the git repository, you'd do the following
+create your own copy of the git repository, you'd do the following
$ mkdir my-git
$ cd my-git
$ rsync -rL rsync://rsync.kernel.org/pub/scm/git/git.git/ .git
-followed by
+
-to populate the index. However, now you have populated the index, and
+
to populate the index. However, now you have populated the index, and
you have all the git internal files, but you will notice that you don't
actually have any of the working tree files to work on. To get
-those, you'd check them out with
+those, you'd check them out with
$ git checkout-index -u -a
-where the -u flag means that you want the checkout to keep the index
+
where the -u flag means that you want the checkout to keep the index
up-to-date (so that you don't have to refresh it afterward), and the
-a flag means "check out all files" (if you have a stale copy or an
older version of a checked out tree you may also need to add the -f
-flag first, to tell git-checkout-index to force overwriting of any old
-files).
-
Again, this can all be simplified with
+flag first, to tell
git-checkout-index to
force overwriting of any old
+files).
+Again, this can all be simplified with
$ git clone rsync://rsync.kernel.org/pub/scm/git/git.git/ my-git
$ cd my-git
$ git checkout
-which will end up doing all of the above for you.
-You have now successfully copied somebody else's (mine) remote
-repository, and checked it out.
+which will end up doing all of the above for you.
+You have now successfully copied somebody else's (mine) remote
+repository, and checked it out.
-Creating a new branch
+Creating a new branch
-
Branches in git are really nothing more than pointers into the git
+
Branches in git are really nothing more than pointers into the git
object database from within the .git/refs/ subdirectory, and as we
already discussed, the HEAD branch is nothing but a symlink to one of
-these object pointers.
-
You can at any time create a new branch by just picking an arbitrary
+these object pointers.
+
You can at any time create a new branch by just picking an arbitrary
point in the project history, and just writing the SHA1 name of that
object into a file under .git/refs/heads/ . You can use any filename you
want (and indeed, subdirectories), but the convention is that the
"normal" branch is called master . That's just a convention, though,
-and nothing enforces it.
-
To show that as an example, let's go back to the git-tutorial repository we
+and nothing enforces it.
+
To show that as an example, let's go back to the git-tutorial repository we
used earlier, and create a branch in it. You do that by simply just
-saying that you want to check out a new branch:
+saying that you want to check out a new branch:
$ git checkout -b mybranch
-
will create a new branch based at the current HEAD position, and switch
-to it.
+
will create a new branch based at the current HEAD position, and switch
+to it.
Note
-If you make the decision to start your new branch at some
+
If you make the decision to start your new branch at some
other point in the history than the current HEAD , you can do so by
-just telling git checkout what the base of the checkout would be.
-In other words, if you have an earlier tag or branch, you'd just do
+just telling
git-checkout what the base of the checkout would be.
+In other words, if you have an earlier tag or branch, you'd just do
$ git checkout -b mybranch earlier-commit
-and it would create the new branch mybranch at the earlier commit,
-and check out the state at that time.
+and it would create the new branch mybranch at the earlier commit,
+and check out the state at that time.
-
You can always just jump back to your original master branch by doing
+
You can always just jump back to your original master branch by doing
-
(or any other branch-name, for that matter) and if you forget which
-branch you happen to be on, a simple
+
(or any other branch-name, for that matter) and if you forget which
+branch you happen to be on, a simple
-
will tell you where it's pointing. To get the list of branches
-you have, you can say
+
will tell you where it's pointing. To get the list of branches
+you have, you can say
-
which used to be nothing more than a simple script around ls .git/refs/heads .
-There will be an asterisk in front of the branch you are currently on.
-
Sometimes you may wish to create a new branch _without_ actually
-checking it out and switching to it. If so, just use the command
+
which used to be nothing more than a simple script around ls .git/refs/heads .
+There will be an asterisk in front of the branch you are currently on.
+
Sometimes you may wish to create a new branch without actually
+checking it out and switching to it. If so, just use the command
$ git branch <branchname> [startingpoint]
-
which will simply _create_ the branch, but will not do anything further.
+
which will simply create the branch, but will not do anything further.
You can then later — once you decide that you want to actually develop
-on that branch — switch to that branch with a regular git checkout
-with the branchname as the argument.
+on that branch — switch to that branch with a regular
git-checkout
+with the branchname as the argument.
-Merging two branches
+Merging two branches
-
One of the ideas of having a branch is that you do some (possibly
+
One of the ideas of having a branch is that you do some (possibly
experimental) work in it, and eventually merge it back to the main
branch. So assuming you created the above mybranch that started out
being the same as the original master branch, let's make sure we're in
-that branch, and do some work there.
+that branch, and do some work there.
$ git checkout mybranch
$ echo "Work, work, work" >>hello
$ git commit -m "Some work." -i hello
-
Here, we just added another line to hello , and we used a shorthand for
+
Here, we just added another line to hello , and we used a shorthand for
doing both git update-index hello and git commit by just giving the
filename directly to git commit , with an -i flag (it tells
git to include that file in addition to what you have done to
the index file so far when making the commit). The -m flag is to give the
-commit log message from the command line.
-
Now, to make it a bit more interesting, let's assume that somebody else
+commit log message from the command line.
+
Now, to make it a bit more interesting, let's assume that somebody else
does some work in the original branch, and simulate that by going back
-to the master branch, and editing the same file differently there:
+to the master branch, and editing the same file differently there:
-
Here, take a moment to look at the contents of hello , and notice how they
+
Here, take a moment to look at the contents of hello , and notice how they
don't contain the work we just did in mybranch — because that work
-hasn't happened in the master branch at all. Then do
+hasn't happened in the
master branch at all. Then do
$ echo "Play, play, play" >>hello
$ echo "Lots of fun" >>example
$ git commit -m "Some fun." -i hello example
-
since the master branch is obviously in a much better mood.
-
Now, you've got two branches, and you decide that you want to merge the
+
since the master branch is obviously in a much better mood.
+
Now, you've got two branches, and you decide that you want to merge the
work done. Before we do that, let's introduce a cool graphical tool that
-helps you view what's going on:
+helps you view what's going on:
-
will show you graphically both of your branches (that's what the --all
+
will show you graphically both of your branches (that's what the --all
means: normally it will just show you your current HEAD ) and their
histories. You can also see exactly how they came to be from a common
-source.
-
Anyway, let's exit gitk (^Q or the File menu), and decide that we want
+source.
+
Anyway, let's exit gitk (^Q or the File menu), and decide that we want
to merge the work we did on the mybranch branch into the master
branch (which is currently our HEAD too). To do that, there's a nice
-script called git merge , which wants to know which branches you want
-to resolve and what the merge is all about:
+script called
git-merge , which wants to know which branches you want
+to resolve and what the merge is all about:
$ git merge -m "Merge work in mybranch" mybranch
-
where the first argument is going to be used as the commit message if
-the merge can be resolved automatically.
-
Now, in this case we've intentionally created a situation where the
+
where the first argument is going to be used as the commit message if
+the merge can be resolved automatically.
+
Now, in this case we've intentionally created a situation where the
merge will need to be fixed up by hand, though, so git will do as much
of it as it can automatically (which in this case is just merge the example
-file, which had no differences in the mybranch branch), and say:
+file, which had no differences in the
mybranch branch), and say:
Auto-merging hello
CONFLICT (content): Merge conflict in hello
Automatic merge failed; fix up by hand
-
It tells you that it did an "Automatic merge", which
-failed due to conflicts in hello .
-
Not to worry. It left the (trivial) conflict in hello in the same form you
+
It tells you that it did an "Automatic merge", which
+failed due to conflicts in hello .
+
Not to worry. It left the (trivial) conflict in hello in the same form you
should already be well used to if you've ever used CVS, so let's just
open hello in our editor (whatever that may be), and fix it up somehow.
-I'd suggest just making it so that hello contains all four lines:
+I'd suggest just making it so that
hello contains all four lines:
Hello World
@@ -1137,22 +1185,22 @@ It's a new day for git
Play, play, play
Work, work, work
-
and once you're happy with your manual merge, just do a
+
and once you're happy with your manual merge, just do a
-
which will very loudly warn you that you're now committing a merge
+
which will very loudly warn you that you're now committing a merge
(which is correct, so never mind), and you can write a small merge
-message about your adventures in git-merge -land.
-
After you're done, start up gitk --all to see graphically what the
+message about your adventures in git-merge -land.
+
After you're done, start up gitk --all to see graphically what the
history looks like. Notice that mybranch still exists, and you can
switch to it, and continue to work with it if you want to. The
mybranch branch will not contain the merge, but next time you merge it
from the master branch, git will know how you merged it, so you'll not
-have to do _that_ merge again.
-
Another useful tool, especially if you do not always work in X-Window
-environment, is git show-branch .
+have to do
that merge again.
+
Another useful tool, especially if you do not always work in X-Window
+environment, is git show-branch .
$ git show-branch --topo-order --more=1 master mybranch
@@ -1163,7 +1211,7 @@ environment, is git show-branch .
*+ [mybranch] Some work.
* [master^] Some fun.
-
The first two lines indicate that it is showing the two branches
+
The first two lines indicate that it is showing the two branches
and the first line of the commit log message from their
top-of-the-tree commits, you are currently on master branch
(notice the asterisk * character), and the first column for
@@ -1180,13 +1228,13 @@ before the commit log message is a short name you can use to
name the commit. In the above example, master and mybranch
are branch heads. master^ is the first parent of master
branch head. Please see git-rev-parse(1) if you want to
-see more complex cases.
+see more complex cases.
Note
-Without the --more=1 option, git-show-branch would not output the
+ Without the --more=1 option, git-show-branch would not output the
[master^] commit, as [mybranch] commit is a common ancestor of
both master and mybranch tips. Please see git-show-branch(1)
for details.
@@ -1198,22 +1246,22 @@ for details.
Note
If there were more commits on the master branch after the merge, the
-merge commit itself would not be shown by git-show-branch by
+merge commit itself would not be shown by git-show-branch by
default. You would need to provide --sparse option to make the
merge commit visible in this case.
-
Now, let's pretend you are the one who did all the work in
+
Now, let's pretend you are the one who did all the work in
mybranch , and the fruit of your hard work has finally been merged
to the master branch. Let's go back to mybranch , and run
-git-merge to get the "upstream changes" back to your branch.
+
git-merge to get the "upstream changes" back to your branch.
$ git checkout mybranch
$ git merge -m "Merge upstream changes." master
-
This outputs something like this (the actual commit object names
-would be different)
+
This outputs something like this (the actual commit object names
+would be different)
Updating from ae3a2da... to a80b4aa....
@@ -1222,13 +1270,13 @@ Fast forward
hello | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
-
Because your branch did not contain anything more than what are
+
Because your branch did not contain anything more than what are
already merged into the master branch, the merge operation did
not actually do a merge. Instead, it just updated the top of
the tree of your branch to that of the master branch. This is
-often called fast forward merge.
-
You can run gitk --all again to see how the commit ancestry
-looks like, or run show-branch , which tells you this.
+often called
fast forward merge.
+
You can run gitk --all again to see how the commit ancestry
+looks like, or run show-branch , which tells you this.
$ git show-branch master mybranch
@@ -1238,23 +1286,23 @@ looks like, or run show-branch , which tells you this.
-- [master] Merge work in mybranch
-Merging external work
+Merging external work
-
It's usually much more common that you merge with somebody else than
+
It's usually much more common that you merge with somebody else than
merging with your own branches, so it's worth pointing out that git
makes that very easy too, and in fact, it's not that different from
-doing a git merge . In fact, a remote merge ends up being nothing
+doing a git-merge . In fact, a remote merge ends up being nothing
more than "fetch the work from a remote repository into a temporary tag"
-followed by a git merge .
-
Fetching from a remote repository is done by, unsurprisingly,
-git fetch :
+followed by a
git-merge .
+
Fetching from a remote repository is done by, unsurprisingly,
+git-fetch :
$ git fetch <remote-repository>
-
One of the following transports can be used to name the
-repository to download from:
-
+One of the following transports can be used to name the
+repository to download from:
+
Rsync
@@ -1262,7 +1310,7 @@ Rsync
rsync://remote.machine/path/to/repo.git/
-Rsync transport is usable for both uploading and downloading,
+
Rsync transport is usable for both uploading and downloading,
but is completely unaware of what git does, and can produce
unexpected results when you download from the public repository
while the repository owner is uploading into it via rsync
@@ -1271,7 +1319,7 @@ transport. Most notably, it could update the files under
before uploading the files in objects/ — the downloader would
obtain head commit object name while that object itself is still
not available in the repository. For this reason, it is
-considered deprecated.
+considered deprecated.
SSH
@@ -1280,13 +1328,13 @@ SSH
remote.machine:/path/to/repo.git/ or
-ssh://remote.machine/path/to/repo.git/
-This transport can be used for both uploading and downloading,
+
ssh://remote.machine/path/to/repo.git/
+This transport can be used for both uploading and downloading,
and requires you to have a log-in privilege over ssh to the
remote machine. It finds out the set of objects the other side
lacks by exchanging the head commits both ends have and
transfers (close to) minimum set of objects. It is by far the
-most efficient way to exchange git objects between repositories.
+most efficient way to exchange git objects between repositories.
Local directory
@@ -1295,9 +1343,9 @@ Local directory
/path/to/repo.git/
-This transport is the same as SSH transport but uses sh to run
+
This transport is the same as SSH transport but uses sh to run
both ends on the local machine instead of running other end on
-the remote machine via ssh .
+the remote machine via
ssh .
git Native
@@ -1306,9 +1354,9 @@ git Native
git://remote.machine/path/to/repo.git/
-This transport was designed for anonymous downloading. Like SSH
+
This transport was designed for anonymous downloading. Like SSH
transport, it finds out the set of objects the downstream side
-lacks and transfers (close to) minimum set of objects.
+lacks and transfers (close to) minimum set of objects.
HTTP(S)
@@ -1317,7 +1365,7 @@ HTTP(S)
http://remote.machine/path/to/repo.git/
-Downloader from http and https URL
+
Downloader from http and https URL
first obtains the topmost commit object name from the remote site
by looking at the specified refname under repo.git/refs/ directory,
and then tries to obtain the
@@ -1326,26 +1374,26 @@ using the object name of that commit object. Then it reads the
commit object to find out its parent commits and the associate
tree object; it repeats this process until it gets all the
necessary objects. Because of this behavior, they are
-sometimes also called commit walkers .
-
The commit walkers are sometimes also called dumb
+sometimes also called commit walkers .
+The commit walkers are sometimes also called dumb
transports , because they do not require any git aware smart
server like git Native transport does. Any stock HTTP server
that does not even support directory index would suffice. But
-you must prepare your repository with git-update-server-info
-to help dumb transport downloaders.
+you must prepare your repository with
git-update-server-info
+to help dumb transport downloaders.
-
-
Once you fetch from the remote repository, you merge that
-with your current branch.
-
However — it's such a common thing to fetch and then
+
+Once you fetch from the remote repository, you merge that
+with your current branch.
+However — it's such a common thing to fetch and then
immediately merge , that it's called git pull , and you can
-simply do
+simply do
$ git pull <remote-repository>
-and optionally give a branch-name for the remote end as a second
-argument.
+and optionally give a branch-name for the remote end as a second
+argument.
@@ -1353,7 +1401,7 @@ argument.
You could do without using any branches at all, by
keeping as many local repositories as you would like to have
-branches, and merging between them with git pull , just like
+branches, and merging between them with git-pull , just like
you merge between branches. The advantage of this approach is
that it lets you keep a set of files for each branch checked
out and you may find it easier to switch back and forth if you
@@ -1362,17 +1410,17 @@ course, you will pay the price of more disk usage to hold
multiple working trees, but disk space is cheap these days.
-It is likely that you will be pulling from the same remote
+
It is likely that you will be pulling from the same remote
repository from time to time. As a short hand, you can store
the remote repository URL in the local repository's config file
-like this:
+like this:
$ git config remote.linus.url http://www.kernel.org/pub/scm/git/git.git/
-and use the "linus" keyword with git pull instead of the full URL.
-Examples.
-
+and use the "linus" keyword with git-pull instead of the full URL.
+
+
git pull linus
@@ -1383,9 +1431,9 @@ like this:
git pull linus tag v0.99.1
-
-
the above are equivalent to:
-
+
+the above are equivalent to:
+
git pull http://www.kernel.org/pub/scm/git/git.git/ HEAD
@@ -1396,18 +1444,18 @@ like this:
git pull http://www.kernel.org/pub/scm/git/git.git/ tag v0.99.1
-
+
-How does the merge work?
+How does the merge work?
-
We said this tutorial shows what plumbing does to help you cope
+
We said this tutorial shows what plumbing does to help you cope
with the porcelain that isn't flushing, but we so far did not
talk about how the merge really works. If you are following
this tutorial the first time, I'd suggest to skip to "Publishing
-your work" section and come back here later.
-
OK, still with me? To give us an example to look at, let's go
+your work" section and come back here later.
+
OK, still with me? To give us an example to look at, let's go
back to the earlier repository with "hello" and "example" file,
-and bring ourselves back to the pre-merge state:
+and bring ourselves back to the pre-merge state:
$ git show-branch --more=2 master mybranch
@@ -1418,9 +1466,9 @@ and bring ourselves back to the pre-merge state:
+* [master^2] Some work.
+* [master^] Some fun.
-
Remember, before running git merge , our master head was at
+
Remember, before running git-merge , our master head was at
"Some fun." commit, while our mybranch head was at "Some
-work." commit.
+work." commit.
$ git checkout mybranch
@@ -1428,7 +1476,7 @@ $ git reset --hard master^2
$ git checkout master
$ git reset --hard master^
-
After rewinding, the commit structure should look like this:
+
After rewinding, the commit structure should look like this:
$ git show-branch
@@ -1439,31 +1487,31 @@ $ git reset --hard master^
* [master] Some fun.
*+ [mybranch^] New day.
-
Now we are ready to experiment with the merge by hand.
-
git merge command, when merging two branches, uses 3-way merge
+
Now we are ready to experiment with the merge by hand.
+
git merge command, when merging two branches, uses 3-way merge
algorithm. First, it finds the common ancestor between them.
-The command it uses is git-merge-base :
+The command it uses is
git-merge-base :
$ mb=$(git merge-base HEAD mybranch)
-
The command writes the commit object name of the common ancestor
+
The command writes the commit object name of the common ancestor
to the standard output, so we captured its output to a variable,
because we will be using it in the next step. By the way, the common
ancestor commit is the "New day." commit in this case. You can
-tell it by:
+tell it by:
$ git name-rev $mb
my-first-tag
-
After finding out a common ancestor commit, the second step is
-this:
+
After finding out a common ancestor commit, the second step is
+this:
$ git read-tree -m -u $mb HEAD mybranch
-
This is the same git-read-tree command we have already seen,
+
This is the same git-read-tree command we have already seen,
but it takes three trees, unlike previous examples. This reads
the contents of each tree into different stage in the index
file (the first tree goes to stage 1, the second to stage 2,
@@ -1472,10 +1520,10 @@ that are the same in all three stages are collapsed into stage
0. Also paths that are the same in two of three stages are
collapsed into stage 0, taking the SHA1 from either stage 2 or
stage 3, whichever is different from stage 1 (i.e. only one side
-changed from the common ancestor).
-
After collapsing operation, paths that are different in three
+changed from the common ancestor).
+
After collapsing operation, paths that are different in three
trees are left in non-zero stages. At this point, you can
-inspect the index file with this command:
+inspect the index file with this command:
$ git ls-files --stage
@@ -1484,13 +1532,13 @@ inspect the index file with this command:
100644 06fa6a24256dc7e560efa5687fa84b51f0263c3a 2 hello
100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello
-
In our example of only two files, we did not have unchanged
+
In our example of only two files, we did not have unchanged
files so only example resulted in collapsing, but in real-life
large projects, only small number of files change in one commit,
and this collapsing tends to trivially merge most of the paths
fairly quickly, leaving only a handful the real changes in non-zero
-stages.
-
To look at only non-zero stages, use --unmerged flag:
+stages.
+
To look at only non-zero stages, use --unmerged flag:
$ git ls-files --unmerged
@@ -1498,10 +1546,10 @@ stages.
100644 06fa6a24256dc7e560efa5687fa84b51f0263c3a 2 hello
100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello
-
The next step of merging is to merge these three versions of the
+
The next step of merging is to merge these three versions of the
file, using 3-way merge. This is done by giving
-git-merge-one-file command as one of the arguments to
-git-merge-index command:
+
git-merge-one-file command as one of the arguments to
+
git-merge-index command:
$ git merge-index git-merge-one-file hello
@@ -1510,15 +1558,15 @@ merge: warning: conflicts during merge
ERROR: Merge conflict in hello.
fatal: merge program failed
-
git-merge-one-file script is called with parameters to
+
git-merge-one-file script is called with parameters to
describe those three versions, and is responsible to leave the
merge results in the working tree.
It is a fairly straightforward shell script, and
-eventually calls merge program from RCS suite to perform a
-file-level 3-way merge. In this case, merge detects
+eventually calls merge program from RCS suite to perform a
+file-level 3-way merge. In this case, merge detects
conflicts, and the merge result with conflict marks is left in
the working tree.. This can be seen if you run ls-files
---stage again at this point:
+--stage again at this point:
$ git ls-files --stage
@@ -1527,18 +1575,18 @@ the working tree.. This can be seen if you run ls-files
100644 06fa6a24256dc7e560efa5687fa84b51f0263c3a 2 hello
100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello
-
This is the state of the index file and the working file after
-git-merge returns control back to you, leaving the conflicting
+
This is the state of the index file and the working file after
+git-merge returns control back to you, leaving the conflicting
merge for you to resolve. Notice that the path hello is still
-unmerged, and what you see with git-diff at this point is
-differences since stage 2 (i.e. your version).
+unmerged, and what you see with
git-diff at this point is
+differences since stage 2 (i.e. your version).
-Publishing your work
+Publishing your work
-
So, we can use somebody else's work from a remote repository, but
+
So, we can use somebody else's work from a remote repository, but
how can you prepare a repository to let other people pull from
-it?
-
You do your real work in your working tree that has your
+it?
+
You do your real work in your working tree that has your
primary repository hanging under it as its .git subdirectory.
You could make that repository accessible remotely and ask
people to pull from it, but in practice that is not the way
@@ -1546,7 +1594,7 @@ things are usually done. A recommended way is to have a public
repository, make it reachable by other people, and when the
changes you made in your primary working tree are in good shape,
update the public repository from it. This is often called
-pushing .
+
pushing .
@@ -1556,46 +1604,46 @@ update the public repository from it. This is often called
how git repositories at kernel.org are managed.
-
Publishing the changes from your local (private) repository to
+
Publishing the changes from your local (private) repository to
your remote (public) repository requires a write privilege on
the remote machine. You need to have an SSH account there to
-run a single command, git-receive-pack .
-
First, you need to create an empty repository on the remote
+run a single command, git-receive-pack .
+
First, you need to create an empty repository on the remote
machine that will house your public repository. This empty
repository will be populated and be kept up-to-date by pushing
into it later. Obviously, this repository creation needs to be
-done only once.
+done only once.
Note
-git-push uses a pair of programs,
-git-send-pack on your local machine, and git-receive-pack
+git-push uses a pair of programs,
+git-send-pack on your local machine, and git-receive-pack
on the remote machine. The communication between the two over
the network internally uses an SSH connection.
-
Your private repository's git directory is usually .git , but
+
Your private repository's git directory is usually .git , but
your public repository is often named after the project name,
i.e. <project>.git . Let's create such a public repository for
project my-git . After logging into the remote machine, create
-an empty directory:
+an empty directory:
-
Then, make that directory into a git repository by running
-git init , but this time, since its name is not the usual
-.git , we do things slightly differently:
+
Then, make that directory into a git repository by running
+git-init , but this time, since its name is not the usual
+.git , we do things slightly differently:
$ GIT_DIR=my-git.git git init
-
Make sure this directory is available for others you want your
+
Make sure this directory is available for others you want your
changes to be pulled by via the transport of your choice. Also
-you need to make sure that you have the git-receive-pack
-program on the $PATH .
+you need to make sure that you have the
git-receive-pack
+program on the
$PATH .
@@ -1603,9 +1651,9 @@ program on the $PATH .
Many installations of sshd do not invoke your shell as the login
shell when you directly run programs; what this means is that if
-your login shell is bash , only .bashrc is read and not
+your login shell is bash , only .bashrc is read and not
.bash_profile . As a workaround, make sure .bashrc sets up
-$PATH so that you can run git-receive-pack program.
+$PATH so that you can run git-receive-pack program.
@@ -1619,41 +1667,41 @@ point. This makes sure that every time you push into this
repository, git update-server-info is run.
-
Your "public repository" is now ready to accept your changes.
+
Your "public repository" is now ready to accept your changes.
Come back to the machine you have your private repository. From
-there, run this command:
+there, run this command:
$ git push <public-host>:/path/to/my-git.git master
-
This synchronizes your public repository to match the named
+
This synchronizes your public repository to match the named
branch head (i.e. master in this case) and objects reachable
-from them in your current repository.
-
As a real example, this is how I update my public git
+from them in your current repository.
+
As a real example, this is how I update my public git
repository. Kernel.org mirror network takes care of the
-propagation to other publicly visible machines:
+propagation to other publicly visible machines:
$ git push master.kernel.org:/pub/scm/git/git.git/
-Packing your repository
+Packing your repository
-
Earlier, we saw that one file under .git/objects/??/ directory
+
Earlier, we saw that one file under .git/objects/??/ directory
is stored for each git object you create. This representation
is efficient to create atomically and safely, but
not so convenient to transport over the network. Since git objects are
immutable once they are created, there is a way to optimize the
-storage by "packing them together". The command
+storage by "packing them together". The command
-
will do it for you. If you followed the tutorial examples, you
+
will do it for you. If you followed the tutorial examples, you
would have accumulated about 17 objects in .git/objects/??/
-directories by now. git repack tells you how many objects it
+directories by now. git-repack tells you how many objects it
packed, and stores the packed file in .git/objects/pack
-directory.
+directory.
@@ -1668,20 +1716,20 @@ in the pack, and the latter holds the index for random
access.
-
If you are paranoid, running git-verify-pack command would
+
If you are paranoid, running git-verify-pack command would
detect if you have a corrupt pack, but do not worry too much.
-Our programs are always perfect ;-).
-
Once you have packed objects, you do not need to leave the
-unpacked objects that are contained in the pack file anymore.
+Our programs are always perfect ;-).
+
Once you have packed objects, you do not need to leave the
+unpacked objects that are contained in the pack file anymore.
-
would remove them for you.
-
You can try running find .git/objects -type f before and after
+
would remove them for you.
+
You can try running find .git/objects -type f before and after
you run git prune-packed if you are curious. Also git
count-objects would tell you how many unpacked objects are in
-your repository and how much space they are consuming.
+your repository and how much space they are consuming.
@@ -1694,34 +1742,34 @@ public repository you might want to repack & prune often, or
never.
-
If you run git repack again at this point, it will say
+
If you run git repack again at this point, it will say
"Nothing to pack". Once you continue your development and
accumulate the changes, running git repack again will create a
new pack, that contains objects created since you packed your
repository the last time. We recommend that you pack your project
soon after the initial import (unless you are starting your
project from scratch), and then run git repack every once in a
-while, depending on how active your project is.
-
When a repository is synchronized via git push and git pull
+while, depending on how active your project is.
+
When a repository is synchronized via git push and git pull
objects packed in the source repository are usually stored
unpacked in the destination, unless rsync transport is used.
While this allows you to use different packing strategies on
both ends, it also means you may need to repack both
-repositories every once in a while.
+repositories every once in a while.
-Working with Others
+Working with Others
-
Although git is a truly distributed system, it is often
+
Although git is a truly distributed system, it is often
convenient to organize your project with an informal hierarchy
of developers. Linux kernel development is run this way. There
is a nice illustration (page 17, "Merges to Mainline") in
-Randy Dunlap's presentation .
-
It should be stressed that this hierarchy is purely informal .
+Randy Dunlap's presentation .
+
It should be stressed that this hierarchy is purely informal .
There is nothing fundamental in git that enforces the "chain of
patch flow" this hierarchy implies. You do not have to pull
-from only one remote repository.
-
A recommended workflow for a "project lead" goes like this:
-
+from only one remote repository.
+
A recommended workflow for a "project lead" goes like this:
+
Prepare your primary repository on your local machine. Your
@@ -1732,14 +1780,14 @@ Prepare your primary repository on your local machine. Your
Prepare a public repository accessible to others.
-If other people are pulling from your repository over dumb
+
If other people are pulling from your repository over dumb
transport protocols (HTTP), you need to keep this repository
dumb transport friendly . After git init ,
$GIT_DIR/hooks/post-update copied from the standard templates
-would contain a call to git-update-server-info but the
+would contain a call to git-update-server-info but the
post-update hook itself is disabled by default — enable it
-with chmod +x post-update . This makes sure git-update-server-info
-keeps the necessary files up-to-date.
+with
chmod +x post-update . This makes sure
git-update-server-info
+keeps the necessary files up-to-date.
@@ -1749,9 +1797,9 @@ Push into the public repository from your primary
-git-repack the public repository. This establishes a big
+git-repack the public repository. This establishes a big
pack that contains the initial set of objects as the
- baseline, and possibly git-prune if the transport
+ baseline, and possibly git-prune if the transport
used for pulling from your repository supports packed
repositories.
@@ -1763,7 +1811,7 @@ Keep working in your primary repository. Your changes
e-mails, and merges resulting from pulling the "public"
repositories of your "subsystem maintainers".
-You can repack this private repository whenever you feel like.
+You can repack this private repository whenever you feel like.
@@ -1777,13 +1825,13 @@ Every once in a while, "git-repack" the public repository.
Go back to step 5. and continue working.
-
-
A recommended work cycle for a "subsystem maintainer" who works
-on that project and has an own "public repository" goes like this:
-
+
+
A recommended work cycle for a "subsystem maintainer" who works
+on that project and has an own "public repository" goes like this:
+
-Prepare your work repository, by git-clone the public
+Prepare your work repository, by git-clone the public
repository of the "project lead". The URL used for the
initial cloning is stored in the remote.origin.url
configuration variable.
@@ -1807,7 +1855,7 @@ Copy over the packed files from "project lead" public
Push into the public repository from your primary
- repository. Run git-repack , and possibly git-prune if the
+ repository. Run git-repack , and possibly git-prune if the
transport used for pulling from your repository supports
packed repositories.
@@ -1820,8 +1868,8 @@ Keep working in your primary repository. Your changes
repositories of your "project lead" and possibly your
"sub-subsystem maintainers".
-You can repack this private repository whenever you feel
-like.
+You can repack this private repository whenever you feel
+like.
@@ -1832,18 +1880,18 @@ Push your changes to your public repository, and ask your
-Every once in a while, git-repack the public repository.
+Every once in a while, git-repack the public repository.
Go back to step 5. and continue working.
-
-
A recommended work cycle for an "individual developer" who does
+
+
A recommended work cycle for an "individual developer" who does
not have a "public" repository is somewhat different. It goes
-like this:
-
+like this:
+
-Prepare your work repository, by git-clone the public
+Prepare your work repository, by git-clone the public
repository of the "project lead" (or a "subsystem
maintainer", if you work on a subsystem). The URL used for
the initial cloning is stored in the remote.origin.url
@@ -1877,27 +1925,27 @@ Use git format-patch origin to prepare patches for e-mail
step 2. and continue.
-
+
-Working with Others, Shared Repository Style
+Working with Others, Shared Repository Style
-
If you are coming from CVS background, the style of cooperation
+
If you are coming from CVS background, the style of cooperation
suggested in the previous section may be new to you. You do not
have to worry. git supports "shared public repository" style of
-cooperation you are probably more familiar with as well.
-
See gitcvs-migration(7) for the details.
+cooperation you are probably more familiar with as well.
+
-Bundling your work together
+Bundling your work together
-
It is likely that you will be working on more than one thing at
+
It is likely that you will be working on more than one thing at
a time. It is easy to manage those more-or-less independent tasks
-using branches with git.
-
We have already seen how branches work previously,
+using branches with git.
+
We have already seen how branches work previously,
with "fun and work" example using two branches. The idea is the
same if there are more than two branches. Let's say you started
out from "master" head, and have some new code in the "master"
branch, and two independent fixes in the "commit-fix" and
-"diff-fix" branches:
+"diff-fix" branches:
$ git show-branch
@@ -1911,15 +1959,15 @@ branch, and two independent fixes in the "commit-fix" and
* [master] Release candidate #1
++* [diff-fix~2] Pretty-print messages.
-
Both fixes are tested well, and at this point, you want to merge
+
Both fixes are tested well, and at this point, you want to merge
in both of them. You could merge in diff-fix first and then
-commit-fix next, like this:
+
commit-fix next, like this:
$ git merge -m "Merge fix in diff-fix" diff-fix
$ git merge -m "Merge fix in commit-fix" commit-fix
-
Which would result in:
+
$ git show-branch
@@ -1935,21 +1983,21 @@ $ git merge -m "Merge fix in commit-fix" commit-fix
* [master~2] Release candidate #1
++* [master~3] Pretty-print messages.
-
However, there is no particular reason to merge in one branch
+
However, there is no particular reason to merge in one branch
first and the other next, when what you have are a set of truly
independent changes (if the order mattered, then they are not
independent by definition). You could instead merge those two
branches into the current branch at once. First let's undo what
we just did and start over. We would want to get the master
-branch before these two merges by resetting it to master~2 :
+branch before these two merges by resetting it to
master~2 :
$ git reset --hard master~2
-
You can make sure git show-branch matches the state before
-those two git merge you just did. Then, instead of running
-two git merge commands in a row, you would merge these two
-branch heads (this is known as making an Octopus ):
+
You can make sure git show-branch matches the state before
+those two git-merge you just did. Then, instead of running
+two git-merge commands in a row, you would merge these two
+branch heads (this is known as making an Octopus ):
$ git merge commit-fix diff-fix
@@ -1965,7 +2013,7 @@ $ git show-branch
* [master~1] Release candidate #1
++* [master~2] Pretty-print messages.
-
Note that you should not do Octopus because you can. An octopus
+
Note that you should not do Octopus because you can. An octopus
is a valid thing to do and often makes it easier to view the
commit history if you are merging more than two independent
changes at the same time. However, if you have merge conflicts
@@ -1975,21 +2023,21 @@ those branches were not independent after all, and you should
merge two at a time, documenting how you resolved the conflicts,
and the reason why you preferred changes made in one side over
the other. Otherwise it would make the project history harder
-to follow, not easier.
+to follow, not easier.
-SEE ALSO
+SEE ALSO
-GIT
+GIT
-
Part of the git(1) suite.
+
diff --git a/gitcore-tutorial.txt b/gitcore-tutorial.txt
index 7d721c5b0..a2b92933f 100644
--- a/gitcore-tutorial.txt
+++ b/gitcore-tutorial.txt
@@ -42,9 +42,9 @@ one for a totally new project, or an existing working tree that you want
to import into git.
For our first example, we're going to start a totally new repository from
-scratch, with no pre-existing files, and we'll call it `git-tutorial`.
+scratch, with no pre-existing files, and we'll call it 'git-tutorial'.
To start up, create a subdirectory for it, change into that
-subdirectory, and initialize the git infrastructure with `git-init`:
+subdirectory, and initialize the git infrastructure with 'git-init':
------------------------------------------------
$ mkdir git-tutorial
@@ -61,7 +61,7 @@ Initialized empty Git repository in .git/
which is just git's way of saying that you haven't been doing anything
strange, and that it will have created a local `.git` directory setup for
your new project. You will now have a `.git` directory, and you can
-inspect that with `ls`. For your new empty project, it should show you
+inspect that with 'ls'. For your new empty project, it should show you
three entries, among other things:
- a file called `HEAD`, that has `ref: refs/heads/master` in it.
@@ -139,7 +139,7 @@ but to actually check in your hard work, you will have to go through two steps:
- commit that index file as an object.
The first step is trivial: when you want to tell git about any changes
-to your working tree, you use the `git-update-index` program. That
+to your working tree, you use the 'git-update-index' program. That
program normally just takes a list of filenames you want to update, but
to avoid trivial mistakes, it refuses to add new entries to the index
(or remove existing ones) unless you explicitly tell it that you're
@@ -173,14 +173,14 @@ and see two files:
which correspond with the objects with names of `557db...` and
`f24c7...` respectively.
-If you want to, you can use `git-cat-file` to look at those objects, but
+If you want to, you can use 'git-cat-file' to look at those objects, but
you'll have to use the object name, not the filename of the object:
----------------
$ git cat-file -t 557db03de997c86a4a028e1ebd3a1ceb225be238
----------------
-where the `-t` tells `git-cat-file` to tell you what the "type" of the
+where the `-t` tells 'git-cat-file' to tell you what the "type" of the
object is. git will tell you that you have a "blob" object (i.e., just a
regular file), and you can see the contents with
@@ -205,7 +205,7 @@ hexadecimal digits in most places.
Anyway, as we mentioned previously, you normally never actually take a
look at the objects themselves, and typing long 40-character hex
names is not something you'd normally want to do. The above digression
-was just to show that `git-update-index` did something magical, and
+was just to show that 'git-update-index' did something magical, and
actually saved away the contents of your files into the git object
database.
@@ -228,18 +228,18 @@ $ echo "It's a new day for git" >>hello
and you can now, since you told git about the previous state of `hello`, ask
git what has changed in the tree compared to your old index, using the
-`git-diff-files` command:
+'git-diff-files' command:
------------
$ git diff-files
------------
Oops. That wasn't very readable. It just spit out its own internal
-version of a `diff`, but that internal version really just tells you
+version of a 'diff', but that internal version really just tells you
that it has noticed that "hello" has been modified, and that the old object
contents it had have been replaced with something else.
-To make it readable, we can tell `git-diff-files` to output the
+To make it readable, we can tell 'git-diff-files' to output the
differences as a patch, using the `-p` flag:
------------
@@ -255,7 +255,7 @@ index 557db03..263414f 100644
i.e. the diff of the change we caused by adding another line to `hello`.
-In other words, `git-diff-files` always shows us the difference between
+In other words, 'git-diff-files' always shows us the difference between
what is recorded in the index, and what is currently in the working
tree. That's very useful.
@@ -283,7 +283,7 @@ that in two phases: creating a 'tree' object, and committing that 'tree'
object as a 'commit' object together with an explanation of what the
tree was all about, along with information of how we came to that state.
-Creating a tree object is trivial, and is done with `git-write-tree`.
+Creating a tree object is trivial, and is done with 'git-write-tree'.
There are no options or other input: `git write-tree` will take the
current index state, and write an object that describes that whole
index. In other words, we're now tying together all the different
@@ -307,23 +307,23 @@ is not a "blob" object, but a "tree" object (you can also use
`git cat-file` to actually output the raw object contents, but you'll see
mainly a binary mess, so that's less interesting).
-However -- normally you'd never use `git-write-tree` on its own, because
+However -- normally you'd never use 'git-write-tree' on its own, because
normally you always commit a tree into a commit object using the
-`git-commit-tree` command. In fact, it's easier to not actually use
-`git-write-tree` on its own at all, but to just pass its result in as an
-argument to `git-commit-tree`.
+'git-commit-tree' command. In fact, it's easier to not actually use
+'git-write-tree' on its own at all, but to just pass its result in as an
+argument to 'git-commit-tree'.
-`git-commit-tree` normally takes several arguments -- it wants to know
+'git-commit-tree' normally takes several arguments -- it wants to know
what the 'parent' of a commit was, but since this is the first commit
ever in this new repository, and it has no parents, we only need to pass in
-the object name of the tree. However, `git-commit-tree` also wants to get a
+the object name of the tree. However, 'git-commit-tree' also wants to get a
commit message on its standard input, and it will write out the resulting
object name for the commit to its standard output.
And this is where we create the `.git/refs/heads/master` file
which is pointed at by `HEAD`. This file is supposed to contain
the reference to the top-of-tree of the master branch, and since
-that's exactly what `git-commit-tree` spits out, we can do this
+that's exactly what 'git-commit-tree' spits out, we can do this
all with a sequence of simple shell commands:
------------------------------------------------
@@ -345,11 +345,11 @@ instead, and it would have done the above magic scripting for you.
Making a change
---------------
-Remember how we did the `git-update-index` on file `hello` and then we
+Remember how we did the 'git-update-index' on file `hello` and then we
changed `hello` afterward, and could compare the new state of `hello` with the
state we saved in the index file?
-Further, remember how I said that `git-write-tree` writes the contents
+Further, remember how I said that 'git-write-tree' writes the contents
of the *index* file to the tree, and thus what we just committed was in
fact the *original* contents of the file `hello`, not the new ones. We did
that on purpose, to show the difference between the index state, and the
@@ -360,12 +360,12 @@ As before, if we do `git diff-files -p` in our git-tutorial project,
we'll still see the same difference we saw last time: the index file
hasn't changed by the act of committing anything. However, now that we
have committed something, we can also learn to use a new command:
-`git-diff-index`.
+'git-diff-index'.
-Unlike `git-diff-files`, which showed the difference between the index
-file and the working tree, `git-diff-index` shows the differences
+Unlike 'git-diff-files', which showed the difference between the index
+file and the working tree, 'git-diff-index' shows the differences
between a committed *tree* and either the index file or the working
-tree. In other words, `git-diff-index` wants a tree to be diffed
+tree. In other words, 'git-diff-index' wants a tree to be diffed
against, and before we did the commit, we couldn't do that, because we
didn't have anything to diff against.
@@ -375,7 +375,7 @@ But now we can do
$ git diff-index -p HEAD
----------------
-(where `-p` has the same meaning as it did in `git-diff-files`), and it
+(where `-p` has the same meaning as it did in 'git-diff-files'), and it
will show us the same difference, but for a totally different reason.
Now we're comparing the working tree not against the index file,
but against the tree we just wrote. It just so happens that those two
@@ -390,7 +390,7 @@ $ git diff HEAD
which ends up doing the above for you.
-In other words, `git-diff-index` normally compares a tree against the
+In other words, 'git-diff-index' normally compares a tree against the
working tree, but when given the `\--cached` flag, it is told to
instead compare against just the index cache contents, and ignore the
current working tree state entirely. Since we just wrote the index
@@ -399,7 +399,7 @@ an empty set of differences, and that's exactly what it does.
[NOTE]
================
-`git-diff-index` really always uses the index for its
+'git-diff-index' really always uses the index for its
comparisons, and saying that it compares a tree against the working
tree is thus not strictly accurate. In particular, the list of
files to compare (the "meta-data") *always* comes from the index file,
@@ -428,11 +428,11 @@ $ git update-index hello
(note how we didn't need the `\--add` flag this time, since git knew
about the file already).
-Note what happens to the different `git-diff-\*` versions here. After
+Note what happens to the different 'git-diff-\*' versions here. After
we've updated `hello` in the index, `git diff-files -p` now shows no
differences, but `git diff-index -p HEAD` still *does* show that the
current state is different from the state we committed. In fact, now
-`git-diff-index` shows the same difference whether we use the `--cached`
+'git-diff-index' shows the same difference whether we use the `--cached`
flag or not, since now the index is coherent with the working tree.
Now, since we've updated `hello` in the index, we can commit the new
@@ -460,7 +460,7 @@ You've now made your first real git commit. And if you're interested in
looking at what `git commit` really does, feel free to investigate:
it's a few very simple shell scripts to generate the helpful (?) commit
message headers, and a few one-liners that actually do the
-commit itself (`git-commit`).
+commit itself ('git-commit').
Inspecting Changes
@@ -468,9 +468,9 @@ Inspecting Changes
While creating changes is useful, it's even more useful if you can tell
later what changed. The most useful command for this is another of the
-`diff` family, namely `git-diff-tree`.
+'diff' family, namely 'git-diff-tree'.
-`git-diff-tree` can be given two arbitrary trees, and it will tell you the
+'git-diff-tree' can be given two arbitrary trees, and it will tell you the
differences between them. Perhaps even more commonly, though, you can
give it just a single commit object, and it will figure out the parent
of that commit itself, and show the difference directly. Thus, to get
@@ -518,15 +518,15 @@ various diff-\* commands compare things.
+-----------+
============
-More interestingly, you can also give `git-diff-tree` the `--pretty` flag,
+More interestingly, you can also give 'git-diff-tree' the `--pretty` flag,
which tells it to also show the commit message and author and date of the
commit, and you can tell it to show a whole series of diffs.
Alternatively, you can tell it to be "silent", and not show the diffs at
all, but just show the actual commit message.
-In fact, together with the `git-rev-list` program (which generates a
-list of revisions), `git-diff-tree` ends up being a veritable fount of
-changes. A trivial (but very useful) script called `git-whatchanged` is
+In fact, together with the 'git-rev-list' program (which generates a
+list of revisions), 'git-diff-tree' ends up being a veritable fount of
+changes. A trivial (but very useful) script called 'git-whatchanged' is
included with git which does exactly this, and shows a log of recent
activities.
@@ -553,14 +553,14 @@ When using the above two commands, the initial commit will be shown.
If this is a problem because it is huge, you can hide it by setting
the log.showroot configuration variable to false. Having this, you
can still show it for each command just adding the `\--root` option,
-which is a flag for `git-diff-tree` accepted by both commands.
+which is a flag for 'git-diff-tree' accepted by both commands.
With that, you should now be having some inkling of what git does, and
can explore on your own.
[NOTE]
Most likely, you are not directly using the core
-git Plumbing commands, but using Porcelain such as `git-add`, `git-rm'
+git Plumbing commands, but using Porcelain such as 'git-add', `git-rm'
and `git-commit'.
@@ -595,7 +595,7 @@ pointer to the state you want to tag, but also a small tag name and
message, along with optionally a PGP signature that says that yes,
you really did
that tag. You create these annotated tags with either the `-a` or
-`-s` flag to `git tag`:
+`-s` flag to 'git-tag':
----------------
$ git tag -s
@@ -642,7 +642,7 @@ and it will be gone. There's no external repository, and there's no
history outside the project you created.
- if you want to move or duplicate a git repository, you can do so. There
- is `git clone` command, but if all you want to do is just to
+ is 'git-clone' command, but if all you want to do is just to
create a copy of your repository (with all the full history that
went along with it), you can do so with a regular
`cp -a git-tutorial new-git-tutorial`.
@@ -660,13 +660,13 @@ in the new repository to make sure that the index file is up-to-date.
Note that the second point is true even across machines. You can
duplicate a remote git repository with *any* regular copy mechanism, be it
-`scp`, `rsync` or `wget`.
+'scp', 'rsync' or 'wget'.
When copying a remote repository, you'll want to at a minimum update the
index cache when you do this, and especially with other peoples'
repositories you often want to make sure that the index cache is in some
known state (you don't know *what* they've done and not yet checked in),
-so usually you'll precede the `git-update-index` with a
+so usually you'll precede the 'git-update-index' with a
----------------
$ git read-tree --reset HEAD
@@ -674,7 +674,7 @@ $ git update-index --refresh
----------------
which will force a total index re-build from the tree pointed to by `HEAD`.
-It resets the index contents to `HEAD`, and then the `git-update-index`
+It resets the index contents to `HEAD`, and then the 'git-update-index'
makes sure to match up all index entries with the checked-out files.
If the original repository had uncommitted changes in its
working tree, `git update-index --refresh` notices them and
@@ -689,8 +689,8 @@ $ git reset
and in fact a lot of the common git command combinations can be scripted
with the `git xyz` interfaces. You can learn things by just looking
at what the various git scripts do. For example, `git reset` used to be
-the above two lines implemented in `git-reset`, but some things like
-`git-status` and `git-commit` are slightly more complex scripts around
+the above two lines implemented in 'git-reset', but some things like
+'git-status' and 'git-commit' are slightly more complex scripts around
the basic git commands.
Many (most?) public remote repositories will not contain any of
@@ -729,7 +729,7 @@ where the `-u` flag means that you want the checkout to keep the index
up-to-date (so that you don't have to refresh it afterward), and the
`-a` flag means "check out all files" (if you have a stale copy or an
older version of a checked out tree you may also need to add the `-f`
-flag first, to tell `git-checkout-index` to *force* overwriting of any old
+flag first, to tell 'git-checkout-index' to *force* overwriting of any old
files).
Again, this can all be simplified with
@@ -776,7 +776,7 @@ to it.
================================================
If you make the decision to start your new branch at some
other point in the history than the current `HEAD`, you can do so by
-just telling `git checkout` what the base of the checkout would be.
+just telling 'git-checkout' what the base of the checkout would be.
In other words, if you have an earlier tag or branch, you'd just do
------------
@@ -819,7 +819,7 @@ $ git branch [startingpoint]
which will simply _create_ the branch, but will not do anything further.
You can then later -- once you decide that you want to actually develop
-on that branch -- switch to that branch with a regular `git checkout`
+on that branch -- switch to that branch with a regular 'git-checkout'
with the branchname as the argument.
@@ -878,10 +878,10 @@ means: normally it will just show you your current `HEAD`) and their
histories. You can also see exactly how they came to be from a common
source.
-Anyway, let's exit `gitk` (`^Q` or the File menu), and decide that we want
+Anyway, let's exit 'gitk' (`^Q` or the File menu), and decide that we want
to merge the work we did on the `mybranch` branch into the `master`
branch (which is currently our `HEAD` too). To do that, there's a nice
-script called `git merge`, which wants to know which branches you want
+script called 'git-merge', which wants to know which branches you want
to resolve and what the merge is all about:
------------
@@ -925,7 +925,7 @@ $ git commit -i hello
which will very loudly warn you that you're now committing a merge
(which is correct, so never mind), and you can write a small merge
-message about your adventures in `git-merge`-land.
+message about your adventures in 'git-merge'-land.
After you're done, start up `gitk \--all` to see graphically what the
history looks like. Notice that `mybranch` still exists, and you can
@@ -967,21 +967,21 @@ branch head. Please see linkgit:git-rev-parse[1] if you want to
see more complex cases.
[NOTE]
-Without the '--more=1' option, `git-show-branch` would not output the
+Without the '--more=1' option, 'git-show-branch' would not output the
'[master^]' commit, as '[mybranch]' commit is a common ancestor of
both 'master' and 'mybranch' tips. Please see linkgit:git-show-branch[1]
for details.
[NOTE]
If there were more commits on the 'master' branch after the merge, the
-merge commit itself would not be shown by `git-show-branch` by
+merge commit itself would not be shown by 'git-show-branch' by
default. You would need to provide '--sparse' option to make the
merge commit visible in this case.
Now, let's pretend you are the one who did all the work in
`mybranch`, and the fruit of your hard work has finally been merged
to the `master` branch. Let's go back to `mybranch`, and run
-`git-merge` to get the "upstream changes" back to your branch.
+'git-merge' to get the "upstream changes" back to your branch.
------------
$ git checkout mybranch
@@ -1006,7 +1006,7 @@ the tree of your branch to that of the `master` branch. This is
often called 'fast forward' merge.
You can run `gitk \--all` again to see how the commit ancestry
-looks like, or run `show-branch`, which tells you this.
+looks like, or run 'show-branch', which tells you this.
------------------------------------------------
$ git show-branch master mybranch
@@ -1023,12 +1023,12 @@ Merging external work
It's usually much more common that you merge with somebody else than
merging with your own branches, so it's worth pointing out that git
makes that very easy too, and in fact, it's not that different from
-doing a `git merge`. In fact, a remote merge ends up being nothing
+doing a 'git-merge'. In fact, a remote merge ends up being nothing
more than "fetch the work from a remote repository into a temporary tag"
-followed by a `git merge`.
+followed by a 'git-merge'.
Fetching from a remote repository is done by, unsurprisingly,
-`git fetch`:
+'git-fetch':
----------------
$ git fetch
@@ -1066,9 +1066,9 @@ most efficient way to exchange git objects between repositories.
Local directory::
`/path/to/repo.git/`
+
-This transport is the same as SSH transport but uses `sh` to run
+This transport is the same as SSH transport but uses 'sh' to run
both ends on the local machine instead of running other end on
-the remote machine via `ssh`.
+the remote machine via 'ssh'.
git Native::
`git://remote.machine/path/to/repo.git/`
@@ -1095,7 +1095,7 @@ The 'commit walkers' are sometimes also called 'dumb
transports', because they do not require any git aware smart
server like git Native transport does. Any stock HTTP server
that does not even support directory index would suffice. But
-you must prepare your repository with `git-update-server-info`
+you must prepare your repository with 'git-update-server-info'
to help dumb transport downloaders.
Once you fetch from the remote repository, you `merge` that
@@ -1115,7 +1115,7 @@ argument.
[NOTE]
You could do without using any branches at all, by
keeping as many local repositories as you would like to have
-branches, and merging between them with `git pull`, just like
+branches, and merging between them with 'git-pull', just like
you merge between branches. The advantage of this approach is
that it lets you keep a set of files for each `branch` checked
out and you may find it easier to switch back and forth if you
@@ -1132,7 +1132,7 @@ like this:
$ git config remote.linus.url http://www.kernel.org/pub/scm/git/git.git/
------------------------------------------------
-and use the "linus" keyword with `git pull` instead of the full URL.
+and use the "linus" keyword with 'git-pull' instead of the full URL.
Examples.
@@ -1168,7 +1168,7 @@ $ git show-branch --more=2 master mybranch
+* [master^] Some fun.
------------
-Remember, before running `git merge`, our `master` head was at
+Remember, before running 'git-merge', our `master` head was at
"Some fun." commit, while our `mybranch` head was at "Some
work." commit.
@@ -1195,7 +1195,7 @@ Now we are ready to experiment with the merge by hand.
`git merge` command, when merging two branches, uses 3-way merge
algorithm. First, it finds the common ancestor between them.
-The command it uses is `git-merge-base`:
+The command it uses is 'git-merge-base':
------------
$ mb=$(git merge-base HEAD mybranch)
@@ -1219,7 +1219,7 @@ this:
$ git read-tree -m -u $mb HEAD mybranch
------------
-This is the same `git-read-tree` command we have already seen,
+This is the same 'git-read-tree' command we have already seen,
but it takes three trees, unlike previous examples. This reads
the contents of each tree into different 'stage' in the index
file (the first tree goes to stage 1, the second to stage 2,
@@ -1260,8 +1260,8 @@ $ git ls-files --unmerged
The next step of merging is to merge these three versions of the
file, using 3-way merge. This is done by giving
-`git-merge-one-file` command as one of the arguments to
-`git-merge-index` command:
+'git-merge-one-file' command as one of the arguments to
+'git-merge-index' command:
------------
$ git merge-index git-merge-one-file hello
@@ -1271,12 +1271,12 @@ ERROR: Merge conflict in hello.
fatal: merge program failed
------------
-`git-merge-one-file` script is called with parameters to
+'git-merge-one-file' script is called with parameters to
describe those three versions, and is responsible to leave the
merge results in the working tree.
It is a fairly straightforward shell script, and
-eventually calls `merge` program from RCS suite to perform a
-file-level 3-way merge. In this case, `merge` detects
+eventually calls 'merge' program from RCS suite to perform a
+file-level 3-way merge. In this case, 'merge' detects
conflicts, and the merge result with conflict marks is left in
the working tree.. This can be seen if you run `ls-files
--stage` again at this point:
@@ -1290,9 +1290,9 @@ $ git ls-files --stage
------------
This is the state of the index file and the working file after
-`git-merge` returns control back to you, leaving the conflicting
+'git-merge' returns control back to you, leaving the conflicting
merge for you to resolve. Notice that the path `hello` is still
-unmerged, and what you see with `git-diff` at this point is
+unmerged, and what you see with 'git-diff' at this point is
differences since stage 2 (i.e. your version).
@@ -1320,7 +1320,7 @@ how git repositories at `kernel.org` are managed.
Publishing the changes from your local (private) repository to
your remote (public) repository requires a write privilege on
the remote machine. You need to have an SSH account there to
-run a single command, `git-receive-pack`.
+run a single command, 'git-receive-pack'.
First, you need to create an empty repository on the remote
machine that will house your public repository. This empty
@@ -1329,8 +1329,8 @@ into it later. Obviously, this repository creation needs to be
done only once.
[NOTE]
-`git-push` uses a pair of programs,
-`git-send-pack` on your local machine, and `git-receive-pack`
+'git-push' uses a pair of programs,
+'git-send-pack' on your local machine, and 'git-receive-pack'
on the remote machine. The communication between the two over
the network internally uses an SSH connection.
@@ -1345,7 +1345,7 @@ $ mkdir my-git.git
------------
Then, make that directory into a git repository by running
-`git init`, but this time, since its name is not the usual
+'git-init', but this time, since its name is not the usual
`.git`, we do things slightly differently:
------------
@@ -1354,15 +1354,15 @@ $ GIT_DIR=my-git.git git init
Make sure this directory is available for others you want your
changes to be pulled by via the transport of your choice. Also
-you need to make sure that you have the `git-receive-pack`
+you need to make sure that you have the 'git-receive-pack'
program on the `$PATH`.
[NOTE]
Many installations of sshd do not invoke your shell as the login
shell when you directly run programs; what this means is that if
-your login shell is `bash`, only `.bashrc` is read and not
+your login shell is 'bash', only `.bashrc` is read and not
`.bash_profile`. As a workaround, make sure `.bashrc` sets up
-`$PATH` so that you can run `git-receive-pack` program.
+`$PATH` so that you can run 'git-receive-pack' program.
[NOTE]
If you plan to publish this repository to be accessed over http,
@@ -1407,7 +1407,7 @@ $ git repack
will do it for you. If you followed the tutorial examples, you
would have accumulated about 17 objects in `.git/objects/??/`
-directories by now. `git repack` tells you how many objects it
+directories by now. 'git-repack' tells you how many objects it
packed, and stores the packed file in `.git/objects/pack`
directory.
@@ -1420,7 +1420,7 @@ them together. The former holds all the data from the objects
in the pack, and the latter holds the index for random
access.
-If you are paranoid, running `git-verify-pack` command would
+If you are paranoid, running 'git-verify-pack' command would
detect if you have a corrupt pack, but do not worry too much.
Our programs are always perfect ;-).
@@ -1487,17 +1487,17 @@ If other people are pulling from your repository over dumb
transport protocols (HTTP), you need to keep this repository
'dumb transport friendly'. After `git init`,
`$GIT_DIR/hooks/post-update` copied from the standard templates
-would contain a call to `git-update-server-info` but the
+would contain a call to 'git-update-server-info' but the
`post-update` hook itself is disabled by default -- enable it
-with `chmod +x post-update`. This makes sure `git-update-server-info`
+with `chmod +x post-update`. This makes sure 'git-update-server-info'
keeps the necessary files up-to-date.
3. Push into the public repository from your primary
repository.
-4. `git-repack` the public repository. This establishes a big
+4. 'git-repack' the public repository. This establishes a big
pack that contains the initial set of objects as the
- baseline, and possibly `git-prune` if the transport
+ baseline, and possibly 'git-prune' if the transport
used for pulling from your repository supports packed
repositories.
@@ -1518,7 +1518,7 @@ You can repack this private repository whenever you feel like.
A recommended work cycle for a "subsystem maintainer" who works
on that project and has an own "public repository" goes like this:
-1. Prepare your work repository, by `git-clone` the public
+1. Prepare your work repository, by 'git-clone' the public
repository of the "project lead". The URL used for the
initial cloning is stored in the remote.origin.url
configuration variable.
@@ -1533,7 +1533,7 @@ on that project and has an own "public repository" goes like this:
point at the repository you are borrowing from.
4. Push into the public repository from your primary
- repository. Run `git-repack`, and possibly `git-prune` if the
+ repository. Run 'git-repack', and possibly 'git-prune' if the
transport used for pulling from your repository supports
packed repositories.
@@ -1550,7 +1550,7 @@ like.
"project lead" and possibly your "sub-subsystem
maintainers" to pull from it.
-7. Every once in a while, `git-repack` the public repository.
+7. Every once in a while, 'git-repack' the public repository.
Go back to step 5. and continue working.
@@ -1558,7 +1558,7 @@ A recommended work cycle for an "individual developer" who does
not have a "public" repository is somewhat different. It goes
like this:
-1. Prepare your work repository, by `git-clone` the public
+1. Prepare your work repository, by 'git-clone' the public
repository of the "project lead" (or a "subsystem
maintainer", if you work on a subsystem). The URL used for
the initial cloning is stored in the remote.origin.url
@@ -1655,9 +1655,9 @@ branch before these two merges by resetting it to 'master~2':
$ git reset --hard master~2
------------
-You can make sure 'git show-branch' matches the state before
-those two 'git merge' you just did. Then, instead of running
-two 'git merge' commands in a row, you would merge these two
+You can make sure `git show-branch` matches the state before
+those two 'git-merge' you just did. Then, instead of running
+two 'git-merge' commands in a row, you would merge these two
branch heads (this is known as 'making an Octopus'):
------------
diff --git a/gitcvs-migration.html b/gitcvs-migration.html
index 7c914eb0e..758fe9305 100644
--- a/gitcvs-migration.html
+++ b/gitcvs-migration.html
@@ -3,7 +3,7 @@
-
+
gitcvs-migration(7)
@@ -272,81 +320,81 @@ gitcvs-migration(7) Manual Page
SYNOPSIS
-DESCRIPTION
+DESCRIPTION
-
Git differs from CVS in that every working tree contains a repository with
+
Git differs from CVS in that every working tree contains a repository with
a full copy of the project history, and no repository is inherently more
important than any other. However, you can emulate the CVS model by
designating a single shared repository which people can synchronize with;
-this document explains how to do that.
-
Some basic familiarity with git is required. Having gone through
+this document explains how to do that.
+
-Developing against a shared repository
+Developing against a shared repository
-
Suppose a shared repository is set up in /pub/repo.git on the host
+
Suppose a shared repository is set up in /pub/repo.git on the host
foo.com. Then as an individual committer you can clone the shared
-repository over ssh with:
+repository over ssh with:
$ git clone foo.com:/pub/repo.git/ my-project
$ cd my-project
-
and hack away. The equivalent of cvs update is
+
and hack away. The equivalent of cvs update is
-
which merges in any work that others might have done since the clone
+
which merges in any work that others might have done since the clone
operation. If there are uncommitted changes in your working tree, commit
-them first before running git pull.
+them first before running git pull.
Note
-The pull command knows where to get updates from because of certain
-configuration variables that were set by the first git-clone
+
The pull command knows where to get updates from because of certain
+configuration variables that were set by the first git-clone
command; see git config -l and the git-config(1) man
-page for details.
+page for details.
-
You can update the shared repository with your changes by first committing
-your changes, and then using the git-push command:
+
You can update the shared repository with your changes by first committing
+your changes, and then using the git-push command:
-
to "push" those commits to the shared repository. If someone else has
-updated the repository more recently, git-push , like cvs commit , will
+
to "push" those commits to the shared repository. If someone else has
+updated the repository more recently, git-push , like cvs commit , will
complain, in which case you must pull any changes before attempting the
-push again.
-
In the git-push command above we specify the name of the remote branch
-to update (master ). If we leave that out, git-push tries to update
+push again.
+
In the git-push command above we specify the name of the remote branch
+to update (master ). If we leave that out, git-push tries to update
any branches in the remote repository that have the same name as a branch
-in the local repository. So the last push can be done with either of:
+in the local repository. So the last
push can be done with either of:
$ git push origin
$ git push foo.com:/pub/project.git/
-
as long as the shared repository does not have any branches
-other than master .
+
as long as the shared repository does not have any branches
+other than master .
-Setting Up a Shared Repository
+Setting Up a Shared Repository
-
We assume you have already created a git repository for your project,
+
We assume you have already created a git repository for your project,
possibly created from scratch or from a tarball (see
gittutorial(7) ), or imported from an already existing CVS
-repository (see the next section).
-
Assume your existing repo is at /home/alice/myproject. Create a new "bare"
+repository (see the next section).
+
Assume your existing repo is at /home/alice/myproject. Create a new "bare"
repository (a repository without a working tree) and fetch your project into
-it:
+it:
$ mkdir /pub/my-repo.git
@@ -354,95 +402,99 @@ $ cd /pub/my-repo.git
$ git --bare init --shared
$ git --bare fetch /home/alice/myproject master:master
-
Next, give every team member read/write access to this repository. One
+
Next, give every team member read/write access to this repository. One
easy way to do this is to give all the team members ssh access to the
machine where the repository is hosted. If you don't want to give them a
full shell on the machine, there is a restricted shell which only allows
-users to do git pushes and pulls; see git-shell(1) .
-
Put all the committers in the same group, and make the repository
-writable by that group:
+users to do git pushes and pulls; see
git-shell(1) .
+
Put all the committers in the same group, and make the repository
+writable by that group:
$ chgrp -R $group /pub/my-repo.git
-
Make sure committers have a umask of at most 027, so that the directories
-they create are writable and searchable by other group members.
+
Make sure committers have a umask of at most 027, so that the directories
+they create are writable and searchable by other group members.
-Importing a CVS archive
+Importing a CVS archive
-
First, install version 2.1 or higher of cvsps from
+
First, install version 2.1 or higher of cvsps from
http://www.cobite.com/cvsps/ and make
sure it is in your path. Then cd to a checked out CVS working directory
-of the project you are interested in and run git-cvsimport :
+of the project you are interested in and run
git-cvsimport :
$ git cvsimport -C <destination> <module>
-
This puts a git archive of the named CVS module in the directory
-<destination>, which will be created if necessary.
-
The import checks out from CVS every revision of every file. Reportedly
+
This puts a git archive of the named CVS module in the directory
+<destination>, which will be created if necessary.
+
The import checks out from CVS every revision of every file. Reportedly
cvsimport can average some twenty revisions per second, so for a
medium-sized project this should not take more than a couple of minutes.
-Larger projects or remote repositories may take longer.
-
The main trunk is stored in the git branch named origin , and additional
+Larger projects or remote repositories may take longer.
+
The main trunk is stored in the git branch named origin , and additional
CVS branches are stored in git branches with the same names. The most
recent version of the main trunk is also left checked out on the master
-branch, so you can start adding your own changes right away.
-
The import is incremental, so if you call it again next month it will
+branch, so you can start adding your own changes right away.
+
The import is incremental, so if you call it again next month it will
fetch any CVS updates that have been made in the meantime. For this to
work, you must not modify the imported branches; instead, create new
branches for your own changes, and merge in the imported branches as
-necessary.
+necessary.
+
If you want a shared repository, you will need to make a bare clone
+of the imported directory, as described above. Then treat the imported
+directory as another development clone for purposes of merging
+incremental imports.
-Advanced Shared Repository Management
+Advanced Shared Repository Management
-
Git allows you to specify scripts called "hooks" to be run at certain
+
Git allows you to specify scripts called "hooks" to be run at certain
points. You can use these, for example, to send all commits to the shared
-repository to a mailing list. See githooks(5) .
-
You can enforce finer grained permissions using update hooks. See
+repository to a mailing list. See githooks(5) .
+
-Providing CVS Access to a git Repository
+Providing CVS Access to a git Repository
-
It is also possible to provide true CVS access to a git repository, so
+
It is also possible to provide true CVS access to a git repository, so
that developers can still use CVS; see git-cvsserver(1) for
-details.
+details.
-Alternative Development Models
+Alternative Development Models
-
CVS users are accustomed to giving a group of developers commit access to
+
CVS users are accustomed to giving a group of developers commit access to
a common repository. As we've seen, this is also possible with git.
However, the distributed nature of git allows other development models,
and you may want to first consider whether one of them might be a better
-fit for your project.
-
For example, you can choose a single person to maintain the project's
+fit for your project.
+
For example, you can choose a single person to maintain the project's
primary public repository. Other developers then clone this repository
and each work in their own clone. When they have a series of changes that
they're happy with, they ask the maintainer to pull from the branch
containing the changes. The maintainer reviews their changes and pulls
them into the primary repository, which other developers pull from as
necessary to stay coordinated. The Linux kernel and other projects use
-variants of this model.
-
With a small group, developers may just pull changes from each other's
-repositories without the need for a central maintainer.
+variants of this model.
+
With a small group, developers may just pull changes from each other's
+repositories without the need for a central maintainer.
-SEE ALSO
+SEE ALSO
-GIT
+GIT
-
Part of the git(1) suite.
+
diff --git a/gitcvs-migration.txt b/gitcvs-migration.txt
index 4dc7ec540..aaa7ef737 100644
--- a/gitcvs-migration.txt
+++ b/gitcvs-migration.txt
@@ -34,7 +34,7 @@ $ git clone foo.com:/pub/repo.git/ my-project
$ cd my-project
------------------------------------------------
-and hack away. The equivalent of `cvs update` is
+and hack away. The equivalent of 'cvs update' is
------------------------------------------------
$ git pull origin
@@ -46,28 +46,28 @@ them first before running git pull.
[NOTE]
================================
-The `pull` command knows where to get updates from because of certain
-configuration variables that were set by the first `git-clone`
+The 'pull' command knows where to get updates from because of certain
+configuration variables that were set by the first 'git-clone'
command; see `git config -l` and the linkgit:git-config[1] man
page for details.
================================
You can update the shared repository with your changes by first committing
-your changes, and then using the `git-push` command:
+your changes, and then using the 'git-push' command:
------------------------------------------------
$ git push origin master
------------------------------------------------
to "push" those commits to the shared repository. If someone else has
-updated the repository more recently, `git-push`, like `cvs commit`, will
+updated the repository more recently, 'git-push', like 'cvs commit', will
complain, in which case you must pull any changes before attempting the
push again.
-In the `git-push` command above we specify the name of the remote branch
-to update (`master`). If we leave that out, `git-push` tries to update
+In the 'git-push' command above we specify the name of the remote branch
+to update (`master`). If we leave that out, 'git-push' tries to update
any branches in the remote repository that have the same name as a branch
-in the local repository. So the last `push` can be done with either of:
+in the local repository. So the last 'push' can be done with either of:
------------
$ git push origin
@@ -118,7 +118,7 @@ Importing a CVS archive
First, install version 2.1 or higher of cvsps from
link:http://www.cobite.com/cvsps/[http://www.cobite.com/cvsps/] and make
sure it is in your path. Then cd to a checked out CVS working directory
-of the project you are interested in and run `git-cvsimport`:
+of the project you are interested in and run 'git-cvsimport':
-------------------------------------------
$ git cvsimport -C
@@ -143,6 +143,11 @@ work, you must not modify the imported branches; instead, create new
branches for your own changes, and merge in the imported branches as
necessary.
+If you want a shared repository, you will need to make a bare clone
+of the imported directory, as described above. Then treat the imported
+directory as another development clone for purposes of merging
+incremental imports.
+
Advanced Shared Repository Management
-------------------------------------
diff --git a/gitdiffcore.html b/gitdiffcore.html
index 600ba7d8a..798f42a39 100644
--- a/gitdiffcore.html
+++ b/gitdiffcore.html
@@ -3,7 +3,7 @@
-
+
gitdiffcore(7)
@@ -272,25 +320,25 @@ gitdiffcore(7) Manual Page
SYNOPSIS
-DESCRIPTION
+DESCRIPTION
-
The diff commands git-diff-index , git-diff-files , and git-diff-tree
+
The diff commands git-diff-index , git-diff-files , and git-diff-tree
can be told to manipulate differences they find in
-unconventional ways before showing diff output. The manipulation
+unconventional ways before showing diff output. The manipulation
is collectively called "diffcore transformation". This short note
-describes what they are and how to use them to produce diff outputs
-that are easier to understand than the conventional kind.
+describes what they are and how to use them to produce
diff output
+that is easier to understand than the conventional kind.
-The chain of operation
+The chain of operation
-
The git-diff-* family works by first comparing two sets of
-files:
-
+The git-diff-* family works by first comparing two sets of
+files:
+
-git-diff-index compares contents of a "tree" object and the
+git-diff-index compares contents of a "tree" object and the
working directory (when --cached flag is not used) or a
"tree" object and the index file (when --cached flag is
used);
@@ -298,21 +346,21 @@ files:
-git-diff-files compares contents of the index file and the
+git-diff-files compares contents of the index file and the
working directory;
-git-diff-tree compares contents of two "tree" objects;
+git-diff-tree compares contents of two "tree" objects;
-
-
In all of these cases, the commands themselves compare
+
+In all of these cases, the commands themselves compare
corresponding paths in the two sets of files. The result of
comparison is passed from these commands to what is internally
called "diffcore", in a format similar to what is output when
-the -p option is not used. E.g.
+the -p option is not used. E.g.
in-place edit :100644 100644 bcd1234... 0123456... M file0
@@ -320,11 +368,11 @@ create :000000 100644 0000000... 1234567... A file4
delete :100644 000000 1234567... 0000000... D file5
unmerged :000000 000000 0000000... 0000000... U file6
-The diffcore mechanism is fed a list of such comparison results
+
The diffcore mechanism is fed a list of such comparison results
(each of which is called "filepair", although at this point each
of them talks about a single file), and transforms such a list
-into another list. There are currently 6 such transformations:
-
+into another list. There are currently 6 such transformations:
+
-
These are applied in sequence. The set of filepairs git-diff-*
+
+These are applied in sequence. The set of filepairs git-diff-*
commands find are used as the input to diffcore-pathspec, and
the output from diffcore-pathspec is used as the input to the
next transformation. The final result is then passed to the
output routine and generates either diff-raw format (see Output
-format sections of the manual for git-diff-* commands) or
-diff-patch format.
+format sections of the manual for
git-diff-* commands) or
+diff-patch format.
-diffcore-pathspec: For Ignoring Files Outside Our Consideration
+diffcore-pathspec: For Ignoring Files Outside Our Consideration
-
The first transformation in the chain is diffcore-pathspec, and
+
The first transformation in the chain is diffcore-pathspec, and
is controlled by giving the pathname parameters to the
-git-diff-* commands on the command line. The pathspec is used
+git-diff-* commands on the command line. The pathspec is used
to limit the world diff operates in. It removes the filepairs
outside the specified set of pathnames. E.g. If the input set
-of filepairs included:
+of filepairs included:
:100644 100644 bcd1234... 0123456... M junkfile
-
but the command invocation was git diff-files myfile , then the
+
but the command invocation was git diff-files myfile , then the
junkfile entry would be removed from the list because only "myfile"
-is under consideration.
-
Implementation note. For performance reasons, git-diff-tree
+is under consideration.
+
Implementation note. For performance reasons, git-diff-tree
uses the pathname parameters on the command line to cull set of
filepairs it feeds the diffcore mechanism itself, and does not
-use diffcore-pathspec, but the end result is the same.
+use diffcore-pathspec, but the end result is the same.
-diffcore-break: For Splitting Up "Complete Rewrites"
+diffcore-break: For Splitting Up "Complete Rewrites"
-
The second transformation in the chain is diffcore-break, and is
-controlled by the -B option to the git-diff-* commands. This is
+
The second transformation in the chain is diffcore-break, and is
+controlled by the -B option to the git-diff-* commands. This is
used to detect a filepair that represents "complete rewrite" and
break such filepair into two filepairs that represent delete and
-create. E.g. If the input contained this filepair:
+create. E.g. If the input contained this filepair:
:100644 100644 bcd1234... 0123456... M file0
-
and if it detects that the file "file0" is completely rewritten,
-it changes it to:
+
and if it detects that the file "file0" is completely rewritten,
+it changes it to:
:100644 000000 bcd1234... 0000000... D file0
:000000 100644 0000000... 0123456... A file0
-
For the purpose of breaking a filepair, diffcore-break examines
+
For the purpose of breaking a filepair, diffcore-break examines
the extent of changes between the contents of the files before
and after modification (i.e. the contents that have "bcd1234…"
and "0123456…" as their SHA1 content ID, in the above
@@ -413,66 +461,66 @@ score defaults to 50% of the size of the smaller of the original
and the result (i.e. if the edit shrinks the file, the size of
the result is used; if the edit lengthens the file, the size of
the original is used), and can be customized by giving a number
-after "-B" option (e.g. "-B75" to tell it to use 75%).
+after "-B" option (e.g. "-B75" to tell it to use 75%).
-diffcore-rename: For Detection Renames and Copies
+diffcore-rename: For Detection Renames and Copies
-
This transformation is used to detect renames and copies, and is
+
This transformation is used to detect renames and copies, and is
controlled by the -M option (to detect renames) and the -C option
-(to detect copies as well) to the git-diff-* commands. If the
-input contained these filepairs:
+(to detect copies as well) to the
git-diff-* commands. If the
+input contained these filepairs:
:100644 000000 0123456... 0000000... D fileX
:000000 100644 0000000... 0123456... A file0
-
and the contents of the deleted file fileX is similar enough to
+
and the contents of the deleted file fileX is similar enough to
the contents of the created file file0, then rename detection
-merges these filepairs and creates:
+merges these filepairs and creates:
:100644 100644 0123456... 0123456... R100 fileX file0
-
When the "-C" option is used, the original contents of modified files,
+
When the "-C" option is used, the original contents of modified files,
and deleted files (and also unmodified files, if the
"--find-copies-harder" option is used) are considered as candidates
of the source files in rename/copy operation. If the input were like
these filepairs, that talk about a modified file fileY and a newly
-created file file0:
+created file file0:
:100644 100644 0123456... 1234567... M fileY
:000000 100644 0000000... bcd3456... A file0
-
the original contents of fileY and the resulting contents of
+
the original contents of fileY and the resulting contents of
file0 are compared, and if they are similar enough, they are
-changed to:
+changed to:
:100644 100644 0123456... 1234567... M fileY
:100644 100644 0123456... bcd3456... C100 fileY file0
-
In both rename and copy detection, the same "extent of changes"
+
In both rename and copy detection, the same "extent of changes"
algorithm used in diffcore-break is used to determine if two
files are "similar enough", and can be customized to use
a similarity score different from the default of 50% by giving a
number after the "-M" or "-C" option (e.g. "-M8" to tell it to use
-8/10 = 80%).
-
Note. When the "-C" option is used with --find-copies-harder
-option, git-diff-* commands feed unmodified filepairs to
+8/10 = 80%).
+
Note. When the "-C" option is used with --find-copies-harder
+option, git-diff-* commands feed unmodified filepairs to
diffcore mechanism as well as modified ones. This lets the copy
detector consider unmodified files as copy source candidates at
the expense of making it slower. Without --find-copies-harder ,
-git-diff-* commands can detect copies only if the file that was
-copied happened to have been modified in the same changeset.
+
git-diff-* commands can detect copies only if the file that was
+copied happened to have been modified in the same changeset.
-diffcore-merge-broken: For Putting "Complete Rewrites" Back Together
+diffcore-merge-broken: For Putting "Complete Rewrites" Back Together
-
This transformation is used to merge filepairs broken by
+
This transformation is used to merge filepairs broken by
diffcore-break, and not transformed into rename/copy by
diffcore-rename, back into a single modification. This always
-runs when diffcore-break is used.
-
For the purpose of merging broken filepairs back, it uses a
+runs when diffcore-break is used.
+
For the purpose of merging broken filepairs back, it uses a
different "extent of changes" computation from the ones used by
diffcore-break and diffcore-rename. It counts only the deletion
from the original, and does not count insertion. If you removed
@@ -483,13 +531,13 @@ help diffcore-rename to consider such filepairs as candidate of
rename/copy detection, but if filepairs broken that way were not
matched with other filepairs to create rename/copy, then this
transformation merges them back into the original
-"modification".
-
The "extent of changes" parameter can be tweaked from the
+"modification".
+
The "extent of changes" parameter can be tweaked from the
default 80% (that is, unless more than 80% of the original
material is deleted, the broken pairs are merged back into a
single modification) by giving a second number to -B option,
-like these:
-
+
-
Note that earlier implementation left a broken pair as a separate
+
+
Note that earlier implementation left a broken pair as a separate
creation and deletion patches. This was an unnecessary hack and
the latest implementation always merges all the broken pairs
back into modifications, but the resulting patch output is
formatted differently for easier review in case of such
a complete rewrite by showing the entire contents of old version
prefixed with - , followed by the entire contents of new
-version prefixed with + .
+version prefixed with
+ .
-diffcore-pickaxe: For Detecting Addition/Deletion of Specified String
+diffcore-pickaxe: For Detecting Addition/Deletion of Specified String
-
This transformation is used to find filepairs that represent
+
This transformation is used to find filepairs that represent
changes that touch a specified string, and is controlled by the
--S option and the --pickaxe-all option to the git-diff-*
-commands.
-
When diffcore-pickaxe is in use, it checks if there are
+-S option and the --pickaxe-all option to the git-diff-*
+commands.
+
When diffcore-pickaxe is in use, it checks if there are
filepairs whose "original" side has the specified string and
whose "result" side does not. Such a filepair represents "the
string appeared in this changeset". It also checks for the
-opposite case that loses the specified string.
-
When --pickaxe-all is not in effect, diffcore-pickaxe leaves
+opposite case that loses the specified string.
+
When --pickaxe-all is not in effect, diffcore-pickaxe leaves
only such filepairs that touch the specified string in its
output. When --pickaxe-all is used, diffcore-pickaxe leaves all
filepairs intact if there is such a filepair, or makes the
output empty otherwise. The latter behaviour is designed to
make reviewing of the changes in the context of the whole
-changeset easier.
+changeset easier.
-diffcore-order: For Sorting the Output Based on Filenames
+diffcore-order: For Sorting the Output Based on Filenames
-
This is used to reorder the filepairs according to the user's
+
This is used to reorder the filepairs according to the user's
(or project's) taste, and is controlled by the -O option to the
-git-diff-* commands.
-
This takes a text file each of whose lines is a shell glob
+git-diff-* commands.
+
This takes a text file each of whose lines is a shell glob
pattern. Filepairs that match a glob pattern on an earlier line
in the file are output before ones that match a later line, and
-filepairs that do not match any glob pattern are output last.
-
As an example, a typical orderfile for the core git probably
-would look like this:
+filepairs that do not match any glob pattern are output last.
+
As an example, a typical orderfile for the core git probably
+would look like this:
README
@@ -551,24 +599,24 @@ Documentation
t
-SEE ALSO
+SEE ALSO
-GIT
+GIT
-
Part of the git(1) suite.
+
diff --git a/gitdiffcore.txt b/gitdiffcore.txt
index 0b7daeda2..2bdbc3d4f 100644
--- a/gitdiffcore.txt
+++ b/gitdiffcore.txt
@@ -7,34 +7,34 @@ gitdiffcore - Tweaking diff output (June 2005)
SYNOPSIS
--------
-git diff *
+'git diff' *
DESCRIPTION
-----------
-The diff commands `git-diff-index`, `git-diff-files`, and `git-diff-tree`
+The diff commands 'git-diff-index', 'git-diff-files', and 'git-diff-tree'
can be told to manipulate differences they find in
-unconventional ways before showing `diff` output. The manipulation
+unconventional ways before showing 'diff' output. The manipulation
is collectively called "diffcore transformation". This short note
-describes what they are and how to use them to produce diff outputs
-that are easier to understand than the conventional kind.
+describes what they are and how to use them to produce 'diff' output
+that is easier to understand than the conventional kind.
The chain of operation
----------------------
-The `git-diff-{asterisk}` family works by first comparing two sets of
+The 'git-diff-{asterisk}' family works by first comparing two sets of
files:
- - `git-diff-index` compares contents of a "tree" object and the
+ - 'git-diff-index' compares contents of a "tree" object and the
working directory (when '\--cached' flag is not used) or a
"tree" object and the index file (when '\--cached' flag is
used);
- - `git-diff-files` compares contents of the index file and the
+ - 'git-diff-files' compares contents of the index file and the
working directory;
- - `git-diff-tree` compares contents of two "tree" objects;
+ - 'git-diff-tree' compares contents of two "tree" objects;
In all of these cases, the commands themselves compare
corresponding paths in the two sets of files. The result of
@@ -61,12 +61,12 @@ into another list. There are currently 6 such transformations:
- diffcore-pickaxe
- diffcore-order
-These are applied in sequence. The set of filepairs `git-diff-{asterisk}`
+These are applied in sequence. The set of filepairs 'git-diff-{asterisk}'
commands find are used as the input to diffcore-pathspec, and
the output from diffcore-pathspec is used as the input to the
next transformation. The final result is then passed to the
output routine and generates either diff-raw format (see Output
-format sections of the manual for `git-diff-{asterisk}` commands) or
+format sections of the manual for 'git-diff-{asterisk}' commands) or
diff-patch format.
@@ -75,7 +75,7 @@ diffcore-pathspec: For Ignoring Files Outside Our Consideration
The first transformation in the chain is diffcore-pathspec, and
is controlled by giving the pathname parameters to the
-`git-diff-{asterisk}` commands on the command line. The pathspec is used
+'git-diff-{asterisk}' commands on the command line. The pathspec is used
to limit the world diff operates in. It removes the filepairs
outside the specified set of pathnames. E.g. If the input set
of filepairs included:
@@ -88,7 +88,7 @@ but the command invocation was `git diff-files myfile`, then the
junkfile entry would be removed from the list because only "myfile"
is under consideration.
-Implementation note. For performance reasons, `git-diff-tree`
+Implementation note. For performance reasons, 'git-diff-tree'
uses the pathname parameters on the command line to cull set of
filepairs it feeds the diffcore mechanism itself, and does not
use diffcore-pathspec, but the end result is the same.
@@ -98,7 +98,7 @@ diffcore-break: For Splitting Up "Complete Rewrites"
----------------------------------------------------
The second transformation in the chain is diffcore-break, and is
-controlled by the -B option to the `git-diff-{asterisk}` commands. This is
+controlled by the -B option to the 'git-diff-{asterisk}' commands. This is
used to detect a filepair that represents "complete rewrite" and
break such filepair into two filepairs that represent delete and
create. E.g. If the input contained this filepair:
@@ -134,7 +134,7 @@ diffcore-rename: For Detection Renames and Copies
This transformation is used to detect renames and copies, and is
controlled by the -M option (to detect renames) and the -C option
-(to detect copies as well) to the `git-diff-{asterisk}` commands. If the
+(to detect copies as well) to the 'git-diff-{asterisk}' commands. If the
input contained these filepairs:
------------------------------------------------
@@ -179,11 +179,11 @@ number after the "-M" or "-C" option (e.g. "-M8" to tell it to use
8/10 = 80%).
Note. When the "-C" option is used with `\--find-copies-harder`
-option, `git-diff-{asterisk}` commands feed unmodified filepairs to
+option, 'git-diff-{asterisk}' commands feed unmodified filepairs to
diffcore mechanism as well as modified ones. This lets the copy
detector consider unmodified files as copy source candidates at
the expense of making it slower. Without `\--find-copies-harder`,
-`git-diff-{asterisk}` commands can detect copies only if the file that was
+'git-diff-{asterisk}' commands can detect copies only if the file that was
copied happened to have been modified in the same changeset.
@@ -234,7 +234,7 @@ diffcore-pickaxe: For Detecting Addition/Deletion of Specified String
This transformation is used to find filepairs that represent
changes that touch a specified string, and is controlled by the
--S option and the `\--pickaxe-all` option to the `git-diff-{asterisk}`
+-S option and the `\--pickaxe-all` option to the 'git-diff-{asterisk}'
commands.
When diffcore-pickaxe is in use, it checks if there are
@@ -257,7 +257,7 @@ diffcore-order: For Sorting the Output Based on Filenames
This is used to reorder the filepairs according to the user's
(or project's) taste, and is controlled by the -O option to the
-`git-diff-{asterisk}` commands.
+'git-diff-{asterisk}' commands.
This takes a text file each of whose lines is a shell glob
pattern. Filepairs that match a glob pattern on an earlier line
diff --git a/githooks.html b/githooks.html
index f130c11a8..6be1cdaf3 100644
--- a/githooks.html
+++ b/githooks.html
@@ -3,7 +3,7 @@
-
+
githooks(5)
@@ -272,163 +320,163 @@ githooks(5) Manual Page
SYNOPSIS
-DESCRIPTION
+DESCRIPTION
-
Hooks are little scripts you can place in $GIT_DIR/hooks
+
Hooks are little scripts you can place in $GIT_DIR/hooks
directory to trigger action at certain points. When
-git-init is run, a handful example hooks are copied in the
+git-init is run, a handful example hooks are copied in the
hooks directory of the new repository, but by default they are
all disabled. To enable a hook, rename it by removing its .sample
-suffix.
-
This document describes the currently defined hooks.
+suffix.
+
This document describes the currently defined hooks.
-applypatch-msg
+applypatch-msg
-
This hook is invoked by git-am script. It takes a single
+
This hook is invoked by git-am script. It takes a single
parameter, the name of the file that holds the proposed commit
log message. Exiting with non-zero status causes
-git-am to abort before applying the patch.
-
The hook is allowed to edit the message file in place, and can
+git-am to abort before applying the patch.
+
The hook is allowed to edit the message file in place, and can
be used to normalize the message into some project standard
format (if the project has one). It can also be used to refuse
-the commit after inspecting the message file.
-
The default applypatch-msg hook, when enabled, runs the
-commit-msg hook, if the latter is enabled.
+the commit after inspecting the message file.
+
The default applypatch-msg hook, when enabled, runs the
+commit-msg hook, if the latter is enabled.
-pre-applypatch
+pre-applypatch
-
This hook is invoked by git-am . It takes no parameter, and is
-invoked after the patch is applied, but before a commit is made.
-
If it exits with non-zero status, then the working tree will not be
-committed after applying the patch.
-
It can be used to inspect the current working tree and refuse to
-make a commit if it does not pass certain test.
-
The default pre-applypatch hook, when enabled, runs the
-pre-commit hook, if the latter is enabled.
+
This hook is invoked by git-am . It takes no parameter, and is
+invoked after the patch is applied, but before a commit is made.
+
If it exits with non-zero status, then the working tree will not be
+committed after applying the patch.
+
It can be used to inspect the current working tree and refuse to
+make a commit if it does not pass certain test.
+
The default pre-applypatch hook, when enabled, runs the
+pre-commit hook, if the latter is enabled.
-post-applypatch
+post-applypatch
-
This hook is invoked by git-am . It takes no parameter,
-and is invoked after the patch is applied and a commit is made.
-
This hook is meant primarily for notification, and cannot affect
-the outcome of git-am .
+
This hook is invoked by git-am . It takes no parameter,
+and is invoked after the patch is applied and a commit is made.
+
This hook is meant primarily for notification, and cannot affect
+the outcome of git-am .
-pre-commit
+pre-commit
-
This hook is invoked by git-commit , and can be bypassed
+
This hook is invoked by git-commit , and can be bypassed
with --no-verify option. It takes no parameter, and is
invoked before obtaining the proposed commit log message and
making a commit. Exiting with non-zero status from this script
-causes the git-commit to abort.
-
The default pre-commit hook, when enabled, catches introduction
+causes the git-commit to abort.
+
The default pre-commit hook, when enabled, catches introduction
of lines with trailing whitespaces and aborts the commit when
-such a line is found.
-
All the git-commit hooks are invoked with the environment
+such a line is found.
+
All the git-commit hooks are invoked with the environment
variable GIT_EDITOR=: if the command will not bring up an editor
-to modify the commit message.
+to modify the commit message.
-prepare-commit-msg
+prepare-commit-msg
-
This hook is invoked by git-commit right after preparing the
-default log message, and before the editor is started.
-
It takes one to three parameters. The first is the name of the file
+
This hook is invoked by git-commit right after preparing the
+default log message, and before the editor is started.
+
It takes one to three parameters. The first is the name of the file
that the commit log message. The second is the source of the commit
message, and can be: message (if a \-m or \-F option was
given); template (if a \-t option was given or the
configuration option commit.template is set); merge (if the
commit is a merge or a .git/MERGE_MSG file exists); squash
(if a .git/SQUASH_MSG file exists); or commit , followed by
-a commit SHA1 (if a \-c , \-C or --amend option was given).
-
If the exit status is non-zero, git-commit will abort.
-
The purpose of the hook is to edit the message file in place, and
+a commit SHA1 (if a \-c , \-C or --amend option was given).
+
If the exit status is non-zero, git-commit will abort.
+
The purpose of the hook is to edit the message file in place, and
it is not suppressed by the --no-verify option. A non-zero exit
means a failure of the hook and aborts the commit. It should not
-be used as replacement for pre-commit hook.
-
The sample prepare-commit-msg hook that comes with git comments
-out the Conflicts: part of a merge's commit message.
+be used as replacement for pre-commit hook.
+
The sample prepare-commit-msg hook that comes with git comments
+out the Conflicts: part of a merge's commit message.
-commit-msg
+commit-msg
-
This hook is invoked by git-commit , and can be bypassed
+
This hook is invoked by git-commit , and can be bypassed
with --no-verify option. It takes a single parameter, the
name of the file that holds the proposed commit log message.
-Exiting with non-zero status causes the git-commit to
-abort.
-
The hook is allowed to edit the message file in place, and can
+Exiting with non-zero status causes the git-commit to
+abort.
+
The hook is allowed to edit the message file in place, and can
be used to normalize the message into some project standard
format (if the project has one). It can also be used to refuse
-the commit after inspecting the message file.
-
The default commit-msg hook, when enabled, detects duplicate
-"Signed-off-by" lines, and aborts the commit if one is found.
+the commit after inspecting the message file.
+
The default commit-msg hook, when enabled, detects duplicate
+"Signed-off-by" lines, and aborts the commit if one is found.
-post-commit
+post-commit
-
This hook is invoked by git-commit . It takes no
-parameter, and is invoked after a commit is made.
-
This hook is meant primarily for notification, and cannot affect
-the outcome of git-commit .
+
This hook is invoked by git-commit . It takes no
+parameter, and is invoked after a commit is made.
+
This hook is meant primarily for notification, and cannot affect
+the outcome of git-commit .
-post-checkout
+post-checkout
-
This hook is invoked when a git-checkout is run after having updated the
+
This hook is invoked when a git-checkout is run after having updated the
worktree. The hook is given three parameters: the ref of the previous HEAD,
the ref of the new HEAD (which may or may not have changed), and a flag
indicating whether the checkout was a branch checkout (changing branches,
flag=1) or a file checkout (retrieving a file from the index, flag=0).
-This hook cannot affect the outcome of git-checkout .
-
This hook can be used to perform repository validity checks, auto-display
+This hook cannot affect the outcome of git-checkout .
+
This hook can be used to perform repository validity checks, auto-display
differences from the previous HEAD if different, or set working dir metadata
-properties.
+properties.
-post-merge
+post-merge
-
This hook is invoked by git-merge , which happens when a git-pull
+
This hook is invoked by git-merge , which happens when a git-pull
is done on a local repository. The hook takes a single parameter, a status
flag specifying whether or not the merge being done was a squash merge.
-This hook cannot affect the outcome of git-merge and is not executed,
-if the merge failed due to conflicts.
-
This hook can be used in conjunction with a corresponding pre-commit hook to
+This hook cannot affect the outcome of git-merge and is not executed,
+if the merge failed due to conflicts.
+
This hook can be used in conjunction with a corresponding pre-commit hook to
save and restore any form of metadata associated with the working tree
(eg: permissions/ownership, ACLS, etc). See contrib/hooks/setgitperms.perl
-for an example of how to do this.
+for an example of how to do this.
- pre-receive
+pre-receive
-
This hook is invoked by git-receive-pack on the remote repository,
-which happens when a git-push is done on a local repository.
+
This hook is invoked by git-receive-pack on the remote repository,
+which happens when a git-push is done on a local repository.
Just before starting to update refs on the remote repository, the
pre-receive hook is invoked. Its exit status determines the success
-or failure of the update.
-
This hook executes once for the receive operation. It takes no
+or failure of the update.
+
This hook executes once for the receive operation. It takes no
arguments, but for each ref to be updated it receives on standard
-input a line of the format:
+input a line of the format:
<old-value> SP <new-value> SP <ref-name> LF
-
where <old-value> is the old object name stored in the ref,
+
where <old-value> is the old object name stored in the ref,
<new-value> is the new object name to be stored in the ref and
<ref-name> is the full name of the ref.
-When creating a new ref, <old-value> is 40 0 .
-
If the hook exits with non-zero status, none of the refs will be
+When creating a new ref, <old-value> is 40 0 .
+
If the hook exits with non-zero status, none of the refs will be
updated. If the hook exits with zero, updating of individual refs can
-still be prevented by the update hook.
-
Both standard output and standard error output are forwarded to
-git-send-pack on the other end, so you can simply echo messages
-for the user.
+still be prevented by the
update hook.
+
Both standard output and standard error output are forwarded to
+git-send-pack on the other end, so you can simply echo messages
+for the user.
- update
+update
-
This hook is invoked by git-receive-pack on the remote repository,
-which happens when a git-push is done on a local repository.
+
This hook is invoked by git-receive-pack on the remote repository,
+which happens when a git-push is done on a local repository.
Just before updating the ref on the remote repository, the update hook
is invoked. Its exit status determines the success or failure of
-the ref update.
-
The hook executes once for each ref to be updated, and takes
-three parameters:
-
+
The hook executes once for each ref to be updated, and takes
+three parameters:
+
the name of the ref being updated,
@@ -444,89 +492,89 @@ the old object name stored in the ref,
and the new objectname to be stored in the ref.
-
-
A zero exit from the update hook allows the ref to be updated.
-Exiting with a non-zero status prevents git-receive-pack
-from updating that ref.
-
This hook can be used to prevent forced update on certain refs by
+
+
A zero exit from the update hook allows the ref to be updated.
+Exiting with a non-zero status prevents git-receive-pack
+from updating that ref.
+
This hook can be used to prevent forced update on certain refs by
making sure that the object name is a commit object that is a
descendant of the commit object named by the old object name.
-That is, to enforce a "fast forward only" policy.
-
It could also be used to log the old..new status. However, it
+That is, to enforce a "fast forward only" policy.
+
It could also be used to log the old..new status. However, it
does not know the entire set of branches, so it would end up
firing one e-mail per ref when used naively, though. The
-post-receive hook is more suited to that.
-
Another use suggested on the mailing list is to use this hook to
+post-receive hook is more suited to that.
+
Another use suggested on the mailing list is to use this hook to
implement access control which is finer grained than the one
-based on filesystem group.
-
Both standard output and standard error output are forwarded to
-git-send-pack on the other end, so you can simply echo messages
-for the user.
-
The default update hook, when enabled--and with
+based on filesystem group.
+
Both standard output and standard error output are forwarded to
+git-send-pack on the other end, so you can simply echo messages
+for the user.
+
The default update hook, when enabled--and with
hooks.allowunannotated config option turned on--prevents
-unannotated tags to be pushed.
+unannotated tags to be pushed.
- post-receive
+post-receive
-
This hook is invoked by git-receive-pack on the remote repository,
-which happens when a git-push is done on a local repository.
+
This hook is invoked by git-receive-pack on the remote repository,
+which happens when a git-push is done on a local repository.
It executes on the remote repository once after all the refs have
-been updated.
-
This hook executes once for the receive operation. It takes no
+been updated.
+
This hook executes once for the receive operation. It takes no
arguments, but gets the same information as the
pre-receive
-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 gets
+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 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
-git-send-pack on the other end, so you can simply echo messages
-for the user.
-
The default post-receive hook is empty, but there is
+names.
+
Both standard output and standard error output are forwarded to
+git-send-pack on the other end, so you can simply echo messages
+for the user.
+
The default post-receive hook is empty, but there is
a sample script post-receive-email provided in the contrib/hooks
directory in git distribution, which implements sending commit
-emails.
+emails.
- post-update
+post-update
-
This hook is invoked by git-receive-pack on the remote repository,
-which happens when a git-push is done on a local repository.
+
This hook is invoked by git-receive-pack on the remote repository,
+which happens when a git-push is done on a local repository.
It executes on the remote repository once after all the refs have
-been updated.
-
It takes a variable number of parameters, each of which is the
-name of ref that was actually updated.
-
This hook is meant primarily for notification, and cannot affect
-the outcome of git-receive-pack .
-
The post-update hook can tell what are the heads that were pushed,
+been updated.
+
It takes a variable number of parameters, each of which is the
+name of ref that was actually updated.
+
This hook is meant primarily for notification, and cannot affect
+the outcome of git-receive-pack .
+
The post-update hook can tell what are the heads that were pushed,
but it does not know what their original and updated values are,
so it is a poor place to do log old..new. The
post-receive hook does get both original and
updated values of the refs. You might consider it instead if you need
-them.
-
When enabled, the default post-update hook runs
-git-update-server-info to keep the information used by dumb
+them.
+
When enabled, the default post-update hook runs
+git-update-server-info to keep the information used by dumb
transports (e.g., HTTP) up-to-date. If you are publishing
a git repository that is accessible via HTTP, you should
-probably enable this hook.
-
Both standard output and standard error output are forwarded to
-git-send-pack on the other end, so you can simply echo messages
-for the user.
+probably enable this hook.
+
Both standard output and standard error output are forwarded to
+git-send-pack on the other end, so you can simply echo messages
+for the user.
-pre-auto-gc
+pre-auto-gc
-
This hook is invoked by git-gc --auto . It takes no parameter, and
-exiting with non-zero status from this script causes the git-gc --auto
-to abort.
+
This hook is invoked by git-gc --auto . It takes no parameter, and
+exiting with non-zero status from this script causes the git-gc --auto
+to abort.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/githooks.txt b/githooks.txt
index 6a0d098f7..046a2a7fe 100644
--- a/githooks.txt
+++ b/githooks.txt
@@ -15,7 +15,7 @@ DESCRIPTION
Hooks are little scripts you can place in `$GIT_DIR/hooks`
directory to trigger action at certain points. When
-`git-init` is run, a handful example hooks are copied in the
+'git-init' is run, a handful example hooks are copied in the
`hooks` directory of the new repository, but by default they are
all disabled. To enable a hook, rename it by removing its `.sample`
suffix.
@@ -25,10 +25,10 @@ This document describes the currently defined hooks.
applypatch-msg
--------------
-This hook is invoked by `git-am` script. It takes a single
+This hook is invoked by 'git-am' script. It takes a single
parameter, the name of the file that holds the proposed commit
log message. Exiting with non-zero status causes
-`git-am` to abort before applying the patch.
+'git-am' to abort before applying the patch.
The hook is allowed to edit the message file in place, and can
be used to normalize the message into some project standard
@@ -41,7 +41,7 @@ The default 'applypatch-msg' hook, when enabled, runs the
pre-applypatch
--------------
-This hook is invoked by `git-am`. It takes no parameter, and is
+This hook is invoked by 'git-am'. It takes no parameter, and is
invoked after the patch is applied, but before a commit is made.
If it exits with non-zero status, then the working tree will not be
@@ -56,33 +56,33 @@ The default 'pre-applypatch' hook, when enabled, runs the
post-applypatch
---------------
-This hook is invoked by `git-am`. It takes no parameter,
+This hook is invoked by 'git-am'. It takes no parameter,
and is invoked after the patch is applied and a commit is made.
This hook is meant primarily for notification, and cannot affect
-the outcome of `git-am`.
+the outcome of 'git-am'.
pre-commit
----------
-This hook is invoked by `git-commit`, and can be bypassed
+This hook is invoked by 'git-commit', and can be bypassed
with `\--no-verify` option. It takes no parameter, and is
invoked before obtaining the proposed commit log message and
making a commit. Exiting with non-zero status from this script
-causes the `git-commit` to abort.
+causes the 'git-commit' to abort.
The default 'pre-commit' hook, when enabled, catches introduction
of lines with trailing whitespaces and aborts the commit when
such a line is found.
-All the `git-commit` hooks are invoked with the environment
+All the 'git-commit' hooks are invoked with the environment
variable `GIT_EDITOR=:` if the command will not bring up an editor
to modify the commit message.
prepare-commit-msg
------------------
-This hook is invoked by `git-commit` right after preparing the
+This hook is invoked by 'git-commit' right after preparing the
default log message, and before the editor is started.
It takes one to three parameters. The first is the name of the file
@@ -94,7 +94,7 @@ commit is a merge or a `.git/MERGE_MSG` file exists); `squash`
(if a `.git/SQUASH_MSG` file exists); or `commit`, followed by
a commit SHA1 (if a `\-c`, `\-C` or `\--amend` option was given).
-If the exit status is non-zero, `git-commit` will abort.
+If the exit status is non-zero, 'git-commit' will abort.
The purpose of the hook is to edit the message file in place, and
it is not suppressed by the `\--no-verify` option. A non-zero exit
@@ -107,10 +107,10 @@ out the `Conflicts:` part of a merge's commit message.
commit-msg
----------
-This hook is invoked by `git-commit`, and can be bypassed
+This hook is invoked by 'git-commit', and can be bypassed
with `\--no-verify` option. It takes a single parameter, the
name of the file that holds the proposed commit log message.
-Exiting with non-zero status causes the `git-commit` to
+Exiting with non-zero status causes the 'git-commit' to
abort.
The hook is allowed to edit the message file in place, and can
@@ -124,21 +124,21 @@ The default 'commit-msg' hook, when enabled, detects duplicate
post-commit
-----------
-This hook is invoked by `git-commit`. It takes no
+This hook is invoked by 'git-commit'. It takes no
parameter, and is invoked after a commit is made.
This hook is meant primarily for notification, and cannot affect
-the outcome of `git-commit`.
+the outcome of 'git-commit'.
post-checkout
-----------
-This hook is invoked when a `git-checkout` is run after having updated the
+This hook is invoked when a 'git-checkout' is run after having updated the
worktree. The hook is given three parameters: the ref of the previous HEAD,
the ref of the new HEAD (which may or may not have changed), and a flag
indicating whether the checkout was a branch checkout (changing branches,
flag=1) or a file checkout (retrieving a file from the index, flag=0).
-This hook cannot affect the outcome of `git-checkout`.
+This hook cannot affect the outcome of 'git-checkout'.
This hook can be used to perform repository validity checks, auto-display
differences from the previous HEAD if different, or set working dir metadata
@@ -147,10 +147,10 @@ properties.
post-merge
-----------
-This hook is invoked by `git-merge`, which happens when a `git-pull`
+This hook is invoked by 'git-merge', which happens when a 'git-pull'
is done on a local repository. The hook takes a single parameter, a status
flag specifying whether or not the merge being done was a squash merge.
-This hook cannot affect the outcome of `git-merge` and is not executed,
+This hook cannot affect the outcome of 'git-merge' and is not executed,
if the merge failed due to conflicts.
This hook can be used in conjunction with a corresponding pre-commit hook to
@@ -162,8 +162,8 @@ for an example of how to do this.
pre-receive
-----------
-This hook is invoked by `git-receive-pack` on the remote repository,
-which happens when a `git-push` is done on a local repository.
+This hook is invoked by 'git-receive-pack' on the remote repository,
+which happens when a 'git-push' is done on a local repository.
Just before starting to update refs on the remote repository, the
pre-receive hook is invoked. Its exit status determines the success
or failure of the update.
@@ -184,15 +184,15 @@ updated. If the hook exits with zero, updating of individual refs can
still be prevented by the <> hook.
Both standard output and standard error output are forwarded to
-`git-send-pack` on the other end, so you can simply `echo` messages
+'git-send-pack' on the other end, so you can simply `echo` messages
for the user.
[[update]]
update
------
-This hook is invoked by `git-receive-pack` on the remote repository,
-which happens when a `git-push` is done on a local repository.
+This hook is invoked by 'git-receive-pack' on the remote repository,
+which happens when a 'git-push' is done on a local repository.
Just before updating the ref on the remote repository, the update hook
is invoked. Its exit status determines the success or failure of
the ref update.
@@ -205,7 +205,7 @@ three parameters:
- and the new objectname to be stored in the ref.
A zero exit from the update hook allows the ref to be updated.
-Exiting with a non-zero status prevents `git-receive-pack`
+Exiting with a non-zero status prevents 'git-receive-pack'
from updating that ref.
This hook can be used to prevent 'forced' update on certain refs by
@@ -223,7 +223,7 @@ implement access control which is finer grained than the one
based on filesystem group.
Both standard output and standard error output are forwarded to
-`git-send-pack` on the other end, so you can simply `echo` messages
+'git-send-pack' on the other end, so you can simply `echo` messages
for the user.
The default 'update' hook, when enabled--and with
@@ -234,8 +234,8 @@ unannotated tags to be pushed.
post-receive
------------
-This hook is invoked by `git-receive-pack` on the remote repository,
-which happens when a `git-push` is done on a local repository.
+This hook is invoked by 'git-receive-pack' on the remote repository,
+which happens when a 'git-push' is done on a local repository.
It executes on the remote repository once after all the refs have
been updated.
@@ -244,7 +244,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
+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 gets
@@ -252,7 +252,7 @@ both old and new values of all the refs in addition to their
names.
Both standard output and standard error output are forwarded to
-`git-send-pack` on the other end, so you can simply `echo` messages
+'git-send-pack' on the other end, so you can simply `echo` messages
for the user.
The default 'post-receive' hook is empty, but there is
@@ -264,8 +264,8 @@ emails.
post-update
-----------
-This hook is invoked by `git-receive-pack` on the remote repository,
-which happens when a `git-push` is done on a local repository.
+This hook is invoked by 'git-receive-pack' on the remote repository,
+which happens when a 'git-push' is done on a local repository.
It executes on the remote repository once after all the refs have
been updated.
@@ -273,7 +273,7 @@ It takes a variable number of parameters, each of which is the
name of ref that was actually updated.
This hook is meant primarily for notification, and cannot affect
-the outcome of `git-receive-pack`.
+the outcome of 'git-receive-pack'.
The 'post-update' hook can tell what are the heads that were pushed,
but it does not know what their original and updated values are,
@@ -283,20 +283,20 @@ updated values of the refs. You might consider it instead if you need
them.
When enabled, the default 'post-update' hook runs
-`git-update-server-info` to keep the information used by dumb
+'git-update-server-info' to keep the information used by dumb
transports (e.g., HTTP) up-to-date. If you are publishing
a git repository that is accessible via HTTP, you should
probably enable this hook.
Both standard output and standard error output are forwarded to
-`git-send-pack` on the other end, so you can simply `echo` messages
+'git-send-pack' on the other end, so you can simply `echo` messages
for the user.
pre-auto-gc
-----------
-This hook is invoked by `git-gc --auto`. It takes no parameter, and
-exiting with non-zero status from this script causes the `git-gc --auto`
+This hook is invoked by 'git-gc --auto'. It takes no parameter, and
+exiting with non-zero status from this script causes the 'git-gc --auto'
to abort.
GIT
diff --git a/gitignore.html b/gitignore.html
index f5292ed33..3c8799bc6 100644
--- a/gitignore.html
+++ b/gitignore.html
@@ -3,7 +3,7 @@
-
+
gitignore(5)
@@ -272,18 +320,18 @@ gitignore(5) Manual Page
SYNOPSIS
-
$GIT_DIR/info/exclude, .gitignore
+
$GIT_DIR/info/exclude, .gitignore
-DESCRIPTION
+DESCRIPTION
-
A gitignore file specifies intentionally untracked files that
+
A gitignore file specifies intentionally untracked files that
git should ignore. Each line in a gitignore file specifies a
-pattern.
-
When deciding whether to ignore a path, git normally checks
+pattern.
+
When deciding whether to ignore a path, git normally checks
gitignore patterns from multiple sources, with the following
order of precedence, from highest to lowest (within one level of
-precedence, the last matching pattern decides the outcome):
-
+precedence, the last matching pattern decides the outcome):
+
-
Which file to place a pattern in depends on how the pattern is meant to
+
+
Which file to place a pattern in depends on how the pattern is meant to
be used. Patterns which should be version-controlled and distributed to
other repositories via clone (i.e., files that all developers will want
to ignore) should go into a .gitignore file. Patterns which are
@@ -324,15 +372,15 @@ the repository but are specific to one user's workflow) should go into
the $GIT_DIR/info/exclude file. Patterns which a user wants git to
ignore in all situations (e.g., backup or temporary files generated by
the user's editor of choice) generally go into a file specified by
-core.excludesfile in the user's ~/.gitconfig .
-
The underlying git plumbing tools, such as
-git-ls-files and git-read-tree , read
+core.excludesfile in the user's ~/.gitconfig .
+
The underlying git plumbing tools, such as
+git-ls-files and git-read-tree , read
gitignore patterns specified by command-line options, or from
files specified by command-line options. Higher-level git
-tools, such as git-status and git-add ,
-use patterns from the sources specified above.
-
Patterns have the following format:
-
+tools, such as git-status and git-add ,
+use patterns from the sources specified above.
+
Patterns have the following format:
+
A blank line matches no files, so it can serve as a separator
@@ -381,8 +429,8 @@ Otherwise, git treats the pattern as a shell glob suitable
"cat-file.c" but not "mozilla-sha1/sha1.c".
-
-
An example:
+
+
$ git status
@@ -410,7 +458,7 @@ Otherwise, git treats the pattern as a shell glob suitable
# Documentation/foo.html
[...]
-
Another example:
+
$ cat .gitignore
@@ -419,21 +467,21 @@ Otherwise, git treats the pattern as a shell glob suitable
arch/foo/kernel/vmlinux.lds.S
$ echo '!/vmlinux*' >arch/foo/kernel/.gitignore
-
The second .gitignore prevents git from ignoring
-arch/foo/kernel/vmlinux.lds.S .
+
The second .gitignore prevents git from ignoring
+arch/foo/kernel/vmlinux.lds.S .
-Documentation
+Documentation
-
Documentation by David Greaves, Junio C Hamano, Josh Triplett,
-Frank Lichtenheld, and the git-list <git@vger.kernel.org>.
+
Documentation by David Greaves, Junio C Hamano, Josh Triplett,
+Frank Lichtenheld, and the git-list <git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/gitignore.txt b/gitignore.txt
index cafdac7e3..fc0efd8ec 100644
--- a/gitignore.txt
+++ b/gitignore.txt
@@ -51,10 +51,10 @@ the user's editor of choice) generally go into a file specified by
`core.excludesfile` in the user's `~/.gitconfig`.
The underlying git plumbing tools, such as
-`git-ls-files` and `git-read-tree`, read
+'git-ls-files' and 'git-read-tree', read
`gitignore` patterns specified by command-line options, or from
files specified by command-line options. Higher-level git
-tools, such as `git-status` and `git-add`,
+tools, such as 'git-status' and 'git-add',
use patterns from the sources specified above.
Patterns have the following format:
diff --git a/gitk.html b/gitk.html
index 052195e91..421726883 100644
--- a/gitk.html
+++ b/gitk.html
@@ -3,7 +3,7 @@
-
+
gitk(1)
@@ -272,24 +320,24 @@ gitk(1) Manual Page
SYNOPSIS
-
gitk [<option>…] [<revs>] [--] [<path>…]
+
gitk [<option>…] [<revs>] [--] [<path>…]
-DESCRIPTION
+DESCRIPTION
-
Displays changes in a repository or a selected set of commits. This includes
+
Displays changes in a repository or a selected set of commits. This includes
visualizing the commit graph, showing information related to each commit, and
-the files in the trees of each revision.
-
Historically, gitk was the first repository browser. It's written in tcl/tk
+the files in the trees of each revision.
+
Historically, gitk was the first repository browser. It's written in tcl/tk
and started off in a separate repository but was later merged into the main
-git repository.
+git repository.
-OPTIONS
+OPTIONS
-
To control which revisions to shown, the command takes options applicable to
-the git-rev-list command (see git-rev-list(1) ).
+
To control which revisions to shown, the command takes options applicable to
+the git-rev-list command (see git-rev-list(1) ).
This manual page describes only the most
-frequently used options.
-
+frequently used options.
+
-n <number>
@@ -358,11 +406,11 @@ frequently used options.
from any preceding options.
-
+
-Examples
+Examples
-
+
gitk v2.6.12.. include/scsi drivers/scsi
@@ -391,16 +439,16 @@ gitk --max-count=100 --all -- Makefile
looking for changes in the current branch look in all branches.
-
+
-Files
+Files
-
Gitk creates the .gitk file in your $HOME directory to store preferences
-such as display options, font, and colors.
+
Gitk creates the .gitk file in your $HOME directory to store preferences
+such as display options, font, and colors.
-SEE ALSO
+SEE ALSO
-
+
qgit(1)
@@ -427,24 +475,24 @@ such as display options, font, and colors.
in C using Ncurses.
-
+
-Author
+Author
-
Written by Paul Mackerras <paulus@samba.org>.
+
Written by Paul Mackerras <paulus@samba.org>.
-Documentation
+Documentation
-
Documentation by Junio C Hamano, Jonas Fonseca, and the git-list
-<git@vger.kernel.org>.
+
Documentation by Junio C Hamano, Jonas Fonseca, and the git-list
+<git@vger.kernel.org>.
-GIT
+GIT
-
Part of the git(1) suite
+
diff --git a/gitk.txt b/gitk.txt
index 03688bfa6..e02ecf574 100644
--- a/gitk.txt
+++ b/gitk.txt
@@ -22,7 +22,7 @@ git repository.
OPTIONS
-------
To control which revisions to shown, the command takes options applicable to
-the `git-rev-list` command (see linkgit:git-rev-list[1]).
+the 'git-rev-list' command (see linkgit:git-rev-list[1]).
This manual page describes only the most
frequently used options.
diff --git a/gitrepository-layout.html b/gitrepository-layout.html
index 5e37a51a3..68353d78f 100644
--- a/gitrepository-layout.html
+++ b/gitrepository-layout.html
@@ -3,7 +3,7 @@
-
+
gitrepository-layout(5)
@@ -272,17 +320,17 @@ gitrepository-layout(5) Manual Page
SYNOPSIS
-DESCRIPTION
+DESCRIPTION
-
You may find these things in your git repository (.git
+
You may find these things in your git repository (.git
directory for a repository associated with your working tree, or
<project>.git directory for a public bare repository. It is
also possible to have a working tree where .git is a plain
ascii file containing gitdir: <path> , i.e. the path to the
-real git repository).
-
+real git repository).
+
objects
@@ -294,7 +342,7 @@ objects
found in it), but there are couple of ways to violate
it.
-
+
You could populate the repository by running a commit walker
@@ -322,7 +370,7 @@ use with dumb transports but otherwise is OK as long as
it borrows from.
-
+
objects/[0-9a-f][0-9a-f]
@@ -365,7 +413,7 @@ objects/info/packs
are available in this object store. Whenever a pack is
added or removed, git update-server-info should be run
to keep this file up-to-date if the repository is
- published for dumb transports. git-repack does this
+ published for dumb transports. git-repack does this
by default.
@@ -401,7 +449,7 @@ refs
References are stored in subdirectories of this
- directory. The git-prune command knows to keep
+ directory. The git-prune command knows to keep
objects reachable from refs found in this directory and
its subdirectories.
@@ -458,11 +506,11 @@ HEAD
a symbolic link instead of a symref that points at the current
branch.
-HEAD can also record a specific commit directly, instead of
+
HEAD can also record a specific commit directly, instead of
being a symref to point at the current branch. Such a state
is often called detached HEAD , and almost all commands work
identically as normal. See git-checkout(1) for
-details.
+details.
branches
@@ -470,7 +518,7 @@ branches
A slightly deprecated way to store shorthands to be used
- to specify URL to git-fetch , git-pull and git-push
+ to specify URL to git-fetch , git-pull and git-push
commands is to store a file in branches/<name> and
give name to these commands in place of repository
argument.
@@ -483,7 +531,7 @@ hooks
Hooks are customization scripts used by various git
commands. A handful of sample hooks are installed when
- git-init is run, but all of them are disabled by
+ git-init is run, but all of them are disabled by
default. To enable, they need to be made executable.
Read githooks(5) for more details about
each hook.
@@ -515,10 +563,10 @@ info/refs
This file helps dumb transports discover what refs are
available in this repository. If the repository is
published for dumb transports, this file should be
- regenerated by git-update-server-info every time a tag
+ regenerated by git-update-server-info every time a tag
or branch is created or modified. This is normally done
from the hooks/update hook, which is run by the
- git-receive-pack command when you git-push into the
+ git-receive-pack command when you git-push into the
repository.
@@ -542,8 +590,8 @@ info/exclude
This file, by convention among Porcelains, stores the
exclude pattern list. .gitignore is the per-directory
- ignore file. git-status , git-add , git-rm and
- git-clean look at it but the core git commands do not look
+ ignore file. git-status , git-add , git-rm and
+ git-clean look at it but the core git commands do not look
at it. See also: gitignore(5) .
@@ -554,7 +602,7 @@ remotes
Stores shorthands to be used to give URL and default
refnames to interact with remote repository to
- git-fetch , git-pull and git-push commands.
+ git-fetch , git-pull and git-push commands.
@@ -593,26 +641,26 @@ shallow
option to git-clone(1) and git-fetch(1) .
-
+
-SEE ALSO
+SEE ALSO
-GIT
+GIT
-
Part of the git(1) suite.
+
diff --git a/gitrepository-layout.txt b/gitrepository-layout.txt
index ade812e0e..a969b3fbc 100644
--- a/gitrepository-layout.txt
+++ b/gitrepository-layout.txt
@@ -64,7 +64,7 @@ objects/info/packs::
are available in this object store. Whenever a pack is
added or removed, `git update-server-info` should be run
to keep this file up-to-date if the repository is
- published for dumb transports. `git-repack` does this
+ published for dumb transports. 'git-repack' does this
by default.
objects/info/alternates::
@@ -85,7 +85,7 @@ objects/info/http-alternates::
refs::
References are stored in subdirectories of this
- directory. The `git-prune` command knows to keep
+ directory. The 'git-prune' command knows to keep
objects reachable from refs found in this directory and
its subdirectories.
@@ -125,7 +125,7 @@ details.
branches::
A slightly deprecated way to store shorthands to be used
- to specify URL to `git-fetch`, `git-pull` and `git-push`
+ to specify URL to 'git-fetch', 'git-pull' and 'git-push'
commands is to store a file in `branches/` and
give 'name' to these commands in place of 'repository'
argument.
@@ -133,7 +133,7 @@ branches::
hooks::
Hooks are customization scripts used by various git
commands. A handful of sample hooks are installed when
- `git-init` is run, but all of them are disabled by
+ 'git-init' is run, but all of them are disabled by
default. To enable, they need to be made executable.
Read linkgit:githooks[5] for more details about
each hook.
@@ -150,10 +150,10 @@ info/refs::
This file helps dumb transports discover what refs are
available in this repository. If the repository is
published for dumb transports, this file should be
- regenerated by `git-update-server-info` every time a tag
+ regenerated by 'git-update-server-info' every time a tag
or branch is created or modified. This is normally done
from the `hooks/update` hook, which is run by the
- `git-receive-pack` command when you `git-push` into the
+ 'git-receive-pack' command when you 'git-push' into the
repository.
info/grafts::
@@ -167,14 +167,14 @@ info/grafts::
info/exclude::
This file, by convention among Porcelains, stores the
exclude pattern list. `.gitignore` is the per-directory
- ignore file. `git-status`, `git-add`, `git-rm` and
- `git-clean` look at it but the core git commands do not look
+ ignore file. 'git-status', 'git-add', 'git-rm' and
+ 'git-clean' look at it but the core git commands do not look
at it. See also: linkgit:gitignore[5].
remotes::
Stores shorthands to be used to give URL and default
refnames to interact with remote repository to
- `git-fetch`, `git-pull` and `git-push` commands.
+ 'git-fetch', 'git-pull' and 'git-push' commands.
logs::
Records of changes made to refs are stored in this
diff --git a/gittutorial-2.html b/gittutorial-2.html
index c24a9fdbf..522ed1d6b 100644
--- a/gittutorial-2.html
+++ b/gittutorial-2.html
@@ -3,7 +3,7 @@
-
+
gittutorial-2(7)
@@ -272,19 +320,19 @@ gittutorial-2(7) Manual Page
SYNOPSIS
-DESCRIPTION
+DESCRIPTION
-
You should work through gittutorial(7) before reading this tutorial.
-
The goal of this tutorial is to introduce two fundamental pieces of
+
+
The goal of this tutorial is to introduce two fundamental pieces of
git's architecture--the object database and the index file--and to
provide the reader with everything necessary to understand the rest
-of the git documentation.
+of the git documentation.
-The git object database
+The git object database
-
Let's start a new project and create a small amount of history:
+
Let's start a new project and create a small amount of history:
$ mkdir test-project
@@ -300,22 +348,22 @@ $ echo 'hello world!' >file.txt
$ git commit -a -m "add emphasis"
Created commit c4d59f390b9cfd4318117afde11d601c1085f241
-
What are the 40 digits of hex that git responded to the commit with?
-
We saw in part one of the tutorial that commits have names like this.
+
What are the 40 digits of hex that git responded to the commit with?
+
We saw in part one of the tutorial that commits have names like this.
It turns out that every object in the git history is stored under
such a 40-digit hex name. That name is the SHA1 hash of the object's
contents; among other things, this ensures that git will never store
the same data twice (since identical data is given an identical SHA1
name), and that the contents of a git object will never change (since
-that would change the object's name as well).
-
It is expected that the content of the commit object you created while
+that would change the object's name as well).
+
It is expected that the content of the commit object you created while
following the example above generates a different SHA1 hash than
the one shown above because the commit object records the time when
-it was created and the name of the person performing the commit.
-
We can ask git about this particular object with the cat-file
+it was created and the name of the person performing the commit.
+
We can ask git about this particular object with the cat-file
command. Don't copy the 40 hex digits from this example but use those
from your own version. Note that you can shorten it to only a few
-characters to save yourself typing all 40 hex digits:
+characters to save yourself typing all 40 hex digits:
$ git cat-file -t 54196cc2
@@ -327,34 +375,34 @@ committer J. Bruce Fields <bfields@puzzle.fieldses.org> 1143414668 -0500
initial commit
-
A tree can refer to one or more "blob" objects, each corresponding to
+
A tree can refer to one or more "blob" objects, each corresponding to
a file. In addition, a tree can also refer to other tree objects,
thus creating a directory hierarchy. You can examine the contents of
any tree using ls-tree (remember that a long enough initial portion
-of the SHA1 will also work):
+of the SHA1 will also work):
$ git ls-tree 92b8b694
100644 blob 3b18e512dba79e4c8300dd08aeb37f8e728b8dad file.txt
-
Thus we see that this tree has one file in it. The SHA1 hash is a
-reference to that file's data:
+
Thus we see that this tree has one file in it. The SHA1 hash is a
+reference to that file's data:
$ git cat-file -t 3b18e512
blob
-
A "blob" is just file data, which we can also examine with cat-file:
+
A "blob" is just file data, which we can also examine with cat-file:
$ git cat-file blob 3b18e512
hello world
-
Note that this is the old file data; so the object that git named in
+
Note that this is the old file data; so the object that git named in
its response to the initial tree was a tree with a snapshot of the
-directory state that was recorded by the first commit.
-
All of these objects are stored under their SHA1 names inside the git
-directory:
+directory state that was recorded by the first commit.
+
All of these objects are stored under their SHA1 names inside the git
+directory:
$ find .git/objects/
@@ -374,20 +422,20 @@ directory:
.git/objects/c4
.git/objects/c4/d59f390b9cfd4318117afde11d601c1085f241
-
and the contents of these files is just the compressed data plus a
+
and the contents of these files is just the compressed data plus a
header identifying their length and their type. The type is either a
-blob, a tree, a commit, or a tag.
-
The simplest commit to find is the HEAD commit, which we can find
-from .git/HEAD:
+blob, a tree, a commit, or a tag.
+
The simplest commit to find is the HEAD commit, which we can find
+from .git/HEAD:
$ cat .git/HEAD
ref: refs/heads/master
-
As you can see, this tells us which branch we're currently on, and it
+
As you can see, this tells us which branch we're currently on, and it
tells us this by naming a file under the .git directory, which itself
contains a SHA1 name referring to a commit object, which we can
-examine with cat-file:
+examine with cat-file:
$ cat .git/refs/heads/master
@@ -402,7 +450,7 @@ committer J. Bruce Fields <bfields@puzzle.fieldses.org> 1143418702 -0500
add emphasis
-
The "tree" object here refers to the new state of the tree:
+
The "tree" object here refers to the new state of the tree:
$ git ls-tree d0492b36
@@ -410,7 +458,7 @@ add emphasis
$ git cat-file blob a0423896
hello world!
-
and the "parent" object refers to the previous commit:
+
and the "parent" object refers to the previous commit:
$ git cat-file commit 54196cc2
@@ -420,18 +468,18 @@ committer J. Bruce Fields <bfields@puzzle.fieldses.org> 1143414668 -0500
initial commit
-
The tree object is the tree we examined first, and this commit is
-unusual in that it lacks any parent.
-
Most commits have only one parent, but it is also common for a commit
+
The tree object is the tree we examined first, and this commit is
+unusual in that it lacks any parent.
+
Most commits have only one parent, but it is also common for a commit
to have multiple parents. In that case the commit represents a
merge, with the parent references pointing to the heads of the merged
-branches.
-
Besides blobs, trees, and commits, the only remaining type of object
+branches.
+
Besides blobs, trees, and commits, the only remaining type of object
is a "tag", which we won't discuss here; refer to git-tag(1)
-for details.
-
So now we know how git uses the object database to represent a
-project's history:
-
+
So now we know how git uses the object database to represent a
+project's history:
+
-
Note, by the way, that lots of commands take a tree as an argument.
+
+
Note, by the way, that lots of commands take a tree as an argument.
But as we can see above, a tree can be referred to in many different
ways--by the SHA1 name for that tree, by the name of a commit that
refers to the tree, by the name of a branch whose head refers to that
-tree, etc.--and most such commands can accept any of these names.
-
In command synopses, the word "tree-ish" is sometimes used to
-designate such an argument.
+tree, etc.--and most such commands can accept any of these names.
+
In command synopses, the word "tree-ish" is sometimes used to
+designate such an argument.
-The index file
+The index file
-
The primary tool we've been using to create commits is git-commit
+The primary tool we've been using to create commits is git-commit
-a , which creates a commit including every change you've made to
your working tree. But what if you want to commit changes only to
-certain files? Or only certain changes to certain files?
-
If we look at the way commits are created under the cover, we'll see
-that there are more flexible ways creating commits.
-
Continuing with our test-project, let's modify file.txt again:
+certain files? Or only certain changes to certain files?
+If we look at the way commits are created under the cover, we'll see
+that there are more flexible ways creating commits.
+Continuing with our test-project, let's modify file.txt again:
$ echo "hello world, again" >>file.txt
-
but this time instead of immediately making the commit, let's take an
+
but this time instead of immediately making the commit, let's take an
intermediate step, and ask for diffs along the way to keep track of
-what's happening:
+what's happening:
$ git diff
@@ -499,8 +547,8 @@ what's happening:
$ git add file.txt
$ git diff
-
The last diff is empty, but no new commits have been made, and the
-head still doesn't contain the new line:
+
The last diff is empty, but no new commits have been made, and the
+head still doesn't contain the new line:
$ git diff HEAD
@@ -512,10 +560,10 @@ index a042389..513feba 100644
hello world!
+hello world, again
-
So git-diff is comparing against something other than the head.
+
So git-diff is comparing against something other than the head.
The thing that it's comparing against is actually the index file,
which is stored in .git/index in a binary format, but whose contents
-we can examine with ls-files:
+we can examine with ls-files:
$ git ls-files --stage
@@ -526,10 +574,10 @@ $ git cat-file blob 513feba2
hello world!
hello world, again
-
So what our git-add did was store a new blob and then put
+
So what our git-add did was store a new blob and then put
a reference to it in the index file. If we modify the file again,
-we'll see that the new modifications are reflected in the git-diff
-output:
+we'll see that the new modifications are reflected in the
git-diff
+output:
$ echo 'again?' >>file.txt
@@ -542,9 +590,9 @@ index 513feba..ba3da7b 100644
hello world, again
+again?
-
With the right arguments, git-diff can also show us the difference
+
With the right arguments, git-diff can also show us the difference
between the working directory and the last commit, or between the
-index and the last commit:
+index and the last commit:
$ git diff HEAD
@@ -565,10 +613,10 @@ index a042389..513feba 100644
hello world!
+hello world, again
-
At any time, we can create a new commit using git-commit (without
+
At any time, we can create a new commit using git-commit (without
the "-a" option), and verify that the state committed only includes the
changes stored in the index file, not the additional change that is
-still only in our working tree:
+still only in our working tree:
$ git commit -m "repeat"
@@ -582,32 +630,32 @@ index 513feba..ba3da7b 100644
hello world, again
+again?
-
So by default git-commit uses the index to create the commit, not
+
So by default git-commit uses the index to create the commit, not
the working tree; the "-a" option to commit tells it to first update
-the index with all changes in the working tree.
-
Finally, it's worth looking at the effect of git-add on the index
-file:
+the index with all changes in the working tree.
+
Finally, it's worth looking at the effect of git-add on the index
+file:
$ echo "goodbye, world" >closing.txt
$ git add closing.txt
-
The effect of the git-add was to add one entry to the index file:
+
The effect of the git-add was to add one entry to the index file:
$ git ls-files --stage
100644 8b9743b20d4b15be3955fc8d5cd2b09cd2336138 0 closing.txt
100644 513feba2e53ebbd2532419ded848ba19de88ba00 0 file.txt
-
And, as you can see with cat-file, this new entry refers to the
-current contents of the file:
+
And, as you can see with cat-file, this new entry refers to the
+current contents of the file:
$ git cat-file blob 8b9743b2
goodbye, world
-
The "status" command is a useful way to get a quick summary of the
-situation:
+
The "status" command is a useful way to get a quick summary of the
+situation:
$ git status
@@ -623,54 +671,54 @@ situation:
# modified: file.txt
#
-
Since the current state of closing.txt is cached in the index file,
+
Since the current state of closing.txt is cached in the index file,
it is listed as "Changes to be committed". Since file.txt has
changes in the working directory that aren't reflected in the index,
it is marked "changed but not updated". At this point, running "git
commit" would create a commit that added closing.txt (with its new
-contents), but that didn't modify file.txt.
-
Also, note that a bare git diff shows the changes to file.txt, but
+contents), but that didn't modify file.txt.
+
Also, note that a bare git diff shows the changes to file.txt, but
not the addition of closing.txt, because the version of closing.txt
-in the index file is identical to the one in the working directory.
-
In addition to being the staging area for new commits, the index file
+in the index file is identical to the one in the working directory.
+
In addition to being the staging area for new commits, the index file
is also populated from the object database when checking out a
branch, and is used to hold the trees involved in a merge operation.
See gitcore-tutorial(7) and the relevant man
-pages for details.
+pages for details.
-What next?
+What next?
-
At this point you should know everything necessary to read the man
+
At this point you should know everything necessary to read the man
pages for any of the git commands; one good place to start would be
with the commands mentioned in Everyday git . You
-should be able to find any unknown jargon in gitglossary(7) .
-
The Git User's Manual provides a more
-comprehensive introduction to git.
-
gitcvs-migration(7) explains how to
+should be able to find any unknown jargon in gitglossary(7) .
+
+
gitcvs-migration(7) explains how to
import a CVS repository into git, and shows how to use git in a
-CVS-like way.
-
For some interesting examples of git use, see the
-howtos .
-
For git developers, gitcore-tutorial(7) goes
+CVS-like way.
+
For some interesting examples of git use, see the
+howtos .
+
For git developers, gitcore-tutorial(7) goes
into detail on the lower-level git mechanisms involved in, for
-example, creating a new commit.
+example, creating a new commit.
-SEE ALSO
+SEE ALSO
-GIT
+GIT
-
Part of the git(1) suite.
+
diff --git a/gittutorial-2.txt b/gittutorial-2.txt
index 6c93445cc..660904686 100644
--- a/gittutorial-2.txt
+++ b/gittutorial-2.txt
@@ -255,7 +255,7 @@ index a042389..513feba 100644
+hello world, again
------------------------------------------------
-So `git-diff` is comparing against something other than the head.
+So 'git-diff' is comparing against something other than the head.
The thing that it's comparing against is actually the index file,
which is stored in .git/index in a binary format, but whose contents
we can examine with ls-files:
@@ -270,9 +270,9 @@ hello world!
hello world, again
------------------------------------------------
-So what our `git-add` did was store a new blob and then put
+So what our 'git-add' did was store a new blob and then put
a reference to it in the index file. If we modify the file again,
-we'll see that the new modifications are reflected in the `git-diff`
+we'll see that the new modifications are reflected in the 'git-diff'
output:
------------------------------------------------
@@ -287,7 +287,7 @@ index 513feba..ba3da7b 100644
+again?
------------------------------------------------
-With the right arguments, `git-diff` can also show us the difference
+With the right arguments, 'git-diff' can also show us the difference
between the working directory and the last commit, or between the
index and the last commit:
@@ -311,7 +311,7 @@ index a042389..513feba 100644
+hello world, again
------------------------------------------------
-At any time, we can create a new commit using `git-commit` (without
+At any time, we can create a new commit using 'git-commit' (without
the "-a" option), and verify that the state committed only includes the
changes stored in the index file, not the additional change that is
still only in our working tree:
@@ -329,11 +329,11 @@ index 513feba..ba3da7b 100644
+again?
------------------------------------------------
-So by default `git-commit` uses the index to create the commit, not
+So by default 'git-commit' uses the index to create the commit, not
the working tree; the "-a" option to commit tells it to first update
the index with all changes in the working tree.
-Finally, it's worth looking at the effect of `git-add` on the index
+Finally, it's worth looking at the effect of 'git-add' on the index
file:
------------------------------------------------
@@ -341,7 +341,7 @@ $ echo "goodbye, world" >closing.txt
$ git add closing.txt
------------------------------------------------
-The effect of the `git-add` was to add one entry to the index file:
+The effect of the 'git-add' was to add one entry to the index file:
------------------------------------------------
$ git ls-files --stage
diff --git a/gittutorial.html b/gittutorial.html
index eddcf15b9..b77223e5f 100644
--- a/gittutorial.html
+++ b/gittutorial.html
@@ -3,7 +3,7 @@
-
+
gittutorial(7)
@@ -272,79 +320,79 @@ gittutorial(7) Manual Page
SYNOPSIS
-DESCRIPTION
+DESCRIPTION
-
This tutorial explains how to import a new project into git, make
-changes to it, and share changes with other developers.
-
If you are instead primarily interested in using git to fetch a project,
+
This tutorial explains how to import a new project into git, make
+changes to it, and share changes with other developers.
+
If you are instead primarily interested in using git to fetch a project,
for example, to test the latest version, you may prefer to start with
-the first two chapters of The Git User's Manual .
-
First, note that you can get documentation for a command such as
-git log --graph with:
+the first two chapters of
The Git User's Manual .
+
First, note that you can get documentation for a command such as
+git log --graph with:
-
It is a good idea to introduce yourself to git with your name and
+
It is a good idea to introduce yourself to git with your name and
public email address before doing any operation. The easiest
-way to do so is:
+way to do so is:
$ git config --global user.name "Your Name Comes Here"
$ git config --global user.email you@yourdomain.example.com
-Importing a new project
+Importing a new project
-
Assume you have a tarball project.tar.gz with your initial work. You
-can place it under git revision control as follows.
+
Assume you have a tarball project.tar.gz with your initial work. You
+can place it under git revision control as follows.
$ tar xzf project.tar.gz
$ cd project
$ git init
-
Git will reply
+
Initialized empty Git repository in .git/
-
You've now initialized the working directory--you may notice a new
-directory created, named ".git".
-
Next, tell git to take a snapshot of the contents of all files under the
-current directory (note the . ), with git-add :
+
You've now initialized the working directory--you may notice a new
+directory created, named ".git".
+
Next, tell git to take a snapshot of the contents of all files under the
+current directory (note the . ), with git-add :
-
This snapshot is now stored in a temporary staging area which git calls
+
This snapshot is now stored in a temporary staging area which git calls
the "index". You can permanently store the contents of the index in the
-repository with git-commit :
+repository with
git-commit :
-
This will prompt you for a commit message. You've now stored the first
-version of your project in git.
+
This will prompt you for a commit message. You've now stored the first
+version of your project in git.
-Making changes
+Making changes
-
Modify some files, then add their updated contents to the index:
+
Modify some files, then add their updated contents to the index:
$ git add file1 file2 file3
-
You are now ready to commit. You can see what is about to be committed
-using git-diff with the --cached option:
+
You are now ready to commit. You can see what is about to be committed
+using git-diff with the --cached option:
-
(Without --cached, git-diff will show you any changes that
+
(Without --cached, git-diff will show you any changes that
you've made but not yet added to the index.) You can also get a brief
-summary of the situation with git-status :
+summary of the situation with
git-status :
$ git status
@@ -357,254 +405,254 @@ summary of the situation with git-status :
# modified: file3
#
-
If you need to make any further adjustments, do so now, and then add any
-newly modified content to the index. Finally, commit your changes with:
+
If you need to make any further adjustments, do so now, and then add any
+newly modified content to the index. Finally, commit your changes with:
-
This will again prompt you for a message describing the change, and then
-record a new version of the project.
-
Alternatively, instead of running git-add beforehand, you can use
+
This will again prompt you for a message describing the change, and then
+record a new version of the project.
+
Alternatively, instead of running git-add beforehand, you can use
-
which will automatically notice any modified (but not new) files, add
-them to the index, and commit, all in one step.
-
A note on commit messages: Though not required, it's a good idea to
+
which will automatically notice any modified (but not new) files, add
+them to the index, and commit, all in one step.
+
A note on commit messages: Though not required, it's a good idea to
begin the commit message with a single short (less than 50 character)
line summarizing the change, followed by a blank line and then a more
thorough description. Tools that turn commits into email, for
example, use the first line on the Subject: line and the rest of the
-commit in the body.
+commit in the body.
-Git tracks content not files
+Git tracks content not files
-
Many revision control systems provide an add command that tells the
+
Many revision control systems provide an add command that tells the
system to start tracking changes to a new file. Git's add command
-does something simpler and more powerful: git-add is used both for new
+does something simpler and more powerful: git-add is used both for new
and newly modified files, and in both cases it takes a snapshot of the
given files and stages that content in the index, ready for inclusion in
-the next commit.
+the next commit.
-Viewing project history
+Viewing project history
-
At any point you can view the history of your changes using
+
At any point you can view the history of your changes using
-
If you also want to see complete diffs at each step, use
+
If you also want to see complete diffs at each step, use
-
Often the overview of the change is useful to get a feel of
-each step
+
Often the overview of the change is useful to get a feel of
+each step
$ git log --stat --summary
-Managing branches
+Managing branches
-
A single git repository can maintain multiple branches of
-development. To create a new branch named "experimental", use
+
A single git repository can maintain multiple branches of
+development. To create a new branch named "experimental", use
$ git branch experimental
-
If you now run
+
-
you'll get a list of all existing branches:
+
you'll get a list of all existing branches:
-
The "experimental" branch is the one you just created, and the
+
The "experimental" branch is the one you just created, and the
"master" branch is a default branch that was created for you
automatically. The asterisk marks the branch you are currently on;
-type
+type
$ git checkout experimental
-
to switch to the experimental branch. Now edit a file, commit the
-change, and switch back to the master branch:
+
to switch to the experimental branch. Now edit a file, commit the
+change, and switch back to the master branch:
(edit file)
$ git commit -a
$ git checkout master
-
Check that the change you made is no longer visible, since it was
-made on the experimental branch and you're back on the master branch.
-
You can make a different change on the master branch:
+
Check that the change you made is no longer visible, since it was
+made on the experimental branch and you're back on the master branch.
+
You can make a different change on the master branch:
(edit file)
$ git commit -a
-
at this point the two branches have diverged, with different changes
-made in each. To merge the changes made in experimental into master, run
+
at this point the two branches have diverged, with different changes
+made in each. To merge the changes made in experimental into master, run
-
If the changes don't conflict, you're done. If there are conflicts,
-markers will be left in the problematic files showing the conflict;
+
If the changes don't conflict, you're done. If there are conflicts,
+markers will be left in the problematic files showing the conflict;
-
will show this. Once you've edited the files to resolve the
-conflicts,
+
will show this. Once you've edited the files to resolve the
+conflicts,
-
will commit the result of the merge. Finally,
+
will commit the result of the merge. Finally,
-
will show a nice graphical representation of the resulting history.
-
At this point you could delete the experimental branch with
+
will show a nice graphical representation of the resulting history.
+
At this point you could delete the experimental branch with
$ git branch -d experimental
-
This command ensures that the changes in the experimental branch are
-already in the current branch.
-
If you develop on a branch crazy-idea, then regret it, you can always
-delete the branch with
+
This command ensures that the changes in the experimental branch are
+already in the current branch.
+
If you develop on a branch crazy-idea, then regret it, you can always
+delete the branch with
$ git branch -D crazy-idea
-
Branches are cheap and easy, so this is a good way to try something
-out.
+
Branches are cheap and easy, so this is a good way to try something
+out.
-Using git for collaboration
+Using git for collaboration
-
Suppose that Alice has started a new project with a git repository in
+
Suppose that Alice has started a new project with a git repository in
/home/alice/project, and that Bob, who has a home directory on the
-same machine, wants to contribute.
-
Bob begins with:
+same machine, wants to contribute.
+
$ git clone /home/alice/project myrepo
-
This creates a new directory "myrepo" containing a clone of Alice's
+
This creates a new directory "myrepo" containing a clone of Alice's
repository. The clone is on an equal footing with the original
-project, possessing its own copy of the original project's history.
-
Bob then makes some changes and commits them:
+project, possessing its own copy of the original project's history.
+
Bob then makes some changes and commits them:
(edit files)
$ git commit -a
(repeat as necessary)
-
When he's ready, he tells Alice to pull changes from the repository
-at /home/bob/myrepo. She does this with:
+
When he's ready, he tells Alice to pull changes from the repository
+at /home/bob/myrepo. She does this with:
$ cd /home/alice/project
$ git pull /home/bob/myrepo master
-
This merges the changes from Bob's "master" branch into Alice's
+
This merges the changes from Bob's "master" branch into Alice's
current branch. If Alice has made her own changes in the meantime,
then she may need to manually fix any conflicts. (Note that the
"master" argument in the above command is actually unnecessary, as it
-is the default.)
-
The "pull" command thus performs two operations: it fetches changes
-from a remote branch, then merges them into the current branch.
-
When you are working in a small closely knit group, it is not
+is the default.)
+
The "pull" command thus performs two operations: it fetches changes
+from a remote branch, then merges them into the current branch.
+
When you are working in a small closely knit group, it is not
unusual to interact with the same repository over and over
again. By defining remote repository shorthand, you can make
-it easier:
+it easier:
$ git remote add bob /home/bob/myrepo
-
With this, Alice can perform the first operation alone using the
-git-fetch command without merging them with her own branch,
-using:
+
With this, Alice can perform the first operation alone using the
+git-fetch command without merging them with her own branch,
+using:
-
Unlike the longhand form, when Alice fetches from Bob using a
-remote repository shorthand set up with git-remote , what was
+
Unlike the longhand form, when Alice fetches from Bob using a
+remote repository shorthand set up with git-remote , what was
fetched is stored in a remote tracking branch, in this case
-bob/master . So after this:
+
bob/master . So after this:
$ git log -p master..bob/master
-
shows a list of all the changes that Bob made since he branched from
-Alice's master branch.
-
After examining those changes, Alice
-could merge the changes into her master branch:
+
shows a list of all the changes that Bob made since he branched from
+Alice's master branch.
+
After examining those changes, Alice
+could merge the changes into her master branch:
-
This merge can also be done by pulling from her own remote
-tracking branch , like this:
+
This merge can also be done by pulling from her own remote
+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 command line.
-
Later, Bob can update his repo with Alice's latest changes using
+
Note that git pull always merges into the current branch,
+regardless of what else is given on the command line.
+
Later, Bob can update his repo with Alice's latest changes using
-
Note that he doesn't need to give the path to Alice's repository;
+
Note that he doesn't need to give the path to Alice's repository;
when Bob cloned Alice's repository, git stored the location of her
repository in the repository configuration, and that location is
-used for pulls:
+used for pulls:
$ git config --get remote.origin.url
/home/alice/project
-
(The complete configuration created by git-clone is visible using
+
(The complete configuration created by git-clone is visible using
git config -l , and the git-config(1) man page
-explains the meaning of each option.)
-
Git also keeps a pristine copy of Alice's master branch under the
-name "origin/master":
+explains the meaning of each option.)
+
Git also keeps a pristine copy of Alice's master branch under the
+name "origin/master":
$ git branch -r
origin/master
-
If Bob later decides to work from a different host, he can still
-perform clones and pulls using the ssh protocol:
+
If Bob later decides to work from a different host, he can still
+perform clones and pulls using the ssh protocol:
$ git clone alice.org:/home/alice/project myrepo
-
Alternatively, git has a native protocol, or can use rsync or http;
-see git-pull(1) for details.
-
Git can also be used in a CVS-like mode, with a central repository
+
Alternatively, git has a native protocol, or can use rsync or http;
+see git-pull(1) for details.
+
-Exploring history
+Exploring history
-
Git history is represented as a series of interrelated commits. We
-have already seen that the git-log command can list those commits.
+
Git history is represented as a series of interrelated commits. We
+have already seen that the git-log command can list those commits.
Note that first line of each git log entry also gives a name for the
-commit:
+commit:
$ git log
@@ -614,14 +662,14 @@ Date: Tue May 16 17:18:22 2006 -0700
merge-base: Clarify the comments on post processing.
-
We can give this name to git-show to see the details about this
-commit.
+
We can give this name to git-show to see the details about this
+commit.
$ git show c82a22c39cbc32576f64f5c6b3f24b99ea8149c7
-
But there are other ways to refer to commits. You can use any initial
-part of the name that is long enough to uniquely identify the commit:
+
But there are other ways to refer to commits. You can use any initial
+part of the name that is long enough to uniquely identify the commit:
$ git show c82a22c39c # the first few characters of the name are
@@ -629,31 +677,31 @@ part of the name that is long enough to uniquely identify the commit:
$ git show HEAD # the tip of the current branch
$ git show experimental # the tip of the "experimental" branch
-
Every commit usually has one "parent" commit
-which points to the previous state of the project:
+
Every commit usually has one "parent" commit
+which points to the previous state of the project:
$ git show HEAD^ # to see the parent of HEAD
$ git show HEAD^^ # to see the grandparent of HEAD
$ git show HEAD~4 # to see the great-great grandparent of HEAD
-
Note that merge commits may have more than one parent:
+
Note that merge commits may have more than one parent:
$ git show HEAD^1 # show the first parent of HEAD (same as HEAD^)
$ git show HEAD^2 # show the second parent of HEAD
-
You can also give commits names of your own; after running
+
You can also give commits names of your own; after running
$ git tag v2.5 1b2e1d63ff
-
you can refer to 1b2e1d63ff by the name "v2.5". If you intend to
+
you can refer to 1b2e1d63ff by the name "v2.5". If you intend to
share this name with other people (for example, to identify a release
version), you should create a "tag" object, and perhaps sign it; see
-git-tag(1) for details.
-
Any git command that needs to know a commit can take any of these
-names. For example:
+
git-tag(1) for details.
+
Any git command that needs to know a commit can take any of these
+names. For example:
$ git diff v2.5 HEAD # compare the current HEAD to v2.5
@@ -662,30 +710,30 @@ $ git branch stable v2.5 # start a new branch named "stable" based
$ git reset --hard HEAD^ # reset your current branch and working
# directory to its state at HEAD^
-
Be careful with that last command: in addition to losing any changes
+
Be careful with that last command: in addition to losing any changes
in the working directory, it will also remove all later commits from
this branch. If this branch is the only branch containing those
-commits, they will be lost. Also, don't use git-reset on a
+commits, they will be lost. Also, don't use git-reset on a
publicly-visible branch that other developers pull from, as it will
force needless merges on other developers to clean up the history.
-If you need to undo changes that you have pushed, use git-revert
-instead.
-
The git-grep command can search for strings in any version of your
-project, so
+If you need to undo changes that you have pushed, use
git-revert
+instead.
+
The git-grep command can search for strings in any version of your
+project, so
-
searches for all occurrences of "hello" in v2.5.
-
If you leave out the commit name, git-grep will search any of the
-files it manages in your current directory. So
+
searches for all occurrences of "hello" in v2.5.
+
If you leave out the commit name, git-grep will search any of the
+files it manages in your current directory. So
-
is a quick way to search just the files that are tracked by git.
-
Many git commands also take sets of commits, which can be specified
-in a number of ways. Here are some examples with git-log :
+
is a quick way to search just the files that are tracked by git.
+
Many git commands also take sets of commits, which can be specified
+in a number of ways. Here are some examples with git-log :
$ git log v2.5..v2.6 # commits between v2.5 and v2.6
@@ -694,57 +742,57 @@ $ git log --since="2 weeks ago" # commits from the last 2 weeks
$ git log v2.5.. Makefile # commits since v2.5 which modify
# Makefile
-
You can also give git-log a "range" of commits where the first is not
+
You can also give git-log a "range" of commits where the first is not
necessarily an ancestor of the second; for example, if the tips of
the branches "stable-release" and "master" diverged from a common
-commit some time ago, then
+commit some time ago, then
$ git log stable..experimental
-
will list commits made in the experimental branch but not in the
-stable branch, while
+
will list commits made in the experimental branch but not in the
+stable branch, while
$ git log experimental..stable
-
will show the list of commits made on the stable branch but not
-the experimental branch.
-
The git-log command has a weakness: it must present commits in a
+
will show the list of commits made on the stable branch but not
+the experimental branch.
+
The git-log command has a weakness: it must present commits in a
list. When the history has lines of development that diverged and
-then merged back together, the order in which git-log presents
-those commits is meaningless.
-
Most projects with multiple contributors (such as the linux kernel,
-or git itself) have frequent merges, and gitk does a better job of
-visualizing their history. For example,
+then merged back together, the order in which
git-log presents
+those commits is meaningless.
+
Most projects with multiple contributors (such as the linux kernel,
+or git itself) have frequent merges, and gitk does a better job of
+visualizing their history. For example,
$ gitk --since="2 weeks ago" drivers/
-
allows you to browse any commits from the last 2 weeks of commits
+
allows you to browse any commits from the last 2 weeks of commits
that modified files under the "drivers" directory. (Note: you can
adjust gitk's fonts by holding down the control key while pressing
-"-" or "+".)
-
Finally, most commands that take filenames will optionally allow you
+"-" or "+".)
+
Finally, most commands that take filenames will optionally allow you
to precede any filename by a commit, to specify a particular version
-of the file:
+of the file:
$ git diff v2.5:Makefile HEAD:Makefile.in
-
You can also use git-show to see any such file:
+
You can also use git-show to see any such file:
-Next Steps
+Next Steps
-
This tutorial should be enough to perform basic distributed revision
+
This tutorial should be enough to perform basic distributed revision
control for your projects. However, to fully understand the depth
and power of git you need to understand two simple ideas on which it
-is based:
-
+
The object database is the rather elegant system used to
@@ -759,13 +807,13 @@ The index file is a cache of the state of a directory tree,
hold the various trees involved in a merge.
-
-
Part two of this tutorial explains the object
+
+
Part two of this tutorial explains the object
database, the index file, and a few other odds and ends that you'll
-need to make the most of git. You can find it at gittutorial-2(7) .
-
If you don't want to continue with that right away, a few other
-digressions that may be interesting at this point are:
-
+
If you don't want to continue with that right away, a few other
+digressions that may be interesting at this point are:
+
-SEE ALSO
+SEE ALSO
-GIT
+GIT
-
Part of the git(1) suite.
+
diff --git a/gittutorial.txt b/gittutorial.txt
index 036a27c41..e71b56117 100644
--- a/gittutorial.txt
+++ b/gittutorial.txt
@@ -58,7 +58,7 @@ You've now initialized the working directory--you may notice a new
directory created, named ".git".
Next, tell git to take a snapshot of the contents of all files under the
-current directory (note the '.'), with `git-add`:
+current directory (note the '.'), with 'git-add':
------------------------------------------------
$ git add .
@@ -66,7 +66,7 @@ $ git add .
This snapshot is now stored in a temporary staging area which git calls
the "index". You can permanently store the contents of the index in the
-repository with `git-commit`:
+repository with 'git-commit':
------------------------------------------------
$ git commit
@@ -85,15 +85,15 @@ $ git add file1 file2 file3
------------------------------------------------
You are now ready to commit. You can see what is about to be committed
-using `git-diff` with the --cached option:
+using 'git-diff' with the --cached option:
------------------------------------------------
$ git diff --cached
------------------------------------------------
-(Without --cached, `git-diff` will show you any changes that
+(Without --cached, 'git-diff' will show you any changes that
you've made but not yet added to the index.) You can also get a brief
-summary of the situation with `git-status`:
+summary of the situation with 'git-status':
------------------------------------------------
$ git status
@@ -117,7 +117,7 @@ $ git commit
This will again prompt you for a message describing the change, and then
record a new version of the project.
-Alternatively, instead of running `git-add` beforehand, you can use
+Alternatively, instead of running 'git-add' beforehand, you can use
------------------------------------------------
$ git commit -a
@@ -138,7 +138,7 @@ Git tracks content not files
Many revision control systems provide an `add` command that tells the
system to start tracking changes to a new file. Git's `add` command
-does something simpler and more powerful: `git-add` is used both for new
+does something simpler and more powerful: 'git-add' is used both for new
and newly modified files, and in both cases it takes a snapshot of the
given files and stages that content in the index, ready for inclusion in
the next commit.
@@ -316,7 +316,7 @@ $ git remote add bob /home/bob/myrepo
------------------------------------------------
With this, Alice can perform the first operation alone using the
-`git-fetch` command without merging them with her own branch,
+'git-fetch' command without merging them with her own branch,
using:
-------------------------------------
@@ -324,7 +324,7 @@ $ git fetch bob
-------------------------------------
Unlike the longhand form, when Alice fetches from Bob using a
-remote repository shorthand set up with `git-remote`, what was
+remote repository shorthand set up with 'git-remote', what was
fetched is stored in a remote tracking branch, in this case
`bob/master`. So after this:
@@ -368,7 +368,7 @@ $ git config --get remote.origin.url
/home/alice/project
-------------------------------------
-(The complete configuration created by `git-clone` is visible using
+(The complete configuration created by 'git-clone' is visible using
`git config -l`, and the linkgit:git-config[1] man page
explains the meaning of each option.)
@@ -398,7 +398,7 @@ Exploring history
-----------------
Git history is represented as a series of interrelated commits. We
-have already seen that the `git-log` command can list those commits.
+have already seen that the 'git-log' command can list those commits.
Note that first line of each git log entry also gives a name for the
commit:
@@ -411,7 +411,7 @@ Date: Tue May 16 17:18:22 2006 -0700
merge-base: Clarify the comments on post processing.
-------------------------------------
-We can give this name to `git-show` to see the details about this
+We can give this name to 'git-show' to see the details about this
commit.
-------------------------------------
@@ -469,13 +469,13 @@ $ git reset --hard HEAD^ # reset your current branch and working
Be careful with that last command: in addition to losing any changes
in the working directory, it will also remove all later commits from
this branch. If this branch is the only branch containing those
-commits, they will be lost. Also, don't use `git-reset` on a
+commits, they will be lost. Also, don't use 'git-reset' on a
publicly-visible branch that other developers pull from, as it will
force needless merges on other developers to clean up the history.
-If you need to undo changes that you have pushed, use `git-revert`
+If you need to undo changes that you have pushed, use 'git-revert'
instead.
-The `git-grep` command can search for strings in any version of your
+The 'git-grep' command can search for strings in any version of your
project, so
-------------------------------------
@@ -484,7 +484,7 @@ $ git grep "hello" v2.5
searches for all occurrences of "hello" in v2.5.
-If you leave out the commit name, `git-grep` will search any of the
+If you leave out the commit name, 'git-grep' will search any of the
files it manages in your current directory. So
-------------------------------------
@@ -494,7 +494,7 @@ $ git grep "hello"
is a quick way to search just the files that are tracked by git.
Many git commands also take sets of commits, which can be specified
-in a number of ways. Here are some examples with `git-log`:
+in a number of ways. Here are some examples with 'git-log':
-------------------------------------
$ git log v2.5..v2.6 # commits between v2.5 and v2.6
@@ -504,7 +504,7 @@ $ git log v2.5.. Makefile # commits since v2.5 which modify
# Makefile
-------------------------------------
-You can also give `git-log` a "range" of commits where the first is not
+You can also give 'git-log' a "range" of commits where the first is not
necessarily an ancestor of the second; for example, if the tips of
the branches "stable-release" and "master" diverged from a common
commit some time ago, then
@@ -523,13 +523,13 @@ $ git log experimental..stable
will show the list of commits made on the stable branch but not
the experimental branch.
-The `git-log` command has a weakness: it must present commits in a
+The 'git-log' command has a weakness: it must present commits in a
list. When the history has lines of development that diverged and
-then merged back together, the order in which `git-log` presents
+then merged back together, the order in which 'git-log' presents
those commits is meaningless.
Most projects with multiple contributors (such as the linux kernel,
-or git itself) have frequent merges, and `gitk` does a better job of
+or git itself) have frequent merges, and 'gitk' does a better job of
visualizing their history. For example,
-------------------------------------
@@ -549,7 +549,7 @@ of the file:
$ git diff v2.5:Makefile HEAD:Makefile.in
-------------------------------------
-You can also use `git-show` to see any such file:
+You can also use 'git-show' to see any such file:
-------------------------------------
$ git show v2.5:Makefile
diff --git a/i18n.txt b/i18n.txt
index 1e188e6e7..fb0d7da56 100644
--- a/i18n.txt
+++ b/i18n.txt
@@ -21,7 +21,7 @@ project find it more convenient to use legacy encodings, git
does not forbid it. However, there are a few things to keep in
mind.
-. `git-commit-tree` (hence, `git-commit` which uses it) issues
+. 'git-commit-tree' (hence, 'git-commit' which uses it) issues
a warning if the commit log message given to it does not look
like a valid UTF-8 string, unless you explicitly say your
project uses a legacy encoding. The way to say this is to
@@ -37,7 +37,7 @@ of `i18n.commitencoding` in its `encoding` header. This is to
help other people who look at them later. Lack of this header
implies that the commit log message is encoded in UTF-8.
-. `git-log`, `git-show` and friends looks at the `encoding`
+. 'git-log', 'git-show' and friends looks at the `encoding`
header of a commit object, and tries to re-code the log
message into UTF-8 unless otherwise specified. You can
specify the desired output encoding with
diff --git a/merge-options.txt b/merge-options.txt
index ffbc6e986..007909a82 100644
--- a/merge-options.txt
+++ b/merge-options.txt
@@ -56,5 +56,5 @@
Use the given merge strategy; can be supplied more than
once to specify them in the order they should be tried.
If there is no `-s` option, a built-in list of strategies
- is used instead (`git-merge-recursive` when merging a single
- head, `git-merge-octopus` otherwise).
+ is used instead ('git-merge-recursive' when merging a single
+ head, 'git-merge-octopus' otherwise).
diff --git a/pretty-formats.txt b/pretty-formats.txt
index ec3755579..69e6d2fa4 100644
--- a/pretty-formats.txt
+++ b/pretty-formats.txt
@@ -30,7 +30,7 @@ This is designed to be as compact as possible.
commit
Author:
- Date:
+ Date:
@@ -50,9 +50,9 @@ This is designed to be as compact as possible.
commit
Author:
- AuthorDate:
+ AuthorDate:
Commit:
- CommitDate:
+ CommitDate:
@@ -62,7 +62,7 @@ This is designed to be as compact as possible.
From
From:
- Date:
+ Date:
Subject: [PATCH]
diff --git a/pull-fetch-param.txt b/pull-fetch-param.txt
index cbee36994..00a8d2104 100644
--- a/pull-fetch-param.txt
+++ b/pull-fetch-param.txt
@@ -32,7 +32,7 @@ must know this is the expected usage pattern for a branch.
[NOTE]
You never do your own development on branches that appear
on the right hand side of a colon on `Pull:` lines;
-they are to be updated by `git-fetch`. If you intend to do
+they are to be updated by 'git-fetch'. If you intend to do
development derived from a remote branch `B`, have a `Pull:`
line to track it (i.e. `Pull: B:remote-B`), and have a separate
branch `my-B` to do your development on top of it. The latter
@@ -44,13 +44,13 @@ on the remote branch, merge it into your development branch with
+
[NOTE]
There is a difference between listing multiple
-directly on `git-pull` command line and having multiple
+directly on 'git-pull' command line and having multiple
`Pull:` lines for a and running
-`git-pull` command without any explicit parameters.
+'git-pull' command without any explicit parameters.
listed explicitly on the command line are always
merged into the current branch after fetching. In other words,
if you list more than one remote refs, you would be making
-an Octopus. While `git-pull` run without any explicit
+an Octopus. While 'git-pull' run without any explicit
parameter takes default s from `Pull:` lines, it
merges only the first found into the current branch,
after fetching all the remote refs. This is because making an
diff --git a/urls-remotes.txt b/urls-remotes.txt
index 99753006e..504ae8a53 100644
--- a/urls-remotes.txt
+++ b/urls-remotes.txt
@@ -49,8 +49,8 @@ following format:
------------
-`Push:` lines are used by `git-push` and
-`Pull:` lines are used by `git-pull` and `git-fetch`.
+`Push:` lines are used by 'git-push' and
+`Pull:` lines are used by 'git-pull' and 'git-fetch'.
Multiple `Push:` and `Pull:` lines may
be specified for additional branch mappings.
diff --git a/user-manual.html b/user-manual.html
index 3c8d094be..974ed6ecb 100644
--- a/user-manual.html
+++ b/user-manual.html
@@ -1,13 +1,13 @@
-Git User's Manual (for version 1.5.3 or newer) Git User's Manual (for version 1.5.3 or newer)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
+
Git User's Manual (for version 1.5.3 or newer) Git User's Manual (for version 1.5.3 or newer)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
regressions, and so on.
People needing to do actual development will also want to read
-Chapter 3, Developing with git and Chapter 4, Sharing development with others .
Further chapters cover more specialized topics.
Comprehensive reference documentation is available through the man
-pages. For a command such as "git clone <repo>", just use
See also Appendix A, Git Quick Reference for a brief overview of git commands,
-without any explanation.
Finally, see Appendix B, Notes and todo list for this manual for ways that you can help make this manual more
+Chapter 3, Developing with git and Chapter 4, Sharing development with others .
Further chapters cover more specialized topics.
Comprehensive reference documentation is available through the man
+pages. For a command such as "git clone <repo>", just use
See also Appendix A, Git Quick Reference for a brief overview of git commands,
+without any explanation.
Finally, see Appendix B, Notes and todo list for this manual for ways that you can help make this manual more
complete.
Chapter 1. Repositories and Branches How to get a git repositoryIt 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 git-clone(1) command to
+read this manual.
The best way to get one is by using the 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):
$ git clone git://git.kernel.org/pub/scm/git/git.git
@@ -16,23 +16,23 @@ $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.
will only need to clone once.
The clone command creates a new directory named after the project ("git"
or "linux-2.6" in the examples above). After you cd into this
directory, you will see that it contains a copy of the project files,
-called the working tree , together with a special
+called the working tree , together with a special
top-level directory named ".git", which contains all the information
about the history of the project.
How to check out a different version of a projectGit 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 commit .
Those snapshots aren't necessarily all arranged in a single line from
+version is called a commit .
Those snapshots aren't necessarily all arranged in a single line from
oldest to newest; instead, work may simultaneously proceed along
-parallel lines of development, called branches , which may
+parallel lines of development, called branches , which may
merge and diverge.
A single git repository can track development on multiple branches. It
-does this by keeping a list of heads which reference the
-latest commit on each branch; the git-branch(1) command shows
+does this by keeping a list of heads which reference the
+latest commit on each branch; the git-branch(1) command shows
you the list of branch heads:
A freshly cloned repository contains a single branch head, by default
named "master", with the working directory initialized to the state of
-the project referred to by that branch head.
Most projects also use tags . Tags, like heads, are
+the project referred to by that branch head.
Most projects also use tags . Tags, like heads, are
references into the project's history, and can be listed using the
-git-tag(1) command:
$ git tag -l
+git-tag(1) command:
$ git tag -l
v2.6.11
v2.6.11-tree
v2.6.12
@@ -44,8 +44,8 @@ v2.6.12-rc6
v2.6.13
...
Tags are expected to always point at the same version of a project,
while heads are expected to advance as development progresses.
Create a new branch head pointing to one of these versions and check it
-out using git-checkout(1) :
$ git checkout -b new v2.6.13
The working directory then reflects the contents that the project had
-when it was tagged v2.6.13, and git-branch(1) shows two
+out using git-checkout(1) :
$ git checkout -b new v2.6.13
The working directory then reflects the contents that the project had
+when it was tagged v2.6.13, and git-branch(1) shows two
branches, with an asterisk marking the currently checked-out branch:
$ git branch
  master
*Â new
If you decide that you'd rather see version 2.6.17, you can modify
@@ -53,7 +53,7 @@ the current branch to point at v2.6.17 instead, with
Understanding History: CommitsEvery change in the history of a project is represented by a commit.
-The git-show(1) command shows the most recent commit on the
+The git-show(1) command shows the most recent commit on the
current branch:
$ git show
commit 17cf781661e6d38f737f15f53ab552f1e95960d7
Author: Linus Torvalds <torvalds@ppc970.osdl.org.(none)>
@@ -85,7 +85,7 @@ example in email), then you are guaranteed that name will refer to the same
commit in their repository that it does in yours (assuming their repository
has that commit at all). Since the object name is computed as a hash over the
contents of the commit, you are guaranteed that the commit can never change
-without its name also changing.
In fact, in Chapter 7, Git concepts we shall see that everything stored in git
+without its name also changing.
In fact, in Chapter 7, Git concepts we shall see that everything stored in git
history, including file data and directory contents, is stored in an object
with a name that is a hash of its contents.
Understanding history: commits, parents, and reachabilityEvery commit (except the very first commit in a project) also has a
parent commit which shows what happened before this commit.
@@ -95,7 +95,7 @@ development to diverge and then reconverge, and the point where two
lines of development reconverge is called a "merge". The commit
representing a merge can therefore have more than one parent, with
each parent representing the most recent commit on one of the lines
-of development leading to that point.
The best way to see how this works is using the gitk(1)
+of development leading to that point.
The best way to see how this works is using the gitk(1)
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
@@ -174,7 +174,7 @@ make up a name for the new branch. You can still create a new branch
of the HEAD in the repository that you cloned from. That repository
may also have had other branches, though, and your local repository
keeps branches which track each of those remote branches, which you
-can view using the "-r" option to git-branch(1) :
$ git branch -r
+can view using the "-r" option to git-branch(1) :
$ git branch -r
  origin/HEAD
  origin/html
  origin/maint
@@ -197,18 +197,18 @@ The tag "v2.6.18" is short for "refs/tags/v2.6.18".
exists a tag and a branch with the same name.
(Newly created refs are actually stored in the .git/refs directory,
under the path given by their name. However, for efficiency reasons
they may also be packed together in a single file; see
-git-pack-refs(1) ).
As another useful shortcut, the "HEAD" of a repository can be referred
+git-pack-refs(1) ).
As another useful shortcut, the "HEAD" of a repository can be referred
to just using the name of that repository. So, for example, "origin"
is usually a shortcut for the HEAD branch in the repository "origin".
For the complete list of paths which git checks for references, and
the order it uses to decide which to choose when there are multiple
references with the same shorthand name, see the "SPECIFYING
-REVISIONS" section of git-rev-parse(1) .
Updating a repository with git-fetchEventually the developer cloned from will do additional work in her
+REVISIONS" section of git-rev-parse(1) .
Updating a repository with git-fetchEventually the developer cloned from will do additional work in her
repository, creating new commits and advancing the branches to point
at the new commits.
The command "git fetch", with no arguments, will update all of the
remote-tracking branches to the latest version found in her
repository. It will not touch any of your own branchesânot even the
"master" branch that was created for you on clone.
Fetching branches from other repositoriesYou can also track branches from repositories other than the one you
-cloned from, using git-remote(1) :
$ git remote add linux-nfs git://linux-nfs.org/pub/nfs-2.6.git
+cloned from, using git-remote(1) :
$ git remote add linux-nfs git://linux-nfs.org/pub/nfs-2.6.git
$ git fetch linux-nfs
* refs/remotes/linux-nfs/master: storing branch 'master' ...
  commit: bf81b46
New remote-tracking branches will be stored under the shorthand name
@@ -224,7 +224,7 @@ a new stanza:
This is what causes git to track the remote's branches; you may modify
or delete these configuration options by editing .git/config with a
text editor. (See the "CONFIGURATION FILE" section of
-git-config(1) for details.)
Chapter 2. Exploring git historyGit is best thought of as a tool for storing the history of a
+git-config(1) for details.)
Chapter 2. Exploring git historyGit is best thought of as a tool for storing the history of a
collection of files. It does this by storing compressed snapshots of
the contents of a file hierarchy, together with "commits" which show
the relationships between these snapshots.
Git provides extremely flexible and fast tools for exploring the
@@ -233,7 +233,7 @@ commit that introduced a bug into a project.
<
"master" crashes. Sometimes the best way to find the cause of such a
regression is to perform a brute-force search through the project's
history to find the particular commit that caused the problem. The
-
git-bisect(1) command can help you do this:
$ git bisect start
+git-bisect(1) command can help you do this:
$ git bisect start
$ git bisect good v2.6.18
$ git bisect bad master
Bisecting: 3537 revisions left to test after this
@@ -248,7 +248,7 @@ stage whether the version it gives you is good or bad, and notice
that the number of revisions left to test is cut approximately in
half each time.
After about 13 tests (in this case), it will output the commit id of
the guilty commit. You can then examine the commit with
-git-show(1) , find out who wrote it, and mail them your bug
+git-show(1) , find out who wrote it, and mail them your bug
report with the commit id. Finally, run
to return you to the branch you were on before and delete the
temporary "bisect" branch.
Note that the version which git-bisect checks out for you at each
point is just a suggestion, and you're free to try a different
@@ -265,11 +265,11 @@ branch name: refers to the commit at the head of the given
tag name: refers to the commit pointed to by the given tag
(we've seen branches and tags are special cases of
- references ).
+ references ).
HEAD: refers to the head of the current branch
There are many more; see the "SPECIFYING REVISIONS" section of the
-git-rev-parse(1) man page for the complete list of ways to
+git-rev-parse(1) man page for the complete list of ways to
name revisions. Some examples:
$ git show fb47ddb2 # the first few characters of the object name
                    # are usually enough to specify it uniquely
$ git show HEAD^    # the parent of the HEAD commit
@@ -284,14 +284,14 @@ set ORIG_HEAD to the value HEAD had before the current operation.
The git-
branch in FETCH_HEAD. For example, if you run git fetch without
specifying a local branch as the target of the operation
$ git fetch git://example.com/proj.git theirbranch
the fetched commits will still be available from FETCH_HEAD.
When we discuss merges we'll also see the special name MERGE_HEAD,
which refers to the other branch that we're merging in to the current
-branch.
The git-rev-parse(1) command is a low-level command that is
+branch.
The git-rev-parse(1) command is a low-level command that is
occasionally useful for translating some name for a commit to the object
name for that commit:
$ git rev-parse origin
e05db0fd4f31dde7005f075a84f96b360d05984b
We can also create a tag to refer to a particular commit; after
running
$ git tag stable-1 1b2e1d63ff
You can use stable-1 to refer to the commit 1b2e1d63ff.
This creates a "lightweight" tag. If you would also like to include a
comment with the tag, and possibly sign it cryptographically, then you
-should create a tag object instead; see the git-tag(1) man page
-for details.
The git-log(1) command can show lists of commits. On its
+should create a tag object instead; see the git-tag(1) man page
+for details.
The git-log(1) command can show lists of commits. On its
own, it shows all commits reachable from the parent commit; but you
can also make more specific requests:
$ git log v2.5..        # commits since (not reachable from) v2.5
$ git log test..master  # commits reachable from master but not test
@@ -303,22 +303,22 @@ $ git log Makefile      # commits which modify Makefile
$ git log fs/           # ... which modify any file under fs/
$ git log -S'foo()'     # commits which add or remove any file data
                        # matching the string 'foo()'
And of course you can combine all of these; the following finds
-commits since v2.5 which touch the Makefile or any file under fs:
$ git log v2.5.. Makefile fs/
You can also ask git log to show patches:
See the "âpretty" option in the git-log(1) man page for more
+commits since v2.5 which touch the Makefile or any file under fs:
$ git log v2.5.. Makefile fs/
You can also ask git log to show patches:
See the "âpretty" option in the git-log(1) man page for more
display options.
Note that git log starts with the most recent commit and works
backwards through the parents; however, since git history can contain
multiple independent lines of development, the particular order that
commits are listed in may be somewhat arbitrary.
You can generate diffs between any two versions using
-git-diff(1) :
$ git diff master..test
That will produce the diff between the tips of the two branches. If
+git-diff(1) :
$ git diff master..test
That will produce the diff between the tips of the two branches. If
you'd prefer to find the diff from their common ancestor to test, you
can use three dots instead of two:
$ git diff master...test
Sometimes what you want instead is a set of patches; for this you can
-use git-format-patch(1) :
$ git format-patch master..test
will generate a file with a patch for each commit reachable from test
+use git-format-patch(1) :
$ git format-patch master..test
will generate a file with a patch for each commit reachable from test
but not from master.
Viewing old file versionsYou can always view an old version of a file by just checking out the
correct revision first. But sometimes it is more convenient to be
able to view an old version of a single file without checking
anything out; this command does that:
$ git show v2.5:fs/locks.c
Before the colon may be anything that names a commit, and after it
may be any path to a file tracked by git.
Counting the number of commits on a branchSuppose you want to know how many commits you've made on "mybranch"
since it diverged from "origin":
$ git log --pretty=oneline origin..mybranch | wc -l
Alternatively, you may often see this sort of thing done with the
-lower-level command git-rev-list(1) , which just lists the SHA1's
+lower-level command git-rev-list(1) , which just lists the SHA1's
of all the given commits:
$ git rev-list origin..mybranch | wc -l
Check whether two branches point at the same historySuppose you want to check whether two branches point at the same point
in history.
$ git diff origin..master
will tell you whether the contents of the project are the same at the
two branches; in theory, however, it's possible that the same project
@@ -332,19 +332,19 @@ both: so
$ git log origin...master
You'd like to find the earliest tagged release that contains that
fix.
Of course, there may be more than one answerâif the history branched
after commit e05db0fd, then there could be multiple "earliest" tagged
-releases.
You could just visually inspect the commits since e05db0fd:
Or you can use git-name-rev(1) , which will give the commit a
+releases.
You could just visually inspect the commits since e05db0fd:
Or you can use git-name-rev(1) , which will give the commit a
name based on any tag it finds pointing to one of the commit's
descendants:
$ git name-rev --tags e05db0fd
-e05db0fd tags/v1.5.0-rc1^0~23
The git-describe(1) command does the opposite, naming the
+e05db0fd tags/v1.5.0-rc1^0~23
The git-describe(1) command does the opposite, naming the
revision using a tag on which the given commit is based:
$ git describe e05db0fd
v1.5.0-rc0-260-ge05db0f
but that may sometimes help you guess which tags might come after the
given commit.
If you just want to verify whether a given tagged version contains a
-given commit, you could use git-merge-base(1) :
$ git merge-base e05db0fd v1.5.0-rc1
+given commit, you could use git-merge-base(1) :
$ git merge-base e05db0fd v1.5.0-rc1
e05db0fd4f31dde7005f075a84f96b360d05984b
The merge-base command finds a common ancestor of the given commits,
and always returns one or the other in the case where one is a
descendant of the other; so the above output shows that e05db0fd
actually is an ancestor of v1.5.0-rc1.
Alternatively, note that
$ git log v1.5.0-rc1..e05db0fd
will produce empty output if and only if v1.5.0-rc1 includes e05db0fd,
-because it outputs only commits that are not reachable from v1.5.0-rc1.
As yet another alternative, the git-show-branch(1) command lists
+because it outputs only commits that are not reachable from v1.5.0-rc1.
As yet another alternative, the git-show-branch(1) command lists
the commits reachable from its arguments with a display on the left-hand
side that indicates which arguments that commit is reachable from. So,
you can run something like
$ git show-branch e05db0fd v1.5.0-rc0 v1.5.0-rc1 v1.5.0-rc2
@@ -357,7 +357,7 @@ available
available
Which shows that e05db0fd is reachable from itself, from v1.5.0-rc1, and
from v1.5.0-rc2, but not from v1.5.0-rc0.
Showing commits unique to a given branchSuppose you would like to see all the commits reachable from the branch
head named "master" but not from any other head in your repository.
We can list all the heads in this repository with
-git-show-ref(1) :
$ git show-ref --heads
+git-show-ref(1) :
$ git show-ref --heads
bf62196b5e363d73353a9dcf094c59595f3153b7Â refs/heads/core-tutorial
db768d5504c1bb46f63ee9d6e1772bd047e05bf9Â refs/heads/maint
a07157ac624b2524a059a3414e99f6f44bebc1e7Â refs/heads/master
@@ -370,8 +370,8 @@ refs/heads/tutorial-2
refs/heads/tutorial-fixes
And then we can ask to see all the commits reachable from master
but not from these other heads:
$ gitk master --not $( git show-ref --heads | cut -d' ' -f2 |
                                grep -v '^refs/heads/master' )
Obviously, endless variations are possible; for example, to see all
-commits reachable from some head but not from any tag in the repository:
$ gitk $( git show-ref --heads ) --not  $( git show-ref --tags )
(See git-rev-parse(1) for explanations of commit-selecting
-syntax such as ânot
.)
Creating a changelog and tarball for a software releaseThe git-archive(1) command can create a tar or zip archive from
+commits reachable from some head but not from any tag in the repository:
$ gitk $( git show-ref --heads ) --not  $( git show-ref --tags )
(See git-rev-parse(1) for explanations of commit-selecting
+syntax such as ânot
.)
Creating a changelog and tarball for a software releaseThe git-archive(1) command can create a tar or zip archive from
any version of a project; for example:
$ git archive --format=tar --prefix=project/ HEAD | gzip >latest.tar.gz
will use HEAD to produce a tar archive in which each filename is
preceded by "project/".
If you're releasing a new version of a software project, you may want
to simultaneously make a changelog to include in the release
@@ -390,12 +390,12 @@ they look OK.
$  git log --raw --abbrev=40 --pretty=oneline |
        grep -B 1 `git hash-object filename`
Figuring out why this works is left as an exercise to the (advanced)
-student. The git-log(1) , git-diff-tree(1) , and
-git-hash-object(1) man pages may prove helpful.
Chapter 3. Developing with git Chapter 3. Developing with gitBefore creating any commits, you should introduce yourself to git. The
easiest way to do so is to make sure the following lines appear in a
file named .gitconfig in your home directory:
[user]
        name = Your Name Comes Here
-        email = you@yourdomain.example.com
(See the "CONFIGURATION FILE" section of git-config(1) for
+        email = you@yourdomain.example.com
(See the "CONFIGURATION FILE" section of git-config(1) for
details on the configuration file.)
Creating a new repositoryCreating a new repository from scratch is very easy:
$ mkdir project
$ cd project
$ git init
If you have some initial content (say, a tarball):
$ tar -xzvf project.tar.gz
@@ -429,7 +429,7 @@ $ git diff          # difference between the index file and y
                    # be included if you ran "commit" now.
$ git diff HEAD     # difference between HEAD and working tree; what
                    # would be committed if you ran "commit -a" now.
-$ git status        # a brief per-file summary of the above.
You can also use git-gui(1) to create commits, view changes in
+$ git status        # a brief per-file summary of the above.
You can also use git-gui(1) to create commits, view changes in
the index and the working tree files, and individually select diff hunks
for inclusion in the index (by right-clicking on the diff hunk and
choosing "Stage Hunk For Commit").
Creating good commit messagesThough not required, it's a good idea to begin the commit message
@@ -452,7 +452,7 @@ foo.txt
# except foo.html which is maintained by hand.
!foo.html
# Ignore objects and archives.
-*.[oa]
See gitignore(5) for a detailed explanation of the syntax. You can
+*.[oa]
See 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
@@ -463,8 +463,8 @@ for other users who clone your repository.
If you wish the exclude pattern
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 gitignore(5) for the details.
You can rejoin two diverging branches of development using
-git-merge(1) :
$ git merge branchname
merges the development in the branch "branchname" into the current
+See gitignore(5) for the details.
You can rejoin two diverging branches of development using
+git-merge(1) :
$ git merge branchname
merges the development in the branch "branchname" into the current
branch. If there are conflictsâfor example, if the same file is
modified in two different ways in the remote branch and the local
branchâthen you are warned; the output may look something like this:
$ git merge next
@@ -479,9 +479,9 @@ has two parents, one pointing to the top of the current branch, and
one to the top of the other branch.
When a merge isn't resolved automatically, git leaves the index and
the working tree in a special state that gives you all the
information you need to help resolve the merge.
Files with conflicts are marked specially in the index, so until you
-resolve the problem and update the index, git-commit(1) will
+resolve the problem and update the index, git-commit(1) will
fail:
$ git commit
-file.txt: needs merge
Also, git-status(1) will list those files as "unmerged", and the
+file.txt: needs merge
Also, git-status(1) will list those files as "unmerged", and the
files with conflicts will have conflict markers added, like this:
<<<<<<<Â HEAD:file.txt
Hello world
=======
@@ -492,7 +492,7 @@ some information about the merge. Normally you can just use this
default message unchanged, but you may add additional commentary of
your own if desired.
The above is all you need to know to resolve a simple merge. But git
also provides more information to help resolve conflicts:
Getting conflict-resolution help during a mergeAll of the changes that git was able to merge automatically are
-already added to the index file, so git-diff(1) shows only
+already added to the index file, so git-diff(1) shows only
the conflicts. It uses an unusual syntax:
$ git diff
diff --cc file.txt
index 802992c,2b60207..0000000
@@ -509,7 +509,7 @@ will be HEAD, the tip of the current branch; the other will be the
tip of the other branch, which is stored temporarily in MERGE_HEAD.
During the merge, the index holds three versions of each file. Each of
these three "file stages" represents a different version of the file:
$ git show :1:file.txt  # the file in a common ancestor of both branches
$ git show :2:file.txt  # the version from HEAD.
-$ git show :3:file.txt  # the version from MERGE_HEAD.
When you ask git-diff(1) to show the conflicts, it runs a
+$ git show :3:file.txt  # the version from MERGE_HEAD.
When you ask git-diff(1) to show the conflicts, it runs a
three-way diff between the conflicted merge results in the work tree with
stages 2 and 3 to show only hunks whose contents come from both sides,
mixed (in other words, when a hunk's merge results come only from stage 2,
@@ -519,7 +519,7 @@ each line by a single "+" or "-", it now uses two columns: the first
column is used for differences between the first parent and the working
directory copy, and the second for differences between the second parent
and the working directory copy. (See the "COMBINED DIFF FORMAT" section
-of git-diff-files(1) for a details of the format.)
After resolving the conflict in the obvious way (but before updating the
+of git-diff-files(1) for a details of the format.)
After resolving the conflict in the obvious way (but before updating the
index), the diff will look like:
$ git diff
diff --cc file.txt
index 802992c,2b60207..0000000
@@ -536,10 +536,10 @@ $ git diff --base file.txt      # same as the above
$ git diff -2 file.txt          # diff against stage 2
$ git diff --ours file.txt      # same as the above
$ git diff -3 file.txt          # diff against stage 3
-$ git diff --theirs file.txt    # same as the above.
The git-log(1) and gitk[1] commands also provide special help
+$ git diff --theirs file.txt    # same as the above.
The git-log(1) and gitk(1) commands also provide special help
for merges:
$ git log --merge
$ gitk --merge
These will display all commits which exist only on HEAD or on
-MERGE_HEAD, and which touch an unmerged file.
You may also use git-mergetool(1) , which lets you merge the
+MERGE_HEAD, and which touch an unmerged file.
You may also use git-mergetool(1) , which lets you merge the
unmerged files using external tools such as emacs or kdiff3.
Each time you resolve the conflicts in a file and update the index:
the different stages of that file will be "collapsed", after which
git-diff will (by default) no longer show diffs for that file.
If you get stuck and decide to just give up and throw the whole mess
away, you can always return to the pre-merge state with
$ git reset --hard HEAD
Or, if you've already committed the merge that you want to throw away,
$ git reset --hard ORIG_HEAD
However, this last command can be dangerous in some casesânever
@@ -566,30 +566,30 @@ You can go back and modify the old commit. You should
change, and cannot correctly perform repeated merges from
a branch that has had its history changed.
Fixing a mistake with a new commitCreating a new commit that reverts an earlier change is very easy;
-just pass the git-revert(1) command a reference to the bad
+just pass the git-revert(1) command a reference to the bad
commit; for example, to revert the most recent commit:
This will create a new commit which undoes the change in HEAD. You
will be given a chance to edit the commit message for the new commit.
You can also revert an earlier change, for example, the next-to-last:
In this case git will attempt to undo the old change while leaving
intact any changes made since then. If more recent changes overlap
with the changes to be reverted, then you will be asked to fix
-conflicts manually, just as in the case of resolving a merge .
Fixing a mistake by rewriting historyIf the problematic commit is the most recent commit, and you have not
+conflicts manually, just as in the case of resolving a merge .
Fixing a mistake by rewriting historyIf the problematic commit is the most recent commit, and you have not
yet made that commit public, then you may just
-destroy it using git-reset .
Alternatively, you
+destroy it using git-reset .
Alternatively, you
can edit the working directory and update the index to fix your
-mistake, just as if you were going to create a new commit , then run
which will replace the old commit by a new commit incorporating your
+mistake, just as if you were going to create a new commit , then run
which will replace the old commit by a new commit incorporating your
changes, giving you a chance to edit the old commit message first.
Again, you should never do this to a commit that may already have
-been merged into another branch; use git-revert(1) instead in
+been merged into another branch; use git-revert(1) instead in
that case.
It is also possible to replace commits further back in the history, but
this is an advanced topic to be left for
-another chapter .
Checking out an old version of a fileIn the process of undoing a previous bad change, you may find it
+another chapter .
Checking out an old version of a fileIn the process of undoing a previous bad change, you may find it
useful to check out an older version of a particular file using
-git-checkout(1) . We've used git-checkout before to switch
+git-checkout(1) . We've used git-checkout before to switch
branches, but it has quite different behavior if it is given a path
name: the command
$ git checkout HEAD^ path/to/file
replaces path/to/file by the contents it had in the commit HEAD^, and
also updates the index to match. It does not change branches.
If you just want to look at an old version of the file, without
modifying the working directory, you can do that with
-git-show(1) :
$ git show HEAD^:path/to/file
which will display the given version of the file.
Temporarily setting aside work in progressWhile you are in the middle of working on something complicated, you
+git-show(1) :
$ git show HEAD^:path/to/file
which will display the given version of the file.
Temporarily setting aside work in progressWhile you are in the middle of working on something complicated, you
find an unrelated but obvious and trivial bug. You would like to fix it
-before continuing. You can use git-stash(1) to save the current
+before continuing. You can use git-stash(1) to save the current
state of your work, and after fixing the bug (or, optionally after doing
so on a different branch and then coming back), unstash the
work-in-progress changes.
$ git stash "work in progress for foo feature"
This command will save your changes away to the stash
, and
@@ -598,8 +598,8 @@ current branch. Then you can make your fix as usual.
After that, you can go back to what you were working on with
git stash apply
:
Ensuring good performanceOn large repositories, git depends on compression to keep the history
information from taking up too much space on disk or in memory.
This compression is not performed automatically. Therefore you
-should occasionally run git-gc(1) :
to recompress the archive. This can be very time-consuming, so
-you may prefer to run git-gc when you are not doing other work.
Checking the repository for corruptionThe git-fsck(1) command runs a number of self-consistency checks
+should occasionally run git-gc(1) :
to recompress the archive. This can be very time-consuming, so
+you may prefer to run git-gc when you are not doing other work.
Checking the repository for corruptionThe git-fsck(1) command runs a number of self-consistency checks
on the repository, and reports on any problems. This may take some
time. The most common warning by far is about "dangling" objects:
$ git fsck
dangling commit 7281251ddd2a61e38657c827739c57015671a6b3
@@ -612,7 +612,7 @@ dangling tree d50bb86186bf27b681d25af89d3b5b68382e4085
dangling tree b24c2473f1fd3d91352a624795be026d64c8841f
...
Dangling objects are not a problem. At worst they may take up a little
extra disk space. They can sometimes provide a last-resort method for
-recovering lost workâsee the section called âDangling objectsâ for details.
Say you modify a branch with git-reset(1) âhard
, and then
realize that the branch was the only reference you had to that point in
history.
Fortunately, git also keeps a log, called a "reflog", of all the
previous values of each branch. So in this case you can still find the
@@ -625,9 +625,9 @@ $ gitk master@{"1 week ago"}    # ... or last week
$ git log --walk-reflogs master # show reflog entries for master
A separate reflog is kept for the HEAD, so
$ git show HEAD@{"1 week ago"}
will show what HEAD pointed to one week ago, not what the current branch
pointed to one week ago. This allows you to see the history of what
you've checked out.
The reflogs are kept by default for 30 days, after which they may be
-pruned. See git-reflog(1) and git-gc(1) to learn
+pruned. See git-reflog(1) and git-gc(1) to learn
how to control this pruning, and see the "SPECIFYING REVISIONS"
-section of git-rev-parse(1) for details.
Note that the reflog history is very different from normal git history.
+section of git-rev-parse(1) for details.
Note that the reflog history is very different from normal git history.
While normal history is shared by every repository that works on the
same project, the reflog history is not shared: it tells you only about
how the branches in your local repository have changed over time.
Examining dangling objectsIn some situations the reflog may not be able to save you. For example,
@@ -635,7 +635,7 @@ suppose you delete a branch, then realize you need the history it
contained. The reflog is also deleted; however, if you have not yet
pruned the repository, then you may still be able to find the lost
commits in the dangling objects that git-fsck reports. See
-the section called âDangling objectsâ for the details.
$ git fsck
+the section called âDangling objectsâ for the details.
$ git fsck
dangling commit 7281251ddd2a61e38657c827739c57015671a6b3
dangling commit 2706a059f258c6b245f298dc4ff2ccd30ec21a63
dangling commit 13472b7c4b80851a1bc551779171dcb03655e9b5
@@ -650,35 +650,35 @@ and complex commit history that was dropped.)
If you decide you want the h
reference pointing to it, for example, a new branch:
$ git branch recovered-branch 7281251ddd
Other types of dangling objects (blobs and trees) are also possible, and
dangling objects can arise in other situations.
Chapter 4. Sharing development with othersHowever, the git-pull(1) command provides a way to do this in
one step:
$ git pull origin master
In fact, if you have "master" checked out, then by default "git pull"
merges from the HEAD branch of the origin repository. So often you can
accomplish the above with just a simple
More generally, a branch that is created from a remote branch will pull
by default from that branch. See the descriptions of the
branch.<name>.remote and branch.<name>.merge options in
-git-config(1) , and the discussion of the âtrack
option in
-git-checkout(1) , to learn how to control these defaults.
In addition to saving you keystrokes, "git pull" also helps you by
+git-config(1) , and the discussion of the âtrack
option in
+git-checkout(1) , to learn how to control these defaults.
In addition to saving you keystrokes, "git pull" also helps you by
producing a default commit message documenting the branch and
repository that you pulled from.
(But note that no such commit will be created in the case of a
-fast forward ; instead, your branch will just be
+fast forward ; instead, your branch will just be
updated to point to the latest commit from the upstream branch.)
The git-pull command can also be given "." as the "remote" repository,
in which case it just merges in a branch from the current repository; so
the commands
$ git pull . branch
$ git merge branch
are roughly equivalent. The former is actually very commonly used.
Submitting patches to a projectIf you just have a few changes, the simplest way to submit them may
-just be to send them as patches in email:
First, use git-format-patch(1) ; for example:
$ git format-patch origin
will produce a numbered series of files in the current directory, one
+just be to send them as patches in email:
First, use git-format-patch(1) ; for example:
$ git format-patch origin
will produce a numbered series of files in the current directory, one
for each patch in the current branch but not in origin/HEAD.
You can then import these into your mail client and send them by
hand. However, if you have a lot to send at once, you may prefer to
-use the git-send-email(1) script to automate the process.
+use the git-send-email(1) script to automate the process.
Consult the mailing list for your project first to determine how they
-prefer such patches be handled.
Importing patches to a projectGit also provides a tool called git-am(1) (am stands for
+prefer such patches be handled.
Importing patches to a projectGit also provides a tool called git-am(1) (am stands for
"apply mailbox"), for importing such an emailed series of patches.
Just save all of the patch-containing messages, in order, into a
single mailbox file, say "patches.mbox", then run
$ git am -3 patches.mbox
Git will apply each patch in order; if any conflicts are found, it
will stop, and you can fix the conflicts as described in
-"Resolving a merge ". (The "-3" option tells
+"Resolving a merge ". (The "-3" option tells
git to perform a merge; if you would prefer it just to abort and
leave your tree and index untouched, you may omit that option.)
Once the index is updated with the results of the conflict
resolution, instead of creating a new commit, just run
and git will create the commit for you and continue applying the
@@ -686,7 +686,7 @@ remaining patches from the mailbox.
The final result will be a series of c
the original mailbox, with authorship and commit log message each
taken from the message containing each patch.
Another way to submit changes to a project is to tell the maintainer
of that project to pull the changes from your repository using
-git-pull(1) . In the section "Getting updates with git-pull " we described this as a way to get
+git-pull(1) . In the section "Getting updates with git-pull " we described this as a way to get
updates from the "main" repository, but it works just as well in the
other direction.
If you and the maintainer both have accounts on the same machine, then
you can just pull changes from each other's repositories directly;
@@ -719,12 +719,12 @@ public repository. You can use scp, rsync, or whatever is most
convenient.
Exporting a git repository via the git protocolThis is the preferred method.
If someone else administers the server, they should tell you what
directory to put the repository in, and what git:// URL it will appear
at. You can then skip to the section
-"Pushing changes to a public repository ", below.
Otherwise, all you need to do is start git-daemon(1) ; it will
+"Pushing changes to a public repository ", below.
Otherwise, all you need to do is start git-daemon(1) ; it will
listen on port 9418. By default, it will allow access to any directory
that looks like a git directory and contains the magic file
git-daemon-export-ok. Passing some directory paths as git-daemon
arguments will further restrict the exports to those paths.
You can also run git-daemon as an inetd service; see the
-git-daemon(1) man page for details. (See especially the
+git-daemon(1) man page for details. (See especially the
examples section.)
Exporting a git repository via httpThe git protocol gives better performance and reliability, but on a
host with a web server set up, http exports may be simpler to set up.
All you need to do is place the newly created bare git repository in
a directory that is exported by the web server, and make some
@@ -732,20 +732,20 @@ adjustments to give web clients some extra information they need:
$ 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 githooks(5) .)
Advertise the URL of proj.git. Anybody else should then be able to
+git-update-server-info(1) and githooks(5) .)
Advertise the URL of proj.git. Anybody else should then be able to
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
+setup-git-server-over-http
for a slightly more sophisticated setup using WebDAV which also
allows pushing over http.)
Pushing changes to a public repositoryNote that the two techniques outlined above (exporting via
-http or git ) allow other
+http or git ) allow other
maintainers to fetch your latest changes, but they do not allow write
access, which you will need to update the public repository with the
-latest changes created in your private repository.
The simplest way to do this is using git-push(1) and ssh; to
+latest changes created in your private repository.
The simplest way to do this is using git-push(1) and ssh; to
update the remote branch named "master" with the latest state of your
branch named "master", run
$ git push ssh://yourserver.com/~you/proj.git master:master
or just
$ git push ssh://yourserver.com/~you/proj.git master
As with git-fetch, git-push will complain if this does not result in a
-fast forward ; see the following section for details on
+fast forward ; see the following section for details on
handling this case.
Note that the target of a "push" is normally a
-bare repository. You can also push to a
+bare repository. You can also push to a
repository that has a checked-out working tree, but the working tree
will not be updated by the push. This may lead to unexpected results if
the branch you push to is the currently checked-out branch!
As with git-fetch, you may also set up configuration options to
@@ -753,35 +753,35 @@ save typing; so, for example, after
$ cat >
[remote "public-repo"]
        url = ssh://yourserver.com/~you/proj.git
EOF
you should be able to perform the above push with just
$ git push public-repo master
See the explanations of the remote.<name>.url, branch.<name>.remote,
-and remote.<name>.push options in git-config(1) for
-details.
What to do when a push failsIf a push would not result in a fast forward of the
+and remote.<name>.push options in git-config(1) for
+details.
What to do when a push failsIf a push would not result in a fast forward of the
remote branch, then it will fail with an error like:
error: remote 'refs/heads/master' is not an ancestor of
 local  'refs/heads/master'.
 Maybe you are not up-to-date and need to pull first?
error: failed to push to 'ssh://yourserver.com/~you/proj.git'
This can happen, for example, if you:
You may force git-push to perform the update anyway by preceding the
branch name with a plus sign:
$ git push ssh://yourserver.com/~you/proj.git +master
Normally whenever a branch head in a public repository is modified, it
is modified to point to a descendant of the commit that it pointed to
before. By forcing a push in this situation, you break that convention.
-(See the section called âProblems with rewriting historyâ .)
Nevertheless, this is a common practice for people that need a simple
+(See the section called âProblems with rewriting historyâ .)
Nevertheless, this is a common practice for people that need a simple
way to publish a work-in-progress patch series, and it is an acceptable
compromise as long as you warn other developers that this is how you
intend to manage the branch.
It's also possible for a push to fail in this way when other people have
the right to push to the same repository. In that case, the correct
solution is to retry the push after first updating your work by either a
pull or a fetch followed by a rebase; see the
-next section and
-gitcvs-migration(7) for more.
Setting up a shared repositoryAnother way to collaborate is by using a model similar to that
commonly used in CVS, where several developers with special rights
all push to and pull from a single shared repository. See
-gitcvs-migration(7) for instructions on how to
+gitcvs-migration(7) for instructions on how to
set this up.
However, while there is nothing wrong with git's support for shared
repositories, this mode of operation is not generally recommended,
simply because the mode of collaboration that git supportsâby
@@ -819,29 +819,29 @@ A "release" tree into which tested patches are moved for final sanity
containing a logical grouping of patches.
To set this up, first create your work tree by cloning Linus's public
tree:
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git work
$ cd work
Linus's tree will be stored in the remote branch named origin/master,
-and can be updated using git-fetch(1) ; you can track other
-public trees using git-remote(1) to set up a "remote" and
-git-fetch(1) to keep them up-to-date; see
-Chapter 1, Repositories and Branches .
Now create the branches in which you are going to work; these start out
+and can be updated using git-fetch(1) ; you can track other
+public trees using git-remote(1) to set up a "remote" and
+git-fetch(1) to keep them up-to-date; see
+Chapter 1, Repositories and Branches .
Now create the branches in which you are going to work; these start out
at the current tip of origin/master branch, and should be set up (using
-the âtrack option to git-branch(1) ) to merge changes in from
+the âtrack option to git-branch(1) ) to merge changes in from
Linus by default.
$ git branch --track test origin/master
-$ git branch --track release origin/master
These can be easily kept up to date using git-pull(1) .
$ git checkout test && git pull
+$ git branch --track release origin/master
These can be easily kept up to date using git-pull(1) .
$ git checkout test && git pull
$ git checkout release && git pull
Important note! If you have any local changes in these branches, then
this merge will create a commit object in the history (with no local
changes git will simply do a "Fast forward" merge). Many people dislike
the "noise" that this creates in the Linux history, so you should avoid
doing this capriciously in the "release" branch, as these noisy commits
will become part of the permanent history when you ask Linus to pull
-from the release branch.
A few configuration variables (see git-config(1) ) can
+from the release branch.
A few configuration variables (see git-config(1) ) can
make it easy to push both branches to your public tree. (See
-the section called âSetting up a public repositoryâ .)
$ cat >> .git/config <<EOF
+the section called âSetting up a public repositoryâ .)
$ cat >> .git/config <<EOF
[remote "mytree"]
        url =  master.kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git
        push = release
        push = test
EOF
Then you can push both the test and release trees using
-git-push(1) :
or push just one of the test and release branches using:
$ git push mytree test
or
$ git push mytree release
Now to apply some patches from the community. Think of a short
+git-push(1) :
or push just one of the test and release branches using:
$ git push mytree test
or
$ git push mytree release
Now to apply some patches from the community. Think of a short
snappy name for a branch to hold this patch (or related group of
patches), and create a new branch from the current tip of Linus's
branch:
$ git checkout -b speed-up-spinlocks origin
Now you apply the patch(es), run some tests, and commit the change(s). If
@@ -854,7 +854,7 @@ see the value of keeping each patch (or patch series) in its own branch. It
means that the patches can be moved into the "release" tree in any order.
$ git checkout release && git pull . speed-up-spinlocks
After a while, you will have a number of branches, and despite the
well chosen names you picked for each of them, you may forget what
they are for, or what status they are in. To get a reminder of what
-changes are in a specific branch, use:
$ git log linux..branchname | git-shortlog
To see whether it has already been merged into the test or release branches,
+changes are in a specific branch, use:
$ git log linux..branchname | git shortlog
To see whether it has already been merged into the test or release branches,
use:
$ git log test..branchname
or
$ git log release..branchname
(If this branch has not yet been merged, you will see some log entries.
If it has been merged, then there will be no output.)
Once a patch completes the great cycle (moving from test to release,
then pulled by Linus, and finally coming back into your local
@@ -999,43 +999,43 @@ the result would create a new merge commit, like this:
git-rebase(1):$ git checkout mywork
+git-rebase(1) :
$ git checkout mywork
$ git rebase origin
This will remove each of your commits from mywork, temporarily saving
them as patches (in a directory named ".dotest"), update mywork to
point at the latest version of origin, then apply each of the saved
patches to the new mywork. The result will look like:
o--o--O--o--o--o <-- origin
\
a'--b'--c' <-- mywork In the process, it may discover conflicts. In that case it will stop
-and allow you to fix the conflicts; after fixing conflicts, use "git
-add" to update the index with those contents, and then, instead of
+and allow you to fix the conflicts; after fixing conflicts, use "git-add"
+to update the index with those contents, and then, instead of
running git-commit, just run
$ git rebase --continue
and git will continue applying the rest of the patches.
At any point you may use the âabort
option to abort this process and
-return mywork to the state it had before you started the rebase:
Rewriting a single commitWe saw in the section called âFixing a mistake by rewriting historyâ that you can replace the
most recent commit using
which will replace the old commit by a new commit incorporating your
-changes, giving you a chance to edit the old commit message first.
You can also use a combination of this and git-rebase(1) to
+changes, giving you a chance to edit the old commit message first.
You can also use a combination of this and git-rebase(1) to
replace a commit further back in your history and recreate the
intervening changes on top of it. First, tag the problematic commit
with
$ git tag bad mywork~5
(Either gitk or git-log may be useful for finding the commit.)
Then check out that commit, edit it, and rebase the rest of the series
on top of it (note that we could check out the commit on a temporary
-branch, but instead we're using a detached head ):
$ git checkout bad
+branch, but instead we're using a detached head ):
$ git checkout bad
$ # make changes here and update the index
$ git commit --amend
$ git rebase --onto HEAD bad mywork
When you're done, you'll be left with mywork checked out, with the top
patches on mywork reapplied on top of your modified commit. You can
then clean up with
Note that the immutable nature of git history means that you haven't really
"modified" existing commits; instead, you have replaced the old commits with
-new commits having new object names.
Reordering or selecting from a patch seriesGiven one existing commit, the git-cherry-pick(1) command
+new commits having new object names.
Reordering or selecting from a patch seriesGiven one existing commit, the git-cherry-pick(1) command
allows you to apply the change introduced by that commit and create a
new commit that records it. So, for example, if "mywork" points to a
series of patches on top of "origin", you might do something like:
$ git checkout -b mywork-new origin
$ gitk origin..mywork &
and browse through the list of patches in the mywork branch using gitk,
applying them (possibly in a different order) to mywork-new using
cherry-pick, and possibly modifying them as you go using commit âamend
.
-The git-gui(1) command may also help as it allows you to
+The git-gui(1) command may also help as it allows you to
individually 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) .
There are numerous other tools, such as StGIT, which exist for the
+them again with git-am(1) .
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 historyThe primary problem with rewriting the history of a branch has to do
with merging. Suppose somebody fetches your branch and merges it into
@@ -1058,7 +1058,7 @@ new. The results are likely to be unexpected.
You may still choose to pub
and it may be useful for others to be able to fetch those branches in
order to examine or test them, but they should not attempt to pull such
branches into their own work.
For true distributed development that supports proper merging,
-published branches should never be rewritten.
Why bisecting merge commits can be harder than bisecting linear historyThe git-bisect(1) command correctly handles history that
+published branches should never be rewritten.
Why bisecting merge commits can be harder than bisecting linear historyThe git-bisect(1) command correctly handles history that
includes merge commits. However, when the commit that it finds is a
merge commit, the user may need to work harder than usual to figure out
why that commit introduced a problem.
Imagine this history:
---Z---o---X---...---o---A---C---D
@@ -1077,7 +1077,7 @@ so no conflict resolution is required.Nevertheless, the code at C is brok
on the lower line of development have not been converted to the new
semantics introduced on the upper line of development. So if all
you know is that D is bad, that Z is good, and that
-git-bisect(1) identifies C as the culprit, how will you
+git-bisect(1) identifies C as the culprit, how will you
figure out that the problem is due to this change in semantics?
When the result of a git-bisect is a non-merge commit, you should
normally be able to discover the problem by examining just that commit.
Developers can make this easy by breaking their changes into small
@@ -1092,7 +1092,7 @@ linear history:
---Z---o---X--...---o---A---o-
and understanding why Y* was broken would probably be easier.Partly for this reason, many experienced git users, even when
working on an otherwise merge-heavy project, keep the history
linear by rebasing against the latest upstream version before
-publishing.
Chapter 6. Advanced branch management Fetching individual branchesInstead of using git-remote(1) , you can also choose just
+publishing.
Chapter 6. Advanced branch management Fetching individual branchesInstead of using git-remote(1) , you can also choose just
to update one branch at a time, and to store it locally under an
arbitrary name:
$ git fetch origin todo:my-todo-work
The first argument, "origin", just tells git to fetch from the
repository you originally cloned from. The second argument tells git
@@ -1100,19 +1100,19 @@ to fetch the branch named "todo" from the remote repository, and to
store it locally under the name refs/heads/my-todo-work.
You can also fetch branches from other repositories; so
$ git fetch git://example.com/proj.git master:example-master
will create a new branch named "example-master" and store in it the
branch named "master" from the repository at the given URL. If you
already have a branch named example-master, it will attempt to
-fast-forward to the commit given by example.com's
-master branch. In more detail:
git fetch and fast-forwardsIn the previous example, when updating an existing branch, "git
-fetch" checks to make sure that the most recent commit on the remote
+fast-forward to the commit given by example.com's
+master branch. In more detail:
git fetch and fast-forwardsIn the previous example, when updating an existing branch, "git-fetch"
+checks to make sure that the most recent commit on the remote
branch is a descendant of the most recent commit on your copy of the
branch before updating your copy of the branch to point at the new
-commit. Git calls this process a fast forward .
A fast forward looks something like this:
o--o--o--o <-- old head of the branch
+commit. Git calls this process a fast forward .A fast forward looks something like this:
o--o--o--o <-- old head of the branch
\
o--o--o <-- new head of the branch In some cases it is possible that the new head will not actually be
a descendant of the old head. For example, the developer may have
realized she made a serious mistake, and decided to backtrack,
resulting in a situation like:
o--o--o--o--a--b <-- old head of the branch
\
- o--o--o <-- new head of the branch In this case, "git fetch" will fail, and print out a warning.
In that case, you can still force git to update to the new head, as
+ o--o--o <-- new head of the branch
In this case, "git-fetch" will fail, and print out a warning.
In that case, you can still force git to update to the new head, as
described in the following section. However, note that in the
situation above this may mean losing the commits labeled "a" and "b",
unless you've already created a reference of your own pointing to
@@ -1122,7 +1122,7 @@ flag to force updates of all the fetched branches, as in:
Configuring remote branchesWe saw above that "origin" is just a shortcut to refer to the
repository that you originally cloned from. This information is
stored in git configuration variables, which you can see using
-git-config(1) :
$ git config -l
+git-config(1) :
$ git config -l
core.repositoryformatversion=0
core.filemode=true
core.logallrefupdates=true
@@ -1137,10 +1137,10 @@ $ git fetch example master:refs/remotes/example/master
$ git fetch example
You can also add a "+" to force the update each time:
$ git config remote.example.fetch +master:ref/remotes/example/master
Don't do this unless you're sure you won't mind "git-fetch" possibly
throwing away commits on mybranch.
Also note that all of the above configuration can be performed by
directly editing the file .git/config instead of using
-git-config(1) .
See git-config(1) for more details on the configuration
+git-config(1) .
See git-config(1) for more details on the configuration
options mentioned above.
Chapter 7. Git conceptsGit is built on a small number of simple but powerful ideas. While it
is possible to get things done without understanding them, you will find
-git much more intuitive if you do.
We start with the most important, the object database and the index .
(See the section called âObject storage formatâ for the details of the object formatting and
SHA1 calculation.)
There are four different types of objects: "blob", "tree", "commit", and
"tag".
-A "blob" object is used to store file data.
+A "blob" object is used to store file data.
-A "tree" object is an object that ties one or more
+A "tree" object is an object that ties one or more
"blob" objects into a directory structure. In addition, a tree object
can refer to other tree objects, thus creating a directory hierarchy.
-A "commit" object ties such directory hierarchies
- together into a directed acyclic graph of revisionsâeach
+A "commit" object ties such directory hierarchies
+ together into a directed acyclic graph of revisionsâeach
commit contains the object name of exactly one tree designating the
directory hierarchy at the time of the commit. In addition, a commit
refers to "parent" commit objects that describe the history of how we
arrived at that directory hierarchy.
-A "tag" object symbolically identifies and can be
+A "tag" object symbolically identifies and can be
used to sign other objects. It contains the object name and type of
another object, a symbolic name (of course!) and, optionally, a
signature.
The object types in some more detail:
The "commit" object links a physical state of a tree with a description
of how we got there and why. Use the âpretty=raw option to
-git-show(1) or git-log(1) to examine your favorite
+git-show(1) or git-log(1) to examine your favorite
commit:
$ git show -s --pretty=raw 2be7fcb476
commit 2be7fcb4764f2dbcee52635b91fedb1b3dcf7ab4
tree fb3a8bdd0ceddd019615af4d57a53f43d8cee2bf
@@ -1216,10 +1216,10 @@ of the tree referred to by this commit with the trees associated with
its parents. In particular, git does not attempt to record file renames
explicitly, though it can identify cases where the existence of the same
file data at changing paths suggests a rename. (See, for example, the
--M option to git-diff(1) ).
A commit is usually created by git-commit(1) , which creates a
+-M option to git-diff(1) ).
A commit is usually created by git-commit(1) , which creates a
commit whose parent is normally the current HEAD, and whose tree is
-taken from the content currently stored in the index.
The ever-versatile git-show(1) command can also be used to
-examine tree objects, but git-ls-tree(1) will give you more
+taken from the content currently stored in the index.
The ever-versatile git-show(1) command can also be used to
+examine tree objects, but git-ls-tree(1) will give you more
details:
$ git ls-tree fb3a8bdd0ce
100644 blob 63c918c667fa005ff12ad89437f2fdc80926e21c    .gitignore
100644 blob 5529b198e8d14decbe4ad99db3f7fb632de0439d    .mailmap
@@ -1239,8 +1239,8 @@ contents (including, recursively, the contents of all subdirectories)
are identical. This allows git to quickly determine the differences
between two related tree objects, since it can ignore any entries with
identical object names.
(Note: in the presence of submodules, trees may also have commits as
-entries. See Chapter 8, Submodules for documentation.)
Note that the files all have mode 644 or 755: git actually only pays
-attention to the executable bit.
You can use git-show(1) to examine the contents of a blob; take,
+entries. See Chapter 8, Submodules for documentation.)
Note that the files all have mode 644 or 755: git actually only pays
+attention to the executable bit.
You can use git-show(1) to examine the contents of a blob; take,
for example, the blob in the entry for "COPYING" from the tree above:
$ git show 6ff87c4664
 Note that the only valid version of the GPL as far as this project
@@ -1252,7 +1252,7 @@ directory tree (or in multiple different versions of the repository)
have the same contents, they will share the same blob object. The object
is totally independent of its location in the directory tree, and
renaming a file does not change the object that file is associated with.
Note that any tree or blob object can be examined using
-git-show(1) with the <revision>:<path> syntax. This can
+git-show(1) with the <revision>:<path> syntax. This can
sometimes be useful for browsing the contents of a tree that is not
currently checked out.
If you receive the SHA1 name of a blob from one source, and its contents
from another (possibly untrusted) source, you can still trust that those
@@ -1272,7 +1272,7 @@ sending out a single email that tells the people the name (SHA1 hash)
of the top commit, and digitally sign that email using something
like GPG/PGP.
To assist in this, git also provides the tag objectâ¦
A tag object contains an object, object type, tag name, the name of the
person ("tagger") who created the tag, and a message, which may contain
-a signature, as can be seen using the git-cat-file(1) :
$ git cat-file tag v1.5.0
+a signature, as can be seen using the git-cat-file(1) :
$ git cat-file tag v1.5.0
object 437b1b20df4b356c9342dac8d38849f24ef44f27
type commit
tag v1.5.0
@@ -1285,8 +1285,8 @@ Version:Â GnuPGÂ v1.4.6Â (GNU/Linux)
iD8DBQBF0lGqwMbZpPMRm5oRAuRiAJ9ohBLd7s2kqjkKlq1qqC57SbnmzQCdG4ui
nLE/L9aUXdWeTFPron96DLA=
=2E+0
------ENDÂ PGPÂ SIGNATURE-----
See the git-tag(1) command to learn how to create and verify tag
-objects. (Note that git-tag(1) can also be used to create
+-----ENDÂ PGPÂ SIGNATURE-----
See the git-tag(1) command to learn how to create and verify tag
+objects. (Note that git-tag(1) can also be used to create
"lightweight tags", which are not tag objects at all, but just simple
references whose names begin with "refs/tags/").
How git stores objects efficiently: pack filesNewly created objects are initially created in a file named after the
object's SHA1 hash (stored in .git/objects).
Unfortunately this system becomes inefficient once a project has a
@@ -1296,7 +1296,7 @@ individual files. The second is the amount of space taken up by
those "loose" objects.
You can save space and make git faster by moving these loose objects in
to a "pack file", which stores a group of objects in an efficient
compressed format; the details of how pack files are formatted can be
-found in technical/pack-format.txt .
To put the loose objects into a pack, just run git repack:
$ git repack
+found in technical/pack-format.txt .
To put the loose objects into a pack, just run git repack:
$ git repack
Generating pack...
Done counting 6020 objects.
Deltifying 6020 objects.
@@ -1306,18 +1306,18 @@ Writing 6020 objects.
Total 6020, written 6020 (delta 4070), reused 0 (delta 0)
Pack pack-3e54ad29d5b2e05838c75df582c65257b8d08e1c created.
You can then run
to remove any of the "loose" objects that are now contained in the
pack. This will also remove any unreferenced objects (which may be
-created when, for example, you use "git reset" to remove a commit).
+created when, for example, you use "git-reset" to remove a commit).
You can verify that the loose objects are gone by looking at the
.git/objects directory or by running
$ git count-objects
0 objects, 0 kilobytes
Although the object files are gone, any commands that refer to those
-objects will work exactly as they did before.
The git-gc(1) command performs packing, pruning, and more for
-you, so is normally the only high-level command you need.
The git-fsck(1) command will sometimes complain about dangling
+objects will work exactly as they did before.
The git-gc(1) command performs packing, pruning, and more for
+you, so is normally the only high-level command you need.
The git-fsck(1) command will sometimes complain about dangling
objects. They are not a problem.
The most common cause of dangling objects is that you've rebased a
branch, or you have pulled from somebody else who rebased a branchâsee
-Chapter 5, Rewriting history and maintaining patch series . In that case, the old head of the original
+Chapter 5, Rewriting history and maintaining patch series . In that case, the old head of the original
branch still exists, as does everything it pointed to. The branch
pointer itself just doesn't, since you replaced it with another one.
There are also other situations that cause dangling objects. For
-example, a "dangling blob" may arise because you did a "git add" of a
+example, a "dangling blob" may arise because you did a "git-add" of a
file, but then, before you actually committed it and made it part of the
bigger picture, you changed something else in that file and committed
that updated thingâthe old state that you added originally ends up
@@ -1341,8 +1341,8 @@ of what the operation was that left that dangling object.
Usually, danglin
almost always the result of either being a half-way mergebase (the blob
will often even have the conflict markers from a merge in it, if you
have had conflicting merges that you fixed up by hand), or simply
-because you interrupted a "git fetch" with ^C or something like that,
-leaving _some_ of the new objects in the object database, but just
+because you interrupted a "git-fetch" with ^C or something like that,
+leaving some of the new objects in the object database, but just
dangling and useless.
Anyway, once you are sure that you're not interested in any dangling
state, you can just prune all unreachable objects:
and they'll be gone. But you should only run "git prune" on a quiescent
repositoryâit's kind of like doing a filesystem fsck recovery: you
@@ -1361,7 +1361,7 @@ to replace them by hand. Back up your repository before attempting this
in case you corrupt things even more in the process.
We'll assume that the problem is a single missing or corrupted blob,
which is sometimes a solvable problem. (Recovering missing trees and
especially commits is much harder).
Before starting, verify that there is corruption, and figure out where
-it is with git-fsck(1) ; this may be time-consuming.
Assume the output looks like this:
$ git fsck --full
+it is with git-fsck(1) ; this may be time-consuming.
Assume the output looks like this:
$ git fsck --full
broken link from    tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8
              to    blob 4b9458b3786228369c63936db65827de3cc06200
missing blob 4b9458b3786228369c63936db65827de3cc06200
(Typically there will be some "dangling object" messages too, but they
@@ -1369,7 +1369,7 @@ aren't interesting.)
Now you know that blob 4b9458b3 is missing, and that
points to it. If you could find just one copy of that missing blob
object, possibly in some other repository, you could move it into
.git/objects/4b/9458b3⦠and be done. Suppose you can't. You can
-still examine the tree that pointed to it with git-ls-tree(1) ,
+still examine the tree that pointed to it with git-ls-tree(1) ,
which might output something like:
$ git ls-tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8
100644 blob 8d14531846b95bfa3564b58ccfb7913a034323b8    .gitignore
100644 blob ebf9bf84da0aab5ed944264a5db2a65fe3a3e883    .mailmap
@@ -1381,7 +1381,7 @@ which might output something like:
$ git ls-t
say it's in "somedirectory". If you're lucky the missing copy might be
the same as the copy you have checked out in your working tree at
"somedirectory/myfile"; you can test whether that's right with
-git-hash-object(1) :
$ git hash-object -w somedirectory/myfile
which will create and store a blob object with the contents of
+git-hash-object(1) :
$ git hash-object -w somedirectory/myfile
which will create and store a blob object with the contents of
somedirectory/myfile, and output the sha1 of that object. if you're
extremely lucky it might be 4b9458b3786228369c63936db65827de3cc06200, in
which case you've guessed right, and the corruption is fixed!
Otherwise, you need more information. How do you tell which version of
@@ -1405,7 +1405,7 @@ shot at reconstructing the contents of the in-between state 4b9458b.
If yo
whole thing. It's up to you - git does have a lot of information, it is
just missing one particular blob version.
The index is a binary file (generally kept in .git/index) containing a
sorted list of path names, each with permissions and the SHA1 of a blob
-object; git-ls-files(1) can show you the contents of the index:
$ git ls-files --stage
+object; git-ls-files(1) can show you the contents of the index:
$ git ls-files --stage
100644 63c918c667fa005ff12ad89437f2fdc80926e21c 0       .gitignore
100644 5529b198e8d14decbe4ad99db3f7fb632de0439d 0       .mailmap
100644Â 6ff87c4664981e4397625791c8ea3bbb5f2279a3Â 0Â Â Â Â Â Â Â COPYING
@@ -1419,7 +1419,7 @@ object; git-ls-files(1) can show y
properties:
The index contains all the information necessary to generate a single
(uniquely determined) tree object.
-
For example, running git-commit(1) generates this tree object
+
For example, running git-commit(1) generates this tree object
from the index, stores it in the object database, and uses it as the
tree object associated with the new commit.
The index enables fast comparisons between the tree object it defines
@@ -1434,13 +1434,13 @@ It can efficiently represent information about merge conflicts
between different tree objects, allowing each pathname to be
associated with sufficient information about the trees involved that
you can create a three-way merge between them.
-
We saw in the section called âGetting conflict-resolution help during a mergeâ that during a merge the index can
+
We saw in the section called âGetting conflict-resolution help during a mergeâ that during a merge the index can
store multiple versions of a single file (called "stages"). The third
-column in the git-ls-files(1) output above is the stage
+column in the git-ls-files(1) output above is the stage
number, and will take on values other than 0 for files with merge
conflicts.
The index is thus a sort of temporary staging area, which is filled with
a tree which you are in the process of working on.
If you blow the index away entirely, you generally haven't lost any
-information as long as you have the name of the tree that it described.
Large projects are often composed of smaller, self-contained modules. For
+information as long as you have the name of the tree that it described.
Large projects are often composed of smaller, self-contained modules. For
example, an embedded Linux distribution's source tree would include every
piece of software in the distribution with some local modifications; a movie
player might need to build against a specific, known-working version of a
@@ -1465,7 +1465,7 @@ the submodule support just stores the submodule repository location and
commit ID, so other developers who clone the containing project
("superproject") can easily clone all the submodules at the same revision.
Partial checkouts of the superproject are possible: you can tell Git to
-clone none, some or all of the submodules.
The git-submodule(1) command is available since Git 1.5.3. Users
+clone none, some or all of the submodules.
The git-submodule(1) command is available since Git 1.5.3. Users
with Git 1.5.2 can look up the submodule commits in the repository and
manually check them out; earlier versions won't recognize the submodules at
all.
To see how submodule support works, create (for example) four example
@@ -1491,7 +1491,7 @@ done
-It adds the submodule's clone path to the gitmodules(5) file and
+It adds the submodule's clone path to the gitmodules(5) file and
adds this file to the index, ready to be committed.
It adds the submodule's current commit ID to the index, ready to be
@@ -1534,7 +1534,7 @@ index d266b98..261dfac 160000
$ git add a
$ git commit -m "Updated submodule a."
$ git push You have to run git submodule update
after git pull
if you want to update
-submodules, too.
Always publish the submodule change before publishing the change to the
+submodules, too.
Always publish the submodule change before publishing the change to the
superproject that references it. If you forget to publish the submodule change,
others won't be able to clone the repository:
$ cd ~/git/super/a
$ echo i added another line to this file >> a.txt
@@ -1563,21 +1563,21 @@ $ cat a.txt
module a
Note The changes are still visible in the submodule's reflog.
This is not the case if you did not commit your changes.
Chapter 9. Low-level git operationsMany of the higher-level commands were originally implemented as shell
scripts using a smaller core of low-level git commands. These can still
be useful when doing unusual things with git, or just as a way to
-understand its inner workings.
High-level operations such as git-commit(1) ,
-git-checkout(1) and git-reset(1) work by moving data
+understand its inner workings.
High-level operations such as git-commit(1) ,
+git-checkout(1) and git-reset(1) work by moving data
between the working tree, the index, and the object database. Git
provides low-level operations which perform each of these steps
individually.
Generally, all "git" operations work on the index file. Some operations
work purely on the index file (showing the current state of the
index), but most operations move data between the index file and either
the database or the working directory. Thus there are four main
-combinations:
working directory -> indexThe git-update-index(1) command updates the index with
+combinations:
working directory -> indexThe git-update-index(1) command updates the index with
information from the working directory. You generally update the
index information by just specifying the filename you want to update,
like so:
$ git update-index filename
but to avoid common mistakes with filename globbing etc, the command
@@ -1589,12 +1589,12 @@ necessarily be removed: if the files still exist in your directory
structure, the index will be updated with their new status, not
removed. The only thing âremove
means is that update-index will be
considering a removed file to be a valid thing, and if the file really
-does not exist any more, it will update the index accordingly.
As a special case, you can also do git-update-index ârefresh
, which
+does not exist any more, it will update the index accordingly.
As a special case, you can also do git update-index ârefresh
, which
will refresh the "stat" information of each index to match the current
stat information. It will not update the object status itself, and
it will only update the fields that are used to quickly test whether
-an object still matches its old backing store object.
The previously introduced git-add(1) is just a wrapper for
-git-update-index(1) .
You write your current index file to a "tree" object with the program
that doesn't come with any optionsâit will just write out the
+an object still matches its old backing store object.
The previously introduced git-add(1) is just a wrapper for
+git-update-index(1) .
You write your current index file to a "tree" object with the program
that doesn't come with any optionsâit will just write out the
current index into the set of tree objects that describe that state,
and it will return the name of the resulting top-level tree. You can
use that tree to re-generate the index at any time by going in the
@@ -1614,7 +1614,7 @@ with
$ git checkout-index filename
if you have an old version of the tree already checked out, you will
need to use the "-f" flag (
before the "-a" flag or the filename) to
force the checkout.
Finally, there are a few odds and ends which are not purely moving
-from one representation to the other:
To commit a tree you have instantiated with "git-write-tree", you'd
+from one representation to the other:
To commit a tree you have instantiated with "git write-tree", you'd
create a "commit" object that refers to that tree and the history
behind itâmost notably the "parent" commits that preceded it in
history.
Normally a "commit" has one parent: the previous state of the tree
@@ -1665,7 +1665,7 @@ various pieces fit together.
                    +-----------+
You can examine the data represented in the object database and the
index with various helper tools. For every object, you can use
-git-cat-file(1) to examine details about the
+git-cat-file(1) to examine details about the
object:
$ git cat-file -t <objectname>
shows the type of the object, and once you have the type (which is
usually implicit in where you find the object), you can use
$ git cat-file blob|tree|commit|tag <objectname>
to show its contents. NOTE! Trees have binary content, and as a result
there is a special helper for showing that content, called
@@ -1692,7 +1692,7 @@ make sure that you've committed thoseâin fact you would normally
always do a merge against your last commit (which should thus match what
you have in your current index anyway).
To do the merge, do
$ git read-tree -m -u <origtree> <yourtree> <targettree>
which will do all trivial merge operations for you directly in the
index file, and you can just write the result out with
-git-write-tree
.
Merging multiple trees, continuedSadly, many merges aren't trivial. If there are files that have
+git write-tree
.
Merging multiple trees, continuedSadly, many merges aren't trivial. If there are files that have
been added, moved or removed, or if both branches have modified the
same file, you will be left with an index tree that contains "merge
entries" in it. Such an index tree can NOT be written out to a tree
@@ -1753,10 +1753,10 @@ source code. This section gives you a little guidance to show where to
start.
A good place to start is with the contents of the initial commit, with:
$ git checkout e83c5163
The initial revision lays the foundation for almost everything git has
today, but is small enough to read in one sitting.
Note that terminology has changed since that revision. For example, the
README in that revision uses the word "changeset" to describe what we
-now call a commit .
Also, we do not call it "cache" any more, but "index", however, the
+now call a commit .
Also, we do not call it "cache" any more, but "index", however, the
file is still called cache.h
. Remark: Not much reason to change it now,
especially since there is no good single name for it anyway, because it is
-basically _the_ header file which is included by _all_ of Git's C sources.
If you grasp the ideas in that initial commit, you should check out a
+basically the header file which is included by all of Git's C sources.
If you grasp the ideas in that initial commit, you should check out a
more recent version and skim cache.h
, object.h
and commit.h
.
In the early days, Git (in the tradition of UNIX) was a bunch of programs
which were extremely simple, and which you used in scripts, piping the
output of one into another. This turned out to be good for initial
@@ -1767,15 +1767,15 @@ and to avoid code duplication.
By now, you know what the index is (and fin
structures in cache.h
), and that there are just a couple of object types
(blobs, trees, commits and tags) which inherit their common structure from
struct object
, which is their first member (and thus, you can cast e.g.
-(struct object *)commit
to achieve the _same_ as &commit->object
, i.e.
-get at the object name and flags).
Now is a good point to take a break to let this information sink in.
Next step: get familiar with the object naming. Read the section called âNaming commitsâ .
+(struct object *)commit
to achieve the same as &commit->object
, i.e.
+get at the object name and flags).
Now is a good point to take a break to let this information sink in.
Next step: get familiar with the object naming. Read the section called âNaming commitsâ .
There are quite a few ways to name an object (and not only revisions!).
All of these are handled in sha1_name.c
. Just have a quick look at
the function get_sha1()
. A lot of the special handling is done by
functions like get_sha1_basic()
or the likes.
This is just to get you into the groove for the most libified part of Git:
-the revision walker.
Basically, the initial version of git log
was a shell script:
$ git-rev-list --pretty $(git-rev-parse --default HEAD "$@") | \
+the revision walker.
Basically, the initial version of git-log
was a shell script:
$ git-rev-list --pretty $(git-rev-parse --default HEAD "$@") | \
        LESS=-S ${PAGER:-less}
What does this mean?
git-rev-list
is the original version of the revision walker, which
-_always_ printed a list of revisions to stdout. It is still functional,
+always printed a list of revisions to stdout. It is still functional,
and needs to, since most new Git programs start out as scripts using
git-rev-list
.
git-rev-parse
is not as important any more; it was only used to filter out
options that were relevant for the different plumbing commands that were
@@ -1790,7 +1790,7 @@ parsing after calling setup_revisions()
. After that
commits one by one with the function get_revision()
.
If you are interested in more details of the revision walking process,
just have a look at the first implementation of cmd_log()
; call
git show v1.3.0~155^2~4
and scroll down to that function (note that you
-no longer need to call setup_pager()
directly).
Nowadays, git log
is a builtin, which means that it is _contained_ in the
+no longer need to call setup_pager()
directly).
Nowadays, git-log
is a builtin, which means that it is contained in the
command git
. The source side of a builtin is
a function called cmd_<bla>
, typically defined in builtin-<bla>.c
,
and declared in builtin.h
,
@@ -1801,13 +1801,13 @@ an entry in BUILTIN_OBJECTS
in the cmd_whatchanged()
and cmd_log()
both reside in builtin-log.c
,
since they share quite a bit of code. In that case, the commands which are
-_not_ named like the .c
file in which they live have to be listed in
-BUILT_INS
in the Makefile
.git log
looks more complicated in C than it does in the original script,
+not named like the .c
file in which they live have to be listed in
+BUILT_INS
in the Makefile
.
git-log
looks more complicated in C than it does in the original script,
but that allows for a much greater flexibility and performance.
Here again it is a good point to take a pause.
Lesson three is: study the code. Really, it is the best way to learn about
the organization of Git (after you know the basic concepts).
So, think about something which you are interested in, say, "how can I
access a blob just knowing the object name of it?". The first step is to
find a Git command with which you can do it. In this example, it is either
-git show
or git cat-file
.
For the sake of clarity, let's stay with git cat-file
, because it