core.editor::
Commands such as `commit` and `tag` that lets you edit
- messages by lauching an editor uses the value of this
+ messages by launching an editor uses the value of this
variable when it is set, and the environment variable
`GIT_EDITOR` is not set. The order of preference is
`GIT_EDITOR` environment, `core.editor`, `VISUAL` and
be encountered again. See gitlink:git-rerere[1].
gitcvs.enabled::
- Whether the cvs server interface is enabled for this repository.
+ Whether the CVS server interface is enabled for this repository.
See gitlink:git-cvsserver[1].
gitcvs.logfile::
- Path to a log file where the cvs server interface well... logs
+ Path to a log file where the CVS server interface well... logs
various stuff. See gitlink:git-cvsserver[1].
gitcvs.allbinary::
'gitcvs.dbuser' supports variable substitution (see
gitlink:git-cvsserver[1] for details).
-All gitcvs variables except for 'gitcvs.allbinary' can also specifed
-as 'gitcvs.<access_method>.<varname>' (where 'access_method' is one
-of "ext" and "pserver") to make them apply only for the given access
-method.
+All gitcvs variables except for 'gitcvs.allbinary' can also be
+specified as 'gitcvs.<access_method>.<varname>' (where 'access_method'
+is one of "ext" and "pserver") to make them apply only for the given
+access method.
http.sslVerify::
Whether to verify the SSL certificate when fetching or pushing
not set, defaults to -1.
pack.deltaCacheSize::
- The maxium memory in bytes used for caching deltas in
+ The maximum memory in bytes used for caching deltas in
gitlink:git-pack-objects[1].
A value of 0 means no limit. Defaults to 0.
</li>\r
</ul>\r
<p>While parent object ids are provided on the command line, author and\r
-commiter information is taken from the following environment variables,\r
+committer information is taken from the following environment variables,\r
if set:</p>\r
<div class="literalblock">\r
<div class="content">\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 18-Aug-2007 07:20:22 UTC\r
+Last updated 25-Aug-2007 03:53:06 UTC\r
</div>\r
</div>\r
</body>\r
- committer name and email and the commit time.
While parent object ids are provided on the command line, author and
-commiter information is taken from the following environment variables,
+committer information is taken from the following environment variables,
if set:
GIT_AUTHOR_NAME
</div>\r
<h2><a id="FILES"></a>FILES</h2>\r
<div class="sectionbody">\r
-<p>If not set explicitely with <em>--file</em>, there are three files where\r
+<p>If not set explicitly with <em>--file</em>, there are three files where\r
git-config will search for configuration options:</p>\r
<div class="literalblock">\r
<div class="title">git/config::</div>\r
<dd>\r
<p>\r
Commands such as <tt>commit</tt> and <tt>tag</tt> that lets you edit\r
- messages by lauching an editor uses the value of this\r
+ messages by launching an editor uses the value of this\r
variable when it is set, and the environment variable\r
<tt>GIT_EDITOR</tt> is not set. The order of preference is\r
<tt>GIT_EDITOR</tt> environment, <tt>core.editor</tt>, <tt>VISUAL</tt> and\r
</dt>\r
<dd>\r
<p>\r
- Whether the cvs server interface is enabled for this repository.\r
+ Whether the CVS server interface is enabled for this repository.\r
See <a href="git-cvsserver.html">git-cvsserver(1)</a>.\r
</p>\r
</dd>\r
</dt>\r
<dd>\r
<p>\r
- Path to a log file where the cvs server interface well… logs\r
+ Path to a log file where the CVS server interface well… logs\r
various stuff. See <a href="git-cvsserver.html">git-cvsserver(1)</a>.\r
</p>\r
</dd>\r
</p>\r
</dd>\r
</dl>\r
-<p>All gitcvs variables except for <em>gitcvs.allbinary</em> can also specifed\r
-as <em>gitcvs.<access_method>.<varname></em> (where <em>access_method</em> is one\r
-of "ext" and "pserver") to make them apply only for the given access\r
-method.</p>\r
+<p>All gitcvs variables except for <em>gitcvs.allbinary</em> can also be\r
+specified as <em>gitcvs.<access_method>.<varname></em> (where <em>access_method</em>\r
+is one of "ext" and "pserver") to make them apply only for the given\r
+access method.</p>\r
<dl>\r
<dt>\r
http.sslVerify\r
</dt>\r
<dd>\r
<p>\r
- The maxium memory in bytes used for caching deltas in\r
+ The maximum memory in bytes used for caching deltas in\r
<a href="git-pack-objects.html">git-pack-objects(1)</a>.\r
A value of 0 means no limit. Defaults to 0.\r
</p>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 23-Aug-2007 00:24:02 UTC\r
+Last updated 25-Aug-2007 03:53:06 UTC\r
</div>\r
</div>\r
</body>\r
FILES
-----
-If not set explicitely with '--file', there are three files where
+If not set explicitly with '--file', there are three files where
git-config will search for configuration options:
.git/config::
</dt>\r
<dd>\r
<p>\r
- Update affected files from cvs repository before attempting export.\r
+ Update affected files from CVS repository before attempting export.\r
</p>\r
</dd>\r
<dt>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 19-Jul-2007 02:09:36 UTC\r
+Last updated 25-Aug-2007 03:53:07 UTC\r
</div>\r
</div>\r
</body>\r
Useful for patch series and the like.
-u::
- Update affected files from cvs repository before attempting export.
+ Update affected files from CVS repository before attempting export.
-v::
Verbose.
<p>No special setup is needed for SSH access, other than having GIT tools\r
in the PATH. If you have clients that do not accept the CVS_SERVER\r
environment variable, you can rename git-cvsserver to cvs.</p>\r
-<p>Note: Newer cvs versions (>= 1.12.11) also support specifying\r
+<p>Note: Newer CVS versions (>= 1.12.11) also support specifying\r
CVS_SERVER directly in CVSROOT like</p>\r
<div class="listingblock">\r
<div class="content">\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 19-Jul-2007 02:09:36 UTC\r
+Last updated 25-Aug-2007 03:53:08 UTC\r
</div>\r
</div>\r
</body>\r
in the PATH. If you have clients that do not accept the CVS_SERVER
environment variable, you can rename git-cvsserver to cvs.
-Note: Newer cvs versions (>= 1.12.11) also support specifying
+Note: Newer CVS versions (>= 1.12.11) also support specifying
CVS_SERVER directly in CVSROOT like
------
been well tested in the wild.</p>\r
<p>Frontends should prefer the <tt>raw</tt> format if the source material\r
already uses UNIX-epoch format, can be coaxed to give dates in that\r
-format, or its format is easiliy convertible to it, as there is no\r
+format, or its format is easily convertible to it, as there is no\r
ambiguity in parsing.</p>\r
</dd>\r
<dt>\r
and <tt>filedeleteall</tt> commands\r
may be included to update the contents of the branch prior to\r
creating the commit. These commands may be supplied in any order.\r
-However it is recommended that a <tt>filedeleteall</tt> command preceed\r
+However it is recommended that a <tt>filedeleteall</tt> command precede\r
all <tt>filemodify</tt>, <tt>filecopy</tt> and <tt>filerename</tt> commands in the same\r
commit, as <tt>filedeleteall</tt>\r
wipes the branch clean (see below).</p>\r
</p>\r
<p>The reason fast-import uses <tt>:</tt> to denote a mark reference is this character\r
is not legal in a Git branch name. The leading <tt>:</tt> makes it easy\r
-to distingush between the mark 42 (<tt>:42</tt>) and the branch 42 (<tt>42</tt>\r
+to distinguish between the mark 42 (<tt>:42</tt>) and the branch 42 (<tt>42</tt>\r
or <tt>refs/heads/42</tt>), or an abbreviated SHA-1 which happened to\r
consist only of base-10 digits.</p>\r
<p>Marks must be declared (via <tt>mark</tt>) before they can be used.</p>\r
start with double quote (<tt>"</tt>).</p>\r
<p>If an <tt>LF</tt> or double quote must be encoded into <tt><path></tt> shell-style\r
quoting should be used, e.g. <tt>"path/with\n and \" in it"</tt>.</p>\r
-<p>The value of <tt><path></tt> must be in canoncial form. That is it must not:</p>\r
+<p>The value of <tt><path></tt> must be in canonical form. That is it must not:</p>\r
<ul>\r
<li>\r
<p>\r
<p>\r
A delimiter string is used to mark the end of the data.\r
fast-import will compute the length by searching for the delimiter.\r
- This format is primarly useful for testing and is not\r
+ This format is primarily useful for testing and is not\r
recommended for real data.\r
</p>\r
<div class="literalblock">\r
to remove the dummy branch.</p>\r
<h3>Import Now, Repack Later</h3>\r
<p>As soon as fast-import completes the Git repository is completely valid\r
-and ready for use. Typicallly this takes only a very short time,\r
+and ready for use. Typically this takes only a very short time,\r
even for considerably large projects (100,000+ commits).</p>\r
<p>However repacking the repository is necessary to improve data\r
locality and access performance. It can also take hours on extremely\r
<div class="sectionbody">\r
<p>There are a number of factors which affect how much memory fast-import\r
requires to perform an import. Like critical sections of core\r
-Git, fast-import uses its own memory allocators to ammortize any overheads\r
-associated with malloc. In practice fast-import tends to ammoritize any\r
+Git, fast-import uses its own memory allocators to amortize any overheads\r
+associated with malloc. In practice fast-import tends to amortize any\r
malloc overheads to 0, due to its use of large block allocations.</p>\r
<h3>per object</h3>\r
<p>fast-import maintains an in-memory structure for every object written in\r
<h3>per active tree</h3>\r
<p>Trees (aka directories) use just 12 bytes of memory on top of the\r
memory required for their entries (see “per active file” below).\r
-The cost of a tree is virtually 0, as its overhead ammortizes out\r
+The cost of a tree is virtually 0, as its overhead amortizes out\r
over the individual file entries.</p>\r
<h3>per active file entry</h3>\r
<p>Files (and pointers to subtrees) within active trees require 52 or 64\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 19-Aug-2007 19:15:24 UTC\r
+Last updated 25-Aug-2007 03:53:08 UTC\r
</div>\r
</div>\r
</body>\r
+
Frontends should prefer the `raw` format if the source material
already uses UNIX-epoch format, can be coaxed to give dates in that
-format, or its format is easiliy convertible to it, as there is no
+format, or its format is easily convertible to it, as there is no
ambiguity in parsing.
`now`::
and `filedeleteall` commands
may be included to update the contents of the branch prior to
creating the commit. These commands may be supplied in any order.
-However it is recommended that a `filedeleteall` command preceed
+However it is recommended that a `filedeleteall` command precede
all `filemodify`, `filecopy` and `filerename` commands in the same
commit, as `filedeleteall`
wipes the branch clean (see below).
+
The reason fast-import uses `:` to denote a mark reference is this character
is not legal in a Git branch name. The leading `:` makes it easy
-to distingush between the mark 42 (`:42`) and the branch 42 (`42`
+to distinguish between the mark 42 (`:42`) and the branch 42 (`42`
or `refs/heads/42`), or an abbreviated SHA-1 which happened to
consist only of base-10 digits.
+
If an `LF` or double quote must be encoded into `<path>` shell-style
quoting should be used, e.g. `"path/with\n and \" in it"`.
-The value of `<path>` must be in canoncial form. That is it must not:
+The value of `<path>` must be in canonical form. That is it must not:
* contain an empty directory component (e.g. `foo//bar` is invalid),
* end with a directory separator (e.g. `foo/` is invalid),
Delimited format::
A delimiter string is used to mark the end of the data.
fast-import will compute the length by searching for the delimiter.
- This format is primarly useful for testing and is not
+ This format is primarily useful for testing and is not
recommended for real data.
+
....
Import Now, Repack Later
~~~~~~~~~~~~~~~~~~~~~~~~
As soon as fast-import completes the Git repository is completely valid
-and ready for use. Typicallly this takes only a very short time,
+and ready for use. Typically this takes only a very short time,
even for considerably large projects (100,000+ commits).
However repacking the repository is necessary to improve data
------------------
There are a number of factors which affect how much memory fast-import
requires to perform an import. Like critical sections of core
-Git, fast-import uses its own memory allocators to ammortize any overheads
-associated with malloc. In practice fast-import tends to ammoritize any
+Git, fast-import uses its own memory allocators to amortize any overheads
+associated with malloc. In practice fast-import tends to amortize any
malloc overheads to 0, due to its use of large block allocations.
per object
~~~~~~~~~~~~~~~
Trees (aka directories) use just 12 bytes of memory on top of the
memory required for their entries (see ``per active file'' below).
-The cost of a tree is virtually 0, as its overhead ammortizes out
+The cost of a tree is virtually 0, as its overhead amortizes out
over the individual file entries.
per active file entry
<div class="sectionbody">\r
<div class="verseblock">\r
<div class="content">git-fmt-merge-msg [--summary | --no-summary] <$GIT_DIR/FETCH_HEAD\r
-git-fmt-merge-msg [--summary | --no-summray] -F <file></div></div>\r
+git-fmt-merge-msg [--summary | --no-summary] -F <file></div></div>\r
</div>\r
<h2>DESCRIPTION</h2>\r
<div class="sectionbody">\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 19-Jul-2007 02:09:41 UTC\r
+Last updated 25-Aug-2007 03:53:09 UTC\r
</div>\r
</div>\r
</body>\r
--------
[verse]
git-fmt-merge-msg [--summary | --no-summary] <$GIT_DIR/FETCH_HEAD
-git-fmt-merge-msg [--summary | --no-summray] -F <file>
+git-fmt-merge-msg [--summary | --no-summary] -F <file>
DESCRIPTION
-----------
<dd>\r
<p>\r
Instead of using <tt>.patch</tt> as the suffix for generated\r
- filenames, use specifed suffix. A common alternative is\r
+ filenames, use specified suffix. A common alternative is\r
<tt>--suffix=.txt</tt>.\r
</p>\r
<p>Note that you would need to include the leading dot <tt>.</tt> if you\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 27-Jul-2007 07:25:26 UTC\r
+Last updated 25-Aug-2007 03:53:09 UTC\r
</div>\r
</div>\r
</body>\r
--suffix=.<sfx>::
Instead of using `.patch` as the suffix for generated
- filenames, use specifed suffix. A common alternative is
+ filenames, use specified suffix. A common alternative is
`--suffix=.txt`.
+
Note that you would need to include the leading dot `.` if you
<h2>Other</h2>\r
<div class="sectionbody">\r
<p>git-gui is actually maintained as an independent project, but stable\r
-versions are distributed as part of the Git suite for the convience\r
+versions are distributed as part of the Git suite for the convenience\r
of end users.</p>\r
<p>A git-gui development repository can be obtained from:</p>\r
<div class="literalblock">\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 19-Jul-2007 02:09:42 UTC\r
+Last updated 25-Aug-2007 03:53:10 UTC\r
</div>\r
</div>\r
</body>\r
Other
-----
git-gui is actually maintained as an independent project, but stable
-versions are distributed as part of the Git suite for the convience
+versions are distributed as part of the Git suite for the convenience
of end users.
A git-gui development repository can be obtained from:
</dt>\r
<dd>\r
<p>\r
- Instead of a commit id on the commandline (which is not expected in this\r
+ Instead of a commit id on the command line (which is not expected in this\r
case), <em>git-http-fetch</em> expects lines on stdin in the format\r
</p>\r
<div class="literalblock">\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 19-Jul-2007 02:09:43 UTC\r
+Last updated 25-Aug-2007 03:53:11 UTC\r
</div>\r
</div>\r
</body>\r
the local end after the transfer is complete.
--stdin::
- Instead of a commit id on the commandline (which is not expected in this
+ Instead of a commit id on the command line (which is not expected in this
case), 'git-http-fetch' expects lines on stdin in the format
<commit-id>['\t'<filename-as-in--w>]
</dt>\r
<dd>\r
<p>\r
- Instead of a commit id on the commandline (which is not expected in this\r
+ Instead of a commit id on the command line (which is not expected in this\r
case), <em>git-local-fetch</em> expects lines on stdin in the format\r
</p>\r
<div class="literalblock">\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 19-Jul-2007 02:09:44 UTC\r
+Last updated 25-Aug-2007 03:53:11 UTC\r
</div>\r
</div>\r
</body>\r
the local end after the transfer is complete.
--stdin::
- Instead of a commit id on the commandline (which is not expected in this
+ Instead of a commit id on the command line (which is not expected in this
case), 'git-local-fetch' expects lines on stdin in the format
<commit-id>['\t'<filename-as-in--w>]
<p>\r
Instead of printing both the SHA-1 and the name, print only\r
the name. If given with --tags the usual tag prefix of\r
- "tags/" is also ommitted from the name, matching the output\r
+ "tags/" is also omitted from the name, matching the output\r
of <a href=":git-describe.html">:git-describe(1)</a> more closely. This option\r
cannot be combined with --stdin.\r
</p>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 19-Jul-2007 02:09:47 UTC\r
+Last updated 25-Aug-2007 03:53:11 UTC\r
</div>\r
</div>\r
</body>\r
--name-only::
Instead of printing both the SHA-1 and the name, print only
the name. If given with --tags the usual tag prefix of
- "tags/" is also ommitted from the name, matching the output
+ "tags/" is also omitted from the name, matching the output
of gitlink::git-describe[1] more closely. This option
cannot be combined with --stdin.
<p>The hook should exit with non-zero status if it wants to disallow\r
updating the named ref. Otherwise it should exit with zero.</p>\r
<p>Successful execution (a zero exit status) of this hook does not\r
-ensure the ref will actully be updated, it is only a prerequisite.\r
+ensure the ref will actually be updated, it is only a prerequisite.\r
As such it is not a good idea to send notices (e.g. email) from\r
this hook. Consider using the post-receive hook instead.</p>\r
</div>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 19-Jul-2007 02:09:50 UTC\r
+Last updated 25-Aug-2007 03:53:12 UTC\r
</div>\r
</div>\r
</body>\r
updating the named ref. Otherwise it should exit with zero.
Successful execution (a zero exit status) of this hook does not
-ensure the ref will actully be updated, it is only a prerequisite.
+ensure the ref will actually be updated, it is only a prerequisite.
As such it is not a good idea to send notices (e.g. email) from
this hook. Consider using the post-receive hook instead.
<tt>expire-unreachable</tt> time and are not reachable from the current\r
tip, are removed from the reflog. This is typically not used\r
directly by the end users — instead, see <a href="git-gc.html">git-gc(1)</a>.</p>\r
-<p>The subcommand "show" (which is also the default, in the absense of any\r
+<p>The subcommand "show" (which is also the default, in the absence of any\r
subcommands) will take all the normal log options, and show the log of\r
<tt>HEAD</tt>, which will cover all recent actions, including branch switches.\r
It is basically an alias for <em>git log -g --abbrev-commit\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 19-Aug-2007 19:15:24 UTC\r
+Last updated 25-Aug-2007 03:53:12 UTC\r
</div>\r
</div>\r
</body>\r
tip, are removed from the reflog. This is typically not used
directly by the end users -- instead, see gitlink:git-gc[1].
-The subcommand "show" (which is also the default, in the absense of any
+The subcommand "show" (which is also the default, in the absence of any
subcommands) will take all the normal log options, and show the log of
`HEAD`, which will cover all recent actions, including branch switches.
It is basically an alias for 'git log -g --abbrev-commit
<h2>DESCRIPTION</h2>\r
<div class="sectionbody">\r
<p>This script is used to combine all objects that do not currently\r
-reside in a "pack", into a pack. It can also be used to re-organise\r
+reside in a "pack", into a pack. It can also be used to re-organize\r
existing packs into a single, more efficient pack.</p>\r
<p>A pack is a collection of objects, individually compressed, with\r
delta compression applied, stored in a single file, with an\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 19-Jul-2007 02:09:51 UTC\r
+Last updated 25-Aug-2007 03:53:13 UTC\r
</div>\r
</div>\r
</body>\r
-----------
This script is used to combine all objects that do not currently
-reside in a "pack", into a pack. It can also be used to re-organise
+reside in a "pack", into a pack. It can also be used to re-organize
existing packs into a single, more efficient pack.
A pack is a collection of objects, individually compressed, with
<p><tt>--date=iso</tt> (or <tt>--date=iso8601</tt>) shows timestamps in ISO 8601 format.</p>\r
<p><tt>--date=rfc</tt> (or <tt>--date=rfc2822</tt>) shows timestamps in RFC 2822\r
format, often found in E-mail messages.</p>\r
-<p><tt>--date=short</tt> shows only date but not time, in <tt>YYYY-MM-DD</tt> fomat.</p>\r
+<p><tt>--date=short</tt> shows only date but not time, in <tt>YYYY-MM-DD</tt> format.</p>\r
<p><tt>--date=default</tt> shows timestamps in the original timezone\r
(either committer's or author's).</p>\r
</dd>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 23-Aug-2007 00:24:04 UTC\r
+Last updated 25-Aug-2007 03:53:13 UTC\r
</div>\r
</div>\r
</body>\r
`--date=rfc` (or `--date=rfc2822`) shows timestamps in RFC 2822
format, often found in E-mail messages.
+
-`--date=short` shows only date but not time, in `YYYY-MM-DD` fomat.
+`--date=short` shows only date but not time, in `YYYY-MM-DD` format.
+
`--date=default` shows timestamps in the original timezone
(either committer's or author's).
</p>\r
<p>This works similarly to <em>svn update</em> or <em>git-pull</em> except that\r
it preserves linear history with <em>git-rebase</em> instead of\r
-<em>git-merge</em> for ease of dcommit-ing with git-svn.</p>\r
+<em>git-merge</em> for ease of dcommiting with git-svn.</p>\r
<p>This accepts all options that <em>git-svn fetch</em> and <em>git-rebase</em>\r
accepts. However <em>--fetch-all</em> only fetches from the current\r
[svn-remote], and not all [svn-remote] definitions.</p>\r
<p>Keep in mind that the <em><strong></em> (asterisk) wildcard of the local ref\r
(left of the <em>:</em>) *must</strong> be the farthest right path component;\r
however the remote wildcard may be anywhere as long as it's own\r
-independent path componet (surrounded by <em>/</em> or EOL). This\r
+independent path component (surrounded by <em>/</em> or EOL). This\r
type of configuration is not automatically created by <em>init</em> and\r
should be manually entered with a text-editor or using\r
<a href="git-config.html">git-config(1)</a></p>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 23-Aug-2007 08:41:16 UTC\r
+Last updated 25-Aug-2007 03:53:14 UTC\r
</div>\r
</div>\r
</body>\r
This works similarly to 'svn update' or 'git-pull' except that
it preserves linear history with 'git-rebase' instead of
-'git-merge' for ease of dcommit-ing with git-svn.
+'git-merge' for ease of dcommiting with git-svn.
This accepts all options that 'git-svn fetch' and 'git-rebase'
accepts. However '--fetch-all' only fetches from the current
Keep in mind that the '*' (asterisk) wildcard of the local ref
(left of the ':') *must* be the farthest right path component;
however the remote wildcard may be anywhere as long as it's own
-independent path componet (surrounded by '/' or EOL). This
+independent path component (surrounded by '/' or EOL). This
type of configuration is not automatically created by 'init' and
should be manually entered with a text-editor or using
gitlink:git-config[1]
<p>Note. A single level of backslashes are eaten by the\r
configuration file parser, so you would need to double the\r
backslashes; the pattern above picks a line that begins with a\r
-backslash, and zero or more occurences of <tt>sub</tt> followed by\r
+backslash, and zero or more occurrences of <tt>sub</tt> followed by\r
<tt>section</tt> followed by open brace, to the end of line.</p>\r
<p>There are a few built-in patterns to make this easier, and <tt>tex</tt>\r
is one of them, so you do not have to write the above in your\r
<li>\r
<p>\r
By examining <tt>t/.gitattributes</tt> (which is in the same\r
- diretory as the path in question), git finds that the first\r
+ directory as the path in question), git finds that the first\r
line matches. <tt>merge</tt> attribute is set. It also finds that\r
the second line matches, and attributes <tt>foo</tt> and <tt>bar</tt>\r
are unset.\r
</p>\r
</li>\r
</ol>\r
-<p>As the result, the attributes assignement to <tt>t/abc</tt> becomes:</p>\r
+<p>As the result, the attributes assignment to <tt>t/abc</tt> becomes:</p>\r
<div class="listingblock">\r
<div class="content">\r
<pre><tt>foo set to true\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 30-Jul-2007 09:06:57 UTC\r
+Last updated 25-Aug-2007 03:53:15 UTC\r
</div>\r
</div>\r
</body>\r
Note. A single level of backslashes are eaten by the
configuration file parser, so you would need to double the
backslashes; the pattern above picks a line that begins with a
-backslash, and zero or more occurences of `sub` followed by
+backslash, and zero or more occurrences of `sub` followed by
`section` followed by open brace, to the end of line.
There are a few built-in patterns to make this easier, and `tex`
the attributes given to path `t/abc` are computed as follows:
1. By examining `t/.gitattributes` (which is in the same
- diretory as the path in question), git finds that the first
+ directory as the path in question), git finds that the first
line matches. `merge` attribute is set. It also finds that
the second line matches, and attributes `foo` and `bar`
are unset.
a match, and `foo` is set, `bar` is reverted to unspecified
state, and `baz` is unset.
-As the result, the attributes assignement to `t/abc` becomes:
+As the result, the attributes assignment to `t/abc` becomes:
----------------------------------------------------------------
foo set to true
hook does on its standard input.</p>\r
<p>This hook does not affect the outcome of <tt>git-receive-pack</tt>, as it\r
is called after the real work is done.</p>\r
-<p>This supersedes the <a href="#post-update"><em>post-update</em></a> hook in that it get's\r
+<p>This supersedes the <a href="#post-update"><em>post-update</em></a> hook in that it gets\r
both old and new values of all the refs in addition to their\r
names.</p>\r
<p>Both standard output and standard error output are forwarded to\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 19-Jul-2007 02:10:09 UTC\r
+Last updated 25-Aug-2007 03:53:16 UTC\r
</div>\r
</div>\r
</body>\r
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,'post-update'>> hook in that it get's
+This supersedes the <<post-update,'post-update'>> hook in that it gets
both old and new values of all the refs in addition to their
names.
<pre><tt>$ git pull . remotes/bob/master</tt></pre>\r
</div></div>\r
<p>Note that git pull always merges into the current branch,\r
-regardless of what else is given on the commandline.</p>\r
+regardless of what else is given on the command line.</p>\r
<p>Later, Bob can update his repo with Alice's latest changes using</p>\r
<div class="listingblock">\r
<div class="content">\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 19-Jul-2007 02:10:02 UTC\r
+Last updated 25-Aug-2007 03:53:15 UTC\r
</div>\r
</div>\r
</body>\r
-------------------------------------
Note that git pull always merges into the current branch,
-regardless of what else is given on the commandline.
+regardless of what else is given on the command line.
Later, Bob can update his repo with Alice's latest changes using
-<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>Git User's Manual (for version 1.5.3 or newer)</title><link rel="stylesheet" href="docbook-xsl.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.69.1"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="book" lang="en"><div class="titlepage"><div><div><h1 class="title"><a name="id189136"></a>Git User's Manual (for version 1.5.3 or newer)</h1></div></div><hr></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="preface"><a href="#id264725">Preface</a></span></dt><dt><span class="chapter"><a href="#repositories-and-branches">1. Repositories and Branches</a></span></dt><dd><dl><dt><span class="section"><a href="#how-to-get-a-git-repository">How to get a git repository</a></span></dt><dt><span class="section"><a href="#how-to-check-out">How to check out a different version of a project</a></span></dt><dt><span class="section"><a href="#understanding-commits">Understanding History: Commits</a></span></dt><dd><dl><dt><span class="section"><a href="#understanding-reachability">Understanding history: commits, parents, and reachability</a></span></dt><dt><span class="section"><a href="#history-diagrams">Understanding history: History diagrams</a></span></dt><dt><span class="section"><a href="#what-is-a-branch">Understanding history: What is a branch?</a></span></dt></dl></dd><dt><span class="section"><a href="#manipulating-branches">Manipulating branches</a></span></dt><dt><span class="section"><a href="#detached-head">Examining an old version without creating a new branch</a></span></dt><dt><span class="section"><a href="#examining-remote-branches">Examining branches from a remote repository</a></span></dt><dt><span class="section"><a href="#how-git-stores-references">Naming branches, tags, and other references</a></span></dt><dt><span class="section"><a href="#Updating-a-repository-with-git-fetch">Updating a repository with git fetch</a></span></dt><dt><span class="section"><a href="#fetching-branches">Fetching branches from other repositories</a></span></dt></dl></dd><dt><span class="chapter"><a href="#exploring-git-history">2. Exploring git history</a></span></dt><dd><dl><dt><span class="section"><a href="#using-bisect">How to use bisect to find a regression</a></span></dt><dt><span class="section"><a href="#naming-commits">Naming commits</a></span></dt><dt><span class="section"><a href="#creating-tags">Creating tags</a></span></dt><dt><span class="section"><a href="#browsing-revisions">Browsing revisions</a></span></dt><dt><span class="section"><a href="#generating-diffs">Generating diffs</a></span></dt><dt><span class="section"><a href="#viewing-old-file-versions">Viewing old file versions</a></span></dt><dt><span class="section"><a href="#history-examples">Examples</a></span></dt><dd><dl><dt><span class="section"><a href="#counting-commits-on-a-branch">Counting the number of commits on a branch</a></span></dt><dt><span class="section"><a href="#checking-for-equal-branches">Check whether two branches point at the same history</a></span></dt><dt><span class="section"><a href="#finding-tagged-descendants">Find first tagged version including a given fix</a></span></dt><dt><span class="section"><a href="#showing-commits-unique-to-a-branch">Showing commits unique to a given branch</a></span></dt><dt><span class="section"><a href="#making-a-release">Creating a changelog and tarball for a software release</a></span></dt></dl></dd><dt><span class="section"><a href="#Finding-comments-with-given-content">Finding commits referencing a file with given content</a></span></dt></dl></dd><dt><span class="chapter"><a href="#Developing-with-git">3. Developing with git</a></span></dt><dd><dl><dt><span class="section"><a href="#telling-git-your-name">Telling git your name</a></span></dt><dt><span class="section"><a href="#creating-a-new-repository">Creating a new repository</a></span></dt><dt><span class="section"><a href="#how-to-make-a-commit">How to make a commit</a></span></dt><dt><span class="section"><a href="#creating-good-commit-messages">Creating good commit messages</a></span></dt><dt><span class="section"><a href="#ignoring-files">Ignoring files</a></span></dt><dt><span class="section"><a href="#how-to-merge">How to merge</a></span></dt><dt><span class="section"><a href="#resolving-a-merge">Resolving a merge</a></span></dt><dd><dl><dt><span class="section"><a href="#conflict-resolution">Getting conflict-resolution help during a merge</a></span></dt></dl></dd><dt><span class="section"><a href="#undoing-a-merge">Undoing a merge</a></span></dt><dt><span class="section"><a href="#fast-forwards">Fast-forward merges</a></span></dt><dt><span class="section"><a href="#fixing-mistakes">Fixing mistakes</a></span></dt><dd><dl><dt><span class="section"><a href="#reverting-a-commit">Fixing a mistake with a new commit</a></span></dt><dt><span class="section"><a href="#fixing-a-mistake-by-editing-history">Fixing a mistake by editing history</a></span></dt><dt><span class="section"><a href="#checkout-of-path">Checking out an old version of a file</a></span></dt><dt><span class="section"><a href="#interrupted-work">Temporarily setting aside work in progress</a></span></dt></dl></dd><dt><span class="section"><a href="#ensuring-good-performance">Ensuring good performance</a></span></dt><dt><span class="section"><a href="#ensuring-reliability">Ensuring reliability</a></span></dt><dd><dl><dt><span class="section"><a href="#checking-for-corruption">Checking the repository for corruption</a></span></dt><dt><span class="section"><a href="#recovering-lost-changes">Recovering lost changes</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#sharing-development">4. Sharing development with others</a></span></dt><dd><dl><dt><span class="section"><a href="#getting-updates-with-git-pull">Getting updates with git pull</a></span></dt><dt><span class="section"><a href="#submitting-patches">Submitting patches to a project</a></span></dt><dt><span class="section"><a href="#importing-patches">Importing patches to a project</a></span></dt><dt><span class="section"><a href="#public-repositories">Public git repositories</a></span></dt><dd><dl><dt><span class="section"><a href="#setting-up-a-public-repository">Setting up a public repository</a></span></dt><dt><span class="section"><a href="#exporting-via-git">Exporting a git repository via the git protocol</a></span></dt><dt><span class="section"><a href="#exporting-via-http">Exporting a git repository via http</a></span></dt><dt><span class="section"><a href="#pushing-changes-to-a-public-repository">Pushing changes to a public repository</a></span></dt><dt><span class="section"><a href="#setting-up-a-shared-repository">Setting up a shared repository</a></span></dt><dt><span class="section"><a href="#setting-up-gitweb">Allowing web browsing of a repository</a></span></dt></dl></dd><dt><span class="section"><a href="#sharing-development-examples">Examples</a></span></dt><dd><dl><dt><span class="section"><a href="#maintaining-topic-branches">Maintaining topic branches for a Linux subsystem maintainer</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#cleaning-up-history">5. Rewriting history and maintaining patch series</a></span></dt><dd><dl><dt><span class="section"><a href="#patch-series">Creating the perfect patch series</a></span></dt><dt><span class="section"><a href="#using-git-rebase">Keeping a patch series up to date using git-rebase</a></span></dt><dt><span class="section"><a href="#modifying-one-commit">Modifying a single commit</a></span></dt><dt><span class="section"><a href="#reordering-patch-series">Reordering or selecting from a patch series</a></span></dt><dt><span class="section"><a href="#patch-series-tools">Other tools</a></span></dt><dt><span class="section"><a href="#problems-with-rewriting-history">Problems with rewriting history</a></span></dt></dl></dd><dt><span class="chapter"><a href="#advanced-branch-management">6. Advanced branch management</a></span></dt><dd><dl><dt><span class="section"><a href="#fetching-individual-branches">Fetching individual branches</a></span></dt><dt><span class="section"><a href="#fetch-fast-forwards">git fetch and fast-forwards</a></span></dt><dt><span class="section"><a href="#forcing-fetch">Forcing git fetch to do non-fast-forward updates</a></span></dt><dt><span class="section"><a href="#remote-branch-configuration">Configuring remote branches</a></span></dt></dl></dd><dt><span class="chapter"><a href="#git-internals">7. Git internals</a></span></dt><dd><dl><dt><span class="section"><a href="#the-object-database">The Object Database</a></span></dt><dt><span class="section"><a href="#blob-object">Blob Object</a></span></dt><dt><span class="section"><a href="#tree-object">Tree Object</a></span></dt><dt><span class="section"><a href="#commit-object">Commit Object</a></span></dt><dt><span class="section"><a href="#trust">Trust</a></span></dt><dt><span class="section"><a href="#tag-object">Tag Object</a></span></dt><dt><span class="section"><a href="#the-index">The "index" aka "Current Directory Cache"</a></span></dt><dt><span class="section"><a href="#the-workflow">The Workflow</a></span></dt><dd><dl><dt><span class="section"><a href="#working-directory-to-index">working directory -> index</a></span></dt><dt><span class="section"><a href="#index-to-object-database">index -> object database</a></span></dt><dt><span class="section"><a href="#object-database-to-index">object database -> index</a></span></dt><dt><span class="section"><a href="#index-to-working-directory">index -> working directory</a></span></dt><dt><span class="section"><a href="#tying-it-all-together">Tying it all together</a></span></dt></dl></dd><dt><span class="section"><a href="#examining-the-data">Examining the data</a></span></dt><dt><span class="section"><a href="#merging-multiple-trees">Merging multiple trees</a></span></dt><dt><span class="section"><a href="#merging-multiple-trees-2">Merging multiple trees, continued</a></span></dt><dt><span class="section"><a href="#pack-files">How git stores objects efficiently: pack files</a></span></dt><dt><span class="section"><a href="#dangling-objects">Dangling objects</a></span></dt><dt><span class="section"><a href="#birdview-on-the-source-code">A birds-eye view of Git's source code</a></span></dt></dl></dd><dt><span class="chapter"><a href="#glossary">8. GIT Glossary</a></span></dt><dt><span class="appendix"><a href="#git-quick-start">A. Git Quick Reference</a></span></dt><dd><dl><dt><span class="section"><a href="#quick-creating-a-new-repository">Creating a new repository</a></span></dt><dt><span class="section"><a href="#managing-branches">Managing branches</a></span></dt><dt><span class="section"><a href="#exploring-history">Exploring history</a></span></dt><dt><span class="section"><a href="#making-changes">Making changes</a></span></dt><dt><span class="section"><a href="#merging">Merging</a></span></dt><dt><span class="section"><a href="#sharing-your-changes">Sharing your changes</a></span></dt><dt><span class="section"><a href="#repository-maintenance">Repository maintenance</a></span></dt></dl></dd><dt><span class="appendix"><a href="#todo">B. Notes and todo list for this manual</a></span></dt></dl></div><div class="preface" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="id264725"></a>Preface</h2></div></div></div><p>Git is a fast distributed revision control system.</p><p>This manual is designed to be readable by someone with basic unix
+<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>Git User's Manual (for version 1.5.3 or newer)</title><link rel="stylesheet" href="docbook-xsl.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.69.1"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="book" lang="en"><div class="titlepage"><div><div><h1 class="title"><a name="id189136"></a>Git User's Manual (for version 1.5.3 or newer)</h1></div></div><hr></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="preface"><a href="#id264725">Preface</a></span></dt><dt><span class="chapter"><a href="#repositories-and-branches">1. Repositories and Branches</a></span></dt><dd><dl><dt><span class="section"><a href="#how-to-get-a-git-repository">How to get a git repository</a></span></dt><dt><span class="section"><a href="#how-to-check-out">How to check out a different version of a project</a></span></dt><dt><span class="section"><a href="#understanding-commits">Understanding History: Commits</a></span></dt><dd><dl><dt><span class="section"><a href="#understanding-reachability">Understanding history: commits, parents, and reachability</a></span></dt><dt><span class="section"><a href="#history-diagrams">Understanding history: History diagrams</a></span></dt><dt><span class="section"><a href="#what-is-a-branch">Understanding history: What is a branch?</a></span></dt></dl></dd><dt><span class="section"><a href="#manipulating-branches">Manipulating branches</a></span></dt><dt><span class="section"><a href="#detached-head">Examining an old version without creating a new branch</a></span></dt><dt><span class="section"><a href="#examining-remote-branches">Examining branches from a remote repository</a></span></dt><dt><span class="section"><a href="#how-git-stores-references">Naming branches, tags, and other references</a></span></dt><dt><span class="section"><a href="#Updating-a-repository-with-git-fetch">Updating a repository with git fetch</a></span></dt><dt><span class="section"><a href="#fetching-branches">Fetching branches from other repositories</a></span></dt></dl></dd><dt><span class="chapter"><a href="#exploring-git-history">2. Exploring git history</a></span></dt><dd><dl><dt><span class="section"><a href="#using-bisect">How to use bisect to find a regression</a></span></dt><dt><span class="section"><a href="#naming-commits">Naming commits</a></span></dt><dt><span class="section"><a href="#creating-tags">Creating tags</a></span></dt><dt><span class="section"><a href="#browsing-revisions">Browsing revisions</a></span></dt><dt><span class="section"><a href="#generating-diffs">Generating diffs</a></span></dt><dt><span class="section"><a href="#viewing-old-file-versions">Viewing old file versions</a></span></dt><dt><span class="section"><a href="#history-examples">Examples</a></span></dt><dd><dl><dt><span class="section"><a href="#counting-commits-on-a-branch">Counting the number of commits on a branch</a></span></dt><dt><span class="section"><a href="#checking-for-equal-branches">Check whether two branches point at the same history</a></span></dt><dt><span class="section"><a href="#finding-tagged-descendants">Find first tagged version including a given fix</a></span></dt><dt><span class="section"><a href="#showing-commits-unique-to-a-branch">Showing commits unique to a given branch</a></span></dt><dt><span class="section"><a href="#making-a-release">Creating a changelog and tarball for a software release</a></span></dt></dl></dd><dt><span class="section"><a href="#Finding-comments-with-given-content">Finding commits referencing a file with given content</a></span></dt></dl></dd><dt><span class="chapter"><a href="#Developing-with-git">3. Developing with git</a></span></dt><dd><dl><dt><span class="section"><a href="#telling-git-your-name">Telling git your name</a></span></dt><dt><span class="section"><a href="#creating-a-new-repository">Creating a new repository</a></span></dt><dt><span class="section"><a href="#how-to-make-a-commit">How to make a commit</a></span></dt><dt><span class="section"><a href="#creating-good-commit-messages">Creating good commit messages</a></span></dt><dt><span class="section"><a href="#ignoring-files">Ignoring files</a></span></dt><dt><span class="section"><a href="#how-to-merge">How to merge</a></span></dt><dt><span class="section"><a href="#resolving-a-merge">Resolving a merge</a></span></dt><dd><dl><dt><span class="section"><a href="#conflict-resolution">Getting conflict-resolution help during a merge</a></span></dt></dl></dd><dt><span class="section"><a href="#undoing-a-merge">Undoing a merge</a></span></dt><dt><span class="section"><a href="#fast-forwards">Fast-forward merges</a></span></dt><dt><span class="section"><a href="#fixing-mistakes">Fixing mistakes</a></span></dt><dd><dl><dt><span class="section"><a href="#reverting-a-commit">Fixing a mistake with a new commit</a></span></dt><dt><span class="section"><a href="#fixing-a-mistake-by-editing-history">Fixing a mistake by editing history</a></span></dt><dt><span class="section"><a href="#checkout-of-path">Checking out an old version of a file</a></span></dt><dt><span class="section"><a href="#interrupted-work">Temporarily setting aside work in progress</a></span></dt></dl></dd><dt><span class="section"><a href="#ensuring-good-performance">Ensuring good performance</a></span></dt><dt><span class="section"><a href="#ensuring-reliability">Ensuring reliability</a></span></dt><dd><dl><dt><span class="section"><a href="#checking-for-corruption">Checking the repository for corruption</a></span></dt><dt><span class="section"><a href="#recovering-lost-changes">Recovering lost changes</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#sharing-development">4. Sharing development with others</a></span></dt><dd><dl><dt><span class="section"><a href="#getting-updates-with-git-pull">Getting updates with git pull</a></span></dt><dt><span class="section"><a href="#submitting-patches">Submitting patches to a project</a></span></dt><dt><span class="section"><a href="#importing-patches">Importing patches to a project</a></span></dt><dt><span class="section"><a href="#public-repositories">Public git repositories</a></span></dt><dd><dl><dt><span class="section"><a href="#setting-up-a-public-repository">Setting up a public repository</a></span></dt><dt><span class="section"><a href="#exporting-via-git">Exporting a git repository via the git protocol</a></span></dt><dt><span class="section"><a href="#exporting-via-http">Exporting a git repository via http</a></span></dt><dt><span class="section"><a href="#pushing-changes-to-a-public-repository">Pushing changes to a public repository</a></span></dt><dt><span class="section"><a href="#setting-up-a-shared-repository">Setting up a shared repository</a></span></dt><dt><span class="section"><a href="#setting-up-gitweb">Allowing web browsing of a repository</a></span></dt></dl></dd><dt><span class="section"><a href="#sharing-development-examples">Examples</a></span></dt><dd><dl><dt><span class="section"><a href="#maintaining-topic-branches">Maintaining topic branches for a Linux subsystem maintainer</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#cleaning-up-history">5. Rewriting history and maintaining patch series</a></span></dt><dd><dl><dt><span class="section"><a href="#patch-series">Creating the perfect patch series</a></span></dt><dt><span class="section"><a href="#using-git-rebase">Keeping a patch series up to date using git-rebase</a></span></dt><dt><span class="section"><a href="#modifying-one-commit">Modifying a single commit</a></span></dt><dt><span class="section"><a href="#reordering-patch-series">Reordering or selecting from a patch series</a></span></dt><dt><span class="section"><a href="#patch-series-tools">Other tools</a></span></dt><dt><span class="section"><a href="#problems-with-rewriting-history">Problems with rewriting history</a></span></dt></dl></dd><dt><span class="chapter"><a href="#advanced-branch-management">6. Advanced branch management</a></span></dt><dd><dl><dt><span class="section"><a href="#fetching-individual-branches">Fetching individual branches</a></span></dt><dt><span class="section"><a href="#fetch-fast-forwards">git fetch and fast-forwards</a></span></dt><dt><span class="section"><a href="#forcing-fetch">Forcing git fetch to do non-fast-forward updates</a></span></dt><dt><span class="section"><a href="#remote-branch-configuration">Configuring remote branches</a></span></dt></dl></dd><dt><span class="chapter"><a href="#git-internals">7. Git internals</a></span></dt><dd><dl><dt><span class="section"><a href="#the-object-database">The Object Database</a></span></dt><dt><span class="section"><a href="#blob-object">Blob Object</a></span></dt><dt><span class="section"><a href="#tree-object">Tree Object</a></span></dt><dt><span class="section"><a href="#commit-object">Commit Object</a></span></dt><dt><span class="section"><a href="#trust">Trust</a></span></dt><dt><span class="section"><a href="#tag-object">Tag Object</a></span></dt><dt><span class="section"><a href="#the-index">The "index" aka "Current Directory Cache"</a></span></dt><dt><span class="section"><a href="#the-workflow">The Workflow</a></span></dt><dd><dl><dt><span class="section"><a href="#working-directory-to-index">working directory -> index</a></span></dt><dt><span class="section"><a href="#index-to-object-database">index -> object database</a></span></dt><dt><span class="section"><a href="#object-database-to-index">object database -> index</a></span></dt><dt><span class="section"><a href="#index-to-working-directory">index -> working directory</a></span></dt><dt><span class="section"><a href="#tying-it-all-together">Tying it all together</a></span></dt></dl></dd><dt><span class="section"><a href="#examining-the-data">Examining the data</a></span></dt><dt><span class="section"><a href="#merging-multiple-trees">Merging multiple trees</a></span></dt><dt><span class="section"><a href="#merging-multiple-trees-2">Merging multiple trees, continued</a></span></dt><dt><span class="section"><a href="#pack-files">How git stores objects efficiently: pack files</a></span></dt><dt><span class="section"><a href="#dangling-objects">Dangling objects</a></span></dt><dt><span class="section"><a href="#birdview-on-the-source-code">A birds-eye view of Git's source code</a></span></dt></dl></dd><dt><span class="chapter"><a href="#glossary">8. GIT Glossary</a></span></dt><dt><span class="appendix"><a href="#git-quick-start">A. Git Quick Reference</a></span></dt><dd><dl><dt><span class="section"><a href="#quick-creating-a-new-repository">Creating a new repository</a></span></dt><dt><span class="section"><a href="#managing-branches">Managing branches</a></span></dt><dt><span class="section"><a href="#exploring-history">Exploring history</a></span></dt><dt><span class="section"><a href="#making-changes">Making changes</a></span></dt><dt><span class="section"><a href="#merging">Merging</a></span></dt><dt><span class="section"><a href="#sharing-your-changes">Sharing your changes</a></span></dt><dt><span class="section"><a href="#repository-maintenance">Repository maintenance</a></span></dt></dl></dd><dt><span class="appendix"><a href="#todo">B. Notes and todo list for this manual</a></span></dt></dl></div><div class="preface" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="id264725"></a>Preface</h2></div></div></div><p>Git is a fast distributed revision control system.</p><p>This manual is designed to be readable by someone with basic UNIX
command-line skills, but no previous knowledge of git.</p><p><a href="#repositories-and-branches" title="Chapter 1. Repositories and Branches">Chapter 1, <i>Repositories and Branches</i></a> and <a href="#exploring-git-history" title="Chapter 2. Exploring git history">Chapter 2, <i>Exploring git history</i></a> 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
command; running gitk now on a git repository and looking for merge
commits will help understand how the git organizes history.</p><p>In the following, we say that commit X is "reachable" from commit Y
if commit X is an ancestor of commit Y. Equivalently, you could say
-that Y is a descendent of X, or that there is a chain of parents
+that Y is a descendant of X, or that there is a chain of parents
leading from commit Y to commit X.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="history-diagrams"></a>Understanding history: History diagrams</h3></div></div></div><p>We will sometimes represent git history using diagrams like the one
below. Commits are shown as "o", and the links between them with
lines drawn with - / and \. Time goes left to right:</p><pre class="literallayout"> o--o--o <-- Branch A
$ chmod a+x hooks/post-update</p></div><p>(For an explanation of the last two lines, see
<a href="git-update-server-info.html" target="_top">git-update-server-info(1)</a>, and the documentation
<a href="hooks.html" target="_top">Hooks used by git</a>.)</p><p>Advertise the url of proj.git. Anybody else should then be able to
-clone or pull from that url, for example with a commandline like:</p><div class="literallayout"><p>$ git clone http://yourserver.com/~you/proj.git</p></div><p>(See also
+clone or pull from that url, for example with a command
line like:</p><div class="literallayout"><p>$ git clone http://yourserver.com/~you/proj.git</p></div><p>(See also
<a href="howto/setup-git-server-over-http.txt" target="_top">setup-git-server-over-http</a>
for a slightly more sophisticated setup using WebDAV which also
allows pushing over http.)</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="pushing-changes-to-a-public-repository"></a>Pushing changes to a public repository</h3></div></div></div><p>Note that the two techniques outlined above (exporting via
diff hunk and choosing "Stage Hunk for Commit").</p><p>Another technique is to use git-format-patch to create a series of
patches, then reset the state to before the patches:</p><div class="literallayout"><p>$ git format-patch origin<br>
$ git reset --hard origin</p></div><p>Then modify, reorder, or eliminate patches as preferred before applying
-them again with <a href="git-am.html" target="_top">git-am(1)</a>.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="patch-series-tools"></a>Other tools</h2></div></div></div><p>There are numerous other tools, such as stgit, which exist for the
+them again with <a href="git-am.html" target="_top">git-am(1)</a>.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="patch-series-tools"></a>Other tools</h2></div></div></div><p>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.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="problems-with-rewriting-history"></a>Problems with rewriting history</h2></div></div></div><p>The primary problem with rewriting the history of a branch has to do
with merging. Suppose somebody fetches your branch and merges it into
branch with your commits:</p><div class="literallayout"><p>$ git push ssh://example.com/project.git mybranch:theirbranch</p></div><p>When remote and local branch are both named "test":</p><div class="literallayout"><p>$ git push ssh://example.com/project.git test</p></div><p>Shortcut version for a frequently used remote repository:</p><div class="literallayout"><p>$ git remote add example ssh://example.com/project.git<br>
$ git push example test</p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="repository-maintenance"></a>Repository maintenance</h2></div></div></div><p>Check for corruption:</p><div class="literallayout"><p>$ git fsck</p></div><p>Recompress, remove unused cruft:</p><div class="literallayout"><p>$ git gc</p></div></div></div><div class="appendix" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="todo"></a>Appendix B. Notes and todo list for this manual</h2></div></div></div><p>This is a work in progress.</p><p>The basic requirements:
- It must be readable in order, from beginning to end, by
- someone intelligent with a basic grasp of the unix
- commandline, but without any special knowledge of git. If
+ someone intelligent with a basic grasp of the UNIX
+ command line, but without any special knowledge of git. If
necessary, any other prerequisites should be specifically
mentioned as they arise.
- Whenever possible, section headings should clearly describe
Git is a fast distributed revision control system.
-This manual is designed to be readable by someone with basic unix
+This manual is designed to be readable by someone with basic UNIX
command-line skills, but no previous knowledge of git.
<<repositories-and-branches>> and <<exploring-git-history>> explain how
In the following, we say that commit X is "reachable" from commit Y
if commit X is an ancestor of commit Y. Equivalently, you could say
-that Y is a descendent of X, or that there is a chain of parents
+that Y is a descendant of X, or that there is a chain of parents
leading from commit Y to commit X.
[[history-diagrams]]
link:hooks.html[Hooks used by git].)
Advertise the url of proj.git. Anybody else should then be able to
-clone or pull from that url, for example with a commandline like:
+clone or pull from that url, for example with a command line like:
-------------------------------------------------
$ git clone http://yourserver.com/~you/proj.git
Other tools
-----------
-There are numerous other tools, such as stgit, which exist for the
+There are numerous other tools, such as StGIT, which exist for the
purpose of maintaining a patch series. These are outside of the scope of
this manual.
The basic requirements:
- It must be readable in order, from beginning to end, by
- someone intelligent with a basic grasp of the unix
- commandline, but without any special knowledge of git. If
+ someone intelligent with a basic grasp of the UNIX
+ command line, but without any special knowledge of git. If
necessary, any other prerequisites should be specifically
mentioned as they arise.
- Whenever possible, section headings should clearly describe
projects / git.git / commitdiff