------------------
The git configuration file contains a number of variables that affect
-the git commands behaviour. They can be used by both the git plumbing
+the git commands behavior. They can be used by both the git plumbing
and the porcelains. The variables are divided to 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
may be set multiple times and is matched in the given order;
the first match wins.
- Can be overriden 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).
This is sometimes needed to work with old scripts that
expect HEAD to be a symbolic link.
+core.logAllRefUpdates::
+ If true, `git-update-ref` will append a line to
+ "$GIT_DIR/logs/<ref>" listing the new SHA1 and the date/time
+ of the update. If the file does not exist it will be
+ created automatically. This information can be used to
+ determine what commit was the tip of a branch "2 days ago".
+ This value is false by default (no logging).
+
core.repositoryFormatVersion::
Internal variable identifying the repository format and layout
version.
http.sslKey::
File containing the SSL private key when fetching or pushing
- over HTTPS. Can be overriden by the 'GIT_SSL_KEY' environment
+ over HTTPS. Can be overridden by the 'GIT_SSL_KEY' environment
variable.
http.sslCAInfo::
File containing the certificates to verify the peer with when
- fetching or pushing over HTTPS. Can be overriden by the
+ fetching or pushing over HTTPS. Can be overridden by the
'GIT_SSL_CAINFO' environment variable.
http.sslCAPath::
by the 'GIT_SSL_CAPATH' environment variable.
http.maxRequests::
- How many HTTP requests to launch in parallel. Can be overriden
+ How many HTTP requests to launch in parallel. Can be overridden
by the 'GIT_HTTP_MAX_REQUESTS' environment variable. Default is 5.
http.lowSpeedLimit, http.lowSpeedTime::
If the HTTP transfer speed is less than 'http.lowSpeedLimit'
for longer than 'http.lowSpeedTime' seconds, the transfer is aborted.
- Can be overriden by the 'GIT_HTTP_LOW_SPEED_LIMIT' and
+ Can be overridden by the 'GIT_HTTP_LOW_SPEED_LIMIT' and
'GIT_HTTP_LOW_SPEED_TIME' environment variables.
i18n.commitEncoding::
user.email::
Your email address to be recorded in any newly created commits.
- Can be overriden by the 'GIT_AUTHOR_EMAIL' and 'GIT_COMMITTER_EMAIL'
+ Can be overridden by the 'GIT_AUTHOR_EMAIL' and 'GIT_COMMITTER_EMAIL'
environment variables. See gitlink:git-commit-tree[1].
user.name::
Your full name to be recorded in any newly created commits.
- Can be overriden by the 'GIT_AUTHOR_NAME' and 'GIT_COMMITTER_NAME'
+ Can be overridden by the 'GIT_AUTHOR_NAME' and 'GIT_COMMITTER_NAME'
environment variables. See gitlink:git-commit-tree[1].
whatchanged.difftree::
<pre><tt>$ git-cat-file -t 557db03de997c86a4a028e1ebd3a1ceb225be238</tt></pre>\r
</div></div>\r
<p>where the <tt>-t</tt> tells <tt>git-cat-file</tt> to tell you what the "type" of the\r
-object is. git will tell you that you have a "blob" object (ie just a\r
+object is. git will tell you that you have a "blob" object (i.e., just a\r
regular file), and you can see the contents with</p>\r
<div class="listingblock">\r
<div class="content">\r
<pre><tt>$ git tag -s <tagname></tt></pre>\r
</div></div>\r
<p>which will sign the current <tt>HEAD</tt> (but you can also give it another\r
-argument that specifies the thing to tag, ie you could have tagged the\r
+argument that specifies the thing to tag, i.e., you could have tagged the\r
current <tt>mybranch</tt> point by using <tt>git tag <tagname> mybranch</tt>).</p>\r
<p>You normally only do signed tags for major releases or things\r
like that, while the light-weight tags are useful for any marking you\r
using the object name of that commit object. Then it reads the\r
commit object to find out its parent commits and the associate\r
tree object; it repeats this process until it gets all the\r
-necessary objects. Because of this behaviour, they are\r
+necessary objects. Because of this behavior, they are\r
sometimes also called <em>commit walkers</em>.</p>\r
<p>The <em>commit walkers</em> are sometimes also called <em>dumb\r
transports</em>, because they do not require any git aware smart\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 30-May-2006 07:20:51 UTC\r
+Last updated 04-Jun-2006 07:24:36 UTC\r
</div>\r
</div>\r
</body>\r
----------------
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 (ie just a
+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
----------------
----------------
which will sign the current `HEAD` (but you can also give it another
-argument that specifies the thing to tag, ie you could have tagged the
+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
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 behaviour, they are
+necessary objects. Because of this behavior, they are
sometimes also called 'commit walkers'.
+
The 'commit walkers' are sometimes also called 'dumb
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">\r
<head>\r
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />\r
-<meta name="generator" content="AsciiDoc 7.0.1" />\r
+<meta name="generator" content="AsciiDoc 7.0.2" />\r
<style type="text/css">\r
/* Debug borders */\r
p, li, dt, dd, div, pre, h1, h2, h3, h4, h5, h6 {\r
</div>\r
<div id="preamble">\r
<div class="sectionbody">\r
-<p>So you're a CVS user. That's ok, it's a treatable condition. The job of\r
+<p>So you're a CVS user. That's OK, it's a treatable condition. The job of\r
this document is to put you on the road to recovery, by helping you\r
convert an existing cvs repository to git, and by showing you how to use a\r
git repository in a cvs-like fashion.</p>\r
<div class="title">Note</div>\r
</td>\r
<td class="content">\r
-<p>Because of this behaviour, if the shared repository and the developer's\r
+<p>Because of this behavior, if the shared repository and the developer's\r
repository both have branches named <tt>origin</tt>, then a push like the above\r
attempts to update the <tt>origin</tt> branch in the shared repository from the\r
developer's <tt>origin</tt> branch. The results may be unexpected, so it's\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 30-Jan-2006 23:10:24 PDT\r
+Last updated 04-Jun-2006 07:24:38 UTC\r
</div>\r
</div>\r
</body>\r
git for CVS users
=================
-So you're a CVS user. That's ok, it's a treatable condition. The job of
+So you're a CVS user. That's OK, it's a treatable condition. The job of
this document is to put you on the road to recovery, by helping you
convert an existing cvs repository to git, and by showing you how to use a
git repository in a cvs-like fashion.
[NOTE]
============
-Because of this behaviour, if the shared repository and the developer's
+Because of this behavior, if the shared repository and the developer's
repository both have branches named `origin`, then a push like the above
attempts to update the `origin` branch in the shared repository from the
developer's `origin` branch. The results may be unexpected, so it's
When <tt>git-apply</tt> is used for statistics and not applying a\r
patch, it defaults to <tt>nowarn</tt>.\r
You can use different <tt><option></tt> to control this\r
- behaviour:\r
+ behavior:\r
</p>\r
<ul>\r
<li>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 13-Apr-2006 07:45:00 UTC\r
+Last updated 04-Jun-2006 07:24:20 UTC\r
</div>\r
</div>\r
</body>\r
When `git-apply` is used for statistics and not applying a
patch, it defaults to `nowarn`.
You can use different `<option>` to control this
- behaviour:
+ behavior:
+
* `nowarn` turns off the trailing whitespace warning.
* `warn` outputs warnings for a few such errors, but applies the
<div class="sectionbody">\r
<dl>\r
<dt>\r
--c, --compability\r
+-c, --compatibility\r
</dt>\r
<dd>\r
<p>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 18-Apr-2006 21:30:44 UTC\r
+Last updated 04-Jun-2006 07:24:21 UTC\r
</div>\r
</div>\r
</body>\r
OPTIONS
-------
--c, --compability::
+-c, --compatibility::
Use the same output mode as git-annotate (Default: off).
-l, --long::
<div class="sectionbody">\r
<div class="verseblock">\r
<div class="content"><em>git-branch</em> [-r]\r
-<em>git-branch</em> [-f] <branchname> [<start-point>]\r
+<em>git-branch</em> [-l] [-f] <branchname> [<start-point>]\r
<em>git-branch</em> (-d | -D) <branchname>…</div></div>\r
</div>\r
<h2>DESCRIPTION</h2>\r
If no <start-point> is given, the branch will be created with a head\r
equal to that of the currently checked out branch.</p>\r
<p>With a <tt>-d</tt> or <tt>-D</tt> option, <tt><branchname></tt> will be deleted. You may\r
-specify more than one branch for deletion.</p>\r
+specify more than one branch for deletion. If the branch currently\r
+has a ref log then the ref log will also be deleted.</p>\r
</div>\r
<h2>OPTIONS</h2>\r
<div class="sectionbody">\r
</p>\r
</dd>\r
<dt>\r
+-l\r
+</dt>\r
+<dd>\r
+<p>\r
+ Create the branch's ref log. This activates recording of\r
+ all changes to made the branch ref, enabling use of date\r
+</p>\r
+</dd>\r
+<dt>\r
-f\r
</dt>\r
<dd>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 21-May-2006 10:50:03 UTC\r
+Last updated 04-Jun-2006 07:24:21 UTC\r
</div>\r
</div>\r
</body>\r
--------
[verse]
'git-branch' [-r]
-'git-branch' [-f] <branchname> [<start-point>]
+'git-branch' [-l] [-f] <branchname> [<start-point>]
'git-branch' (-d | -D) <branchname>...
DESCRIPTION
equal to that of the currently checked out branch.
With a `-d` or `-D` option, `<branchname>` will be deleted. You may
-specify more than one branch for deletion.
+specify more than one branch for deletion. If the branch currently
+has a ref log then the ref log will also be deleted.
OPTIONS
-D::
Delete a branch irrespective of its index status.
+-l::
+ Create the branch's ref log. This activates recording of
+ all changes to made the branch ref, enabling use of date
+ based sha1 expressions such as "<branchname>@{yesterday}".
+
-f::
Force the creation of a new branch even if it means deleting
a branch that already exists with the same name.
<h2>SYNOPSIS</h2>\r
<div class="sectionbody">\r
<div class="verseblock">\r
-<div class="content"><em>git-checkout</em> [-f] [-b <new_branch>] [-m] [<branch>]\r
+<div class="content"><em>git-checkout</em> [-f] [-b <new_branch> [-l]] [-m] [<branch>]\r
<em>git-checkout</em> [-m] [<branch>] <paths>…</div></div>\r
</div>\r
<h2>DESCRIPTION</h2>\r
</p>\r
</dd>\r
<dt>\r
+-l\r
+</dt>\r
+<dd>\r
+<p>\r
+ Create the new branch's ref log. This activates recording of\r
+ all changes to made the branch ref, enabling use of date\r
+</p>\r
+</dd>\r
+<dt>\r
-m\r
</dt>\r
<dd>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 21-May-2006 10:50:03 UTC\r
+Last updated 04-Jun-2006 07:24:22 UTC\r
</div>\r
</div>\r
</body>\r
SYNOPSIS
--------
[verse]
-'git-checkout' [-f] [-b <new_branch>] [-m] [<branch>]
+'git-checkout' [-f] [-b <new_branch> [-l]] [-m] [<branch>]
'git-checkout' [-m] [<branch>] <paths>...
DESCRIPTION
by gitlink:git-check-ref-format[1]. Some of these checks
may restrict the characters allowed in a branch name.
+-l::
+ Create the new branch's ref log. This activates recording of
+ all changes to made the branch ref, enabling use of date
+ based sha1 expressions such as "<branchname>@{yesterday}".
+
-m::
If you have local modifications to one or more files that
are different between the current branch and the branch to
Instead of committing only the files specified on the\r
command line, update them in the index file and then\r
commit the whole index. This is the traditional\r
- behaviour.\r
+ behavior.\r
</p>\r
</dd>\r
<dt>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 05-May-2006 23:14:12 UTC\r
+Last updated 04-Jun-2006 07:24:22 UTC\r
</div>\r
</div>\r
</body>\r
Instead of committing only the files specified on the
command line, update them in the index file and then
commit the whole index. This is the traditional
- behaviour.
+ behavior.
-o|--only::
Commit only the files specified on the command line.
</p>\r
</li>\r
</ol>\r
-<p>Protocol notes: If you are using anonymous acces via pserver, just select that.\r
+<p>Protocol notes: If you are using anonymous access via pserver, just select that.\r
Those using SSH access should choose the <em>ext</em> protocol, and configure <em>ext</em>\r
access on the Preferences->Team->CVS->ExtConnection pane. Set CVS_SERVER to\r
<em>git-cvsserver</em>. Not that password support is not good when using <em>ext</em>,\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 05-Mar-2006 10:51:09 UTC\r
+Last updated 04-Jun-2006 07:24:23 UTC\r
</div>\r
</div>\r
</body>\r
4. 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 acces 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'. Not that password support is not good when using 'ext',
aka 9418. It waits for a connection, and will just execute "git-upload-pack"\r
when it gets one.</p>\r
<p>It's careful in that there's a magic request-line that gives the command and\r
-what directory to upload, and it verifies that the directory is ok.</p>\r
+what directory to upload, and it verifies that the directory is OK.</p>\r
<p>It verifies that the directory has the magic file "git-daemon-export-ok", and\r
it will refuse to export any git directory that hasn't explicitly been marked\r
for export this way (unless the <em>--export-all</em> parameter is specified). If you\r
pass some directory paths as <em>git-daemon</em> arguments, you can further restrict\r
the offers to a whitelist comprising of those.</p>\r
-<p>This is ideally suited for read-only updates, ie pulling from git repositories.</p>\r
+<p>This is ideally suited for read-only updates, i.e., pulling from git repositories.</p>\r
</div>\r
<h2>OPTIONS</h2>\r
<div class="sectionbody">\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 10-Mar-2006 00:31:23 UTC\r
+Last updated 04-Jun-2006 07:24:23 UTC\r
</div>\r
</div>\r
</body>\r
when it gets one.
It's careful in that there's a magic request-line that gives the command and
-what directory to upload, and it verifies that the directory is ok.
+what directory to upload, and it verifies that the directory is OK.
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
pass some directory paths as 'git-daemon' arguments, you can further restrict
the offers to a whitelist comprising of those.
-This is ideally suited for read-only updates, ie pulling from git repositories.
+This is ideally suited for read-only updates, i.e., pulling from git repositories.
OPTIONS
-------
<pre><tt>torvalds@ppc970:~/v2.6/linux> git-diff-index HEAD\r
*100644->100664 blob 7476bb......->000000...... kernel/sched.c</tt></pre>\r
</div></div>\r
-<p>ie it shows that the tree has changed, and that <tt>kernel/sched.c</tt> has is\r
+<p>i.e., it shows that the tree has changed, and that <tt>kernel/sched.c</tt> has is\r
not up-to-date and may contain new stuff. The all-zero sha1 means that to\r
get the real diff, you need to look at the object in the working directory\r
directly rather than do an object-to-object diff.</p>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 17-May-2006 10:34:00 UTC\r
+Last updated 04-Jun-2006 07:24:24 UTC\r
</div>\r
</div>\r
</body>\r
torvalds@ppc970:~/v2.6/linux> git-diff-index HEAD
*100644->100664 blob 7476bb......->000000...... kernel/sched.c
-ie 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.
<p>\r
If provided, the results are limited to a subset of files\r
matching one of these prefix strings.\r
- ie file matches <tt>/^<pattern1>|<pattern2>|…/</tt>\r
+ i.e., file matches <tt>/^<pattern1>|<pattern2>|…/</tt>\r
Note that this parameter does not provide any wildcard or regexp\r
features.\r
</p>\r
</p>\r
<p>When a single commit is given on one line of such input, it compares\r
the commit with its parents. The following flags further affects its\r
-behaviour. This does not apply to the case where two <tree-ish>\r
+behavior. This does not apply to the case where two <tree-ish>\r
separated with a single space are given.</p>\r
</dd>\r
<dt>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 17-May-2006 10:34:02 UTC\r
+Last updated 04-Jun-2006 07:24:25 UTC\r
</div>\r
</div>\r
</body>\r
<path>...::
If provided, the results are limited to a subset of files
matching one of these prefix strings.
- i
e file matches `/^<pattern1>|<pattern2>|.../`
+ i
.e., file matches `/^<pattern1>|<pattern2>|.../`
Note that this parameter does not provide any wildcard or regexp
features.
+
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
-behaviour. This does not apply to the case where two <tree-ish>
+behavior. This does not apply to the case where two <tree-ish>
separated with a single space are given.
-m::
<p>\r
show only names and the nature of change, but not actual\r
diff output. --name-status disables usual patch generation\r
-which in turn also disables recursive behaviour, so without -r\r
+which in turn also disables recursive behavior, so without -r\r
you would only see the directory name if there is a change in a\r
file in a subdirectory.\r
</p>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 29-Apr-2006 07:01:33 UTC\r
+Last updated 04-Jun-2006 07:24:26 UTC\r
</div>\r
</div>\r
</body>\r
nor deletion.
<2> show only names and the nature of change, but not actual
diff output. --name-status disables usual patch generation
-which in turn also disables recursive behaviour, so without -r
+which in turn also disables recursive behavior, so without -r
you would only see the directory name if there is a change in a
file in a subdirectory.
<3> limit diff output to named subtrees.
<h2>SYNOPSIS</h2>\r
<div class="sectionbody">\r
<div class="verseblock">\r
-<div class="content"><em>git-format-patch</em> [-n | -k] [-o <dir> | --stdout] [--attach] [-s] [-c]\r
- [--diff-options] <his> [<mine>]</div></div>\r
+<div class="content"><em>git-format-patch</em> [-n | -k] [-o <dir> | --stdout] [--attach]\r
+ [-s | --signoff] [--diff-options] [--start-number <n>]\r
+ <since>[..<until>]</div></div>\r
</div>\r
<h2>DESCRIPTION</h2>\r
<div class="sectionbody">\r
-<p>Prepare each commit with its patch since <mine> head forked from\r
-<his> head, one file per patch formatted to resemble UNIX mailbox\r
-format, for e-mail submission or use with <a href="git-am.html">git-am(1)</a>.</p>\r
+<p>Prepare each commit between <since> and <until> with its patch in\r
+one file per commit, formatted to resemble UNIX mailbox format.\r
+If ..<until> is not specified, the head of the current working\r
+tree is implied.</p>\r
+<p>The output of this command is convenient for e-mail submission or\r
+for use with <a href="git-am.html">git-am(1)</a>.</p>\r
<p>Each output file is numbered sequentially from 1, and uses the\r
-first line of the commit message (massaged for pathname safety)\r
-as the filename.</p>\r
-<p>When -o is specified, output files are created in <dir>; otherwise\r
-they are created in the current working directory. This option\r
-is ignored if --stdout is specified.</p>\r
-<p>When -n is specified, instead of "[PATCH] Subject", the first\r
-line is formatted as "[PATCH N/M] Subject", unless you have only\r
-one patch.</p>\r
+first line of the commit message (massaged for pathname safety) as\r
+the filename. The names of the output files are printed to standard\r
+output, unless the --stdout option is specified.</p>\r
+<p>If -o is specified, output files are created in <dir>. Otherwise\r
+they are created in the current working directory.</p>\r
+<p>If -n is specified, instead of "[PATCH] Subject", the first line\r
+is formatted as "[PATCH n/m] Subject".</p>\r
</div>\r
<h2>OPTIONS</h2>\r
<div class="sectionbody">\r
<dd>\r
<p>\r
Use <dir> to store the resulting files, instead of the\r
- current working directory.\r
+ current working directory. This option is ignored if\r
+ --stdout is specified.\r
</p>\r
</dd>\r
<dt>\r
</p>\r
</dd>\r
<dt>\r
--k|--keep-subject\r
+--start-number <n>\r
</dt>\r
<dd>\r
<p>\r
- Do not strip/add <em>[PATCH]</em> from the first line of the\r
- commit log message.\r
+ Start numbering the patches at <n> instead of 1.\r
</p>\r
</dd>\r
<dt>\r
--s|--signoff\r
+-k|--keep-subject\r
</dt>\r
<dd>\r
<p>\r
- Add <tt>Signed-off-by:</tt> line to the commit message, using\r
- the committer identity of yourself.\r
+ Do not strip/add <em>[PATCH]</em> from the first line of the\r
+ commit log message.\r
</p>\r
</dd>\r
<dt>\r
--c|--check\r
+-s|--signoff\r
</dt>\r
<dd>\r
<p>\r
- Display suspicious lines in the patch. The definition\r
- of <em>suspicious lines</em> is currently the lines that has\r
- trailing whitespaces, and the lines whose indentation\r
- has a SP character immediately followed by a TAB\r
- character.\r
+ Add <tt>Signed-off-by:</tt> line to the commit message, using\r
+ the committer identity of yourself.\r
</p>\r
</dd>\r
<dt>\r
</dt>\r
<dd>\r
<p>\r
- This flag generates the mbox formatted output to the\r
- standard output, instead of saving them into a file per\r
- patch and implies --mbox.\r
+ Print all commits to the standard output in mbox format,\r
+ instead of creating a file for each one.\r
</p>\r
</dd>\r
<dt>\r
</dt>\r
<dd>\r
<p>\r
- Extract commits the current branch accumulated since it\r
- pulled from origin the last time in a patch form for\r
- e-mail submission.\r
+ Extract all commits which are in the current branch but\r
+ not in the origin branch. For each commit a separate file\r
+ is created in the current directory.\r
</p>\r
</dd>\r
<dt>\r
</dt>\r
<dd>\r
<p>\r
- The same as the previous one, except detect and handle\r
- renames and complete rewrites intelligently to produce\r
- renaming patch. A renaming patch reduces the amount of\r
- text output, and generally makes it easier to review\r
- it. Note that the "patch" program does not understand\r
- renaming patch well, so use it only when you know the\r
- recipient uses git to apply your patch.\r
+ The same as the previous one. Additionally, it detects\r
+ and handles renames and complete rewrites intelligently to\r
+ produce a renaming patch. A renaming patch reduces the\r
+ amount of text output, and generally makes it easier to\r
+ review it. Note that the "patch" program does not\r
+ understand renaming patches, so use it only when you know\r
+ the recipient uses git to apply your patch.\r
</p>\r
</dd>\r
</dl>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 11-Mar-2006 08:04:28 UTC\r
+Last updated 04-Jun-2006 07:24:26 UTC\r
</div>\r
</div>\r
</body>\r
SYNOPSIS
--------
[verse]
-'git-format-patch' [-n | -k] [-o <dir> | --stdout] [--attach] [-s] [-c]
- [--diff-options] <his> [<mine>]
+'git-format-patch' [-n | -k] [-o <dir> | --stdout] [--attach]
+ [-s | --signoff] [--diff-options] [--start-number <n>]
+ <since>[..<until>]
DESCRIPTION
-----------
-Prepare each commit with its patch since <mine> head forked from
-<his> head, one file per patch formatted to resemble UNIX mailbox
-format, for e-mail submission or use with gitlink:git-am[1].
+
+Prepare each commit between <since> and <until> with its patch in
+one file per commit, formatted to resemble UNIX mailbox format.
+If ..<until> is not specified, the head of the current working
+tree is implied.
+
+The output of this command is convenient for e-mail submission or
+for use with gitlink:git-am[1].
Each output file is numbered sequentially from 1, and uses the
-first line of the commit message (massaged for pathname safety)
-as the filename.
+first line of the commit message (massaged for pathname safety) as
+the filename. The names of the output files are printed to standard
+output, unless the --stdout option is specified.
-When -o is specified, output files are created in <dir>; otherwise
-they are created in the current working directory. This option
-is ignored if --stdout is specified.
+If -o is specified, output files are created in <dir>. Otherwise
+they are created in the current working directory.
-When -n is specified, instead of "[PATCH] Subject", the first
-line is formatted as "[PATCH N/M] Subject", unless you have only
-one patch.
+If -n is specified, instead of "[PATCH] Subject", the first line
+is formatted as "[PATCH n/m] Subject".
OPTIONS
-------
-o|--output-directory <dir>::
Use <dir> to store the resulting files, instead of the
- current working directory.
+ current working directory. This option is ignored if
+ --stdout is specified.
-n|--numbered::
Name output in '[PATCH n/m]' format.
+--start-number <n>::
+ Start numbering the patches at <n> instead of 1.
+
-k|--keep-subject::
Do not strip/add '[PATCH]' from the first line of the
commit log message.
Add `Signed-off-by:` line to the commit message, using
the committer identity of yourself.
--c|--check::
- Display suspicious lines in the patch. The definition
- of 'suspicious lines' is currently the lines that has
- trailing whitespaces, and the lines whose indentation
- has a SP character immediately followed by a TAB
- character.
-
--stdout::
- This flag generates the mbox formatted output to the
- standard output, instead of saving them into a file per
- patch and implies --mbox.
+ Print all commits to the standard output in mbox format,
+ instead of creating a file for each one.
--attach::
Create attachments instead of inlining patches.
cherry-pick them.
git-format-patch origin::
- Extract commits the current branch accumulated since it
- pulled from origin the last time in a patch form for
- e-mail submission.
+ Extract all commits which are in the current branch but
+ not in the origin branch. For each commit a separate file
+ is created in the current directory.
git-format-patch -M -B origin::
- The same as the previous one, except detect and handle
- renames and complete rewrites intelligently to produce
- 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 patch well, so use it only when you know the
- recipient uses git to apply your patch.
+ The same as the previous one. 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.
See Also
sorted properly etc), but on the whole if "git-fsck-objects" is happy, you\r
do have a valid tree.</p>\r
<p>Any corrupt objects you will have to find in backups or other archives\r
-(ie you can just remove them and do an "rsync" with some other site in\r
+(i.e., you can just remove them and do an "rsync" with some other site in\r
the hopes that somebody else has the object you have corrupted).</p>\r
<p>Of course, "valid tree" doesn't mean that it wasn't generated by some\r
evil person, and the end result might be crap. git is a revision\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 13-Mar-2006 08:20:13 UTC\r
+Last updated 04-Jun-2006 07:24:27 UTC\r
</div>\r
</div>\r
</body>\r
do have a valid tree.
Any corrupt objects you will have to find in backups or other archives
-(ie 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
<dd>\r
<p>\r
Instead of searching in the working tree files, check\r
- the blobs registerd in the index file.\r
+ the blobs registered in the index file.\r
</p>\r
</dd>\r
<dt>\r
<p>\r
Show <tt>context</tt> trailing (<tt>A</tt> — after), or leading (<tt>B</tt>\r
— before), or both (<tt>C</tt> — context) lines, and place a\r
- line containing <tt>--</tt> between continguous groups of\r
+ line containing <tt>--</tt> between contiguous groups of\r
matches.\r
</p>\r
</dd>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 16-May-2006 02:14:10 UTC\r
+Last updated 04-Jun-2006 07:24:27 UTC\r
</div>\r
</div>\r
</body>\r
-------
--cached::
Instead of searching in the working tree files, check
- the blobs registerd in the index file.
+ the blobs registered in the index file.
-a | --text::
Process binary files as if they were text.
-[ABC] <context>::
Show `context` trailing (`A` -- after), or leading (`B`
-- before), or both (`C` -- context) lines, and place a
- line containing `--` between continguous groups of
+ line containing `--` between contiguous groups of
matches.
-f <file>::
fatal: merge program failed</tt></pre>\r
</div></div>\r
<p>where the latter example shows how "git-merge-index" will stop trying to\r
-merge once anything has returned an error (ie "cat" returned an error\r
+merge once anything has returned an error (i.e., "cat" returned an error\r
for the AA file, because it didn't exist in the original, and thus\r
"git-merge-index" didn't even try to merge the MM thing).</p>\r
</div>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 05-May-2006 23:14:13 UTC\r
+Last updated 04-Jun-2006 07:24:28 UTC\r
</div>\r
</div>\r
</body>\r
fatal: merge program failed
where the latter example shows how "git-merge-index" will stop trying to
-merge once anything has returned an error (ie "cat" returned an error
+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).
<div class="sectionbody">\r
<p>A "patch ID" is nothing but a SHA1 of the diff associated with a patch, with\r
whitespace and line numbers ignored. As such, it's "reasonably stable", but at\r
-the same time also reasonably unique, ie two patches that have the same "patch\r
+the same time also reasonably unique, i.e., two patches that have the same "patch\r
ID" are almost guaranteed to be the same thing.</p>\r
<p>IOW, you can use this thing to look for likely duplicate commits.</p>\r
<p>When dealing with git-diff-tree output, it takes advantage of\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 10-Mar-2006 00:31:30 UTC\r
+Last updated 04-Jun-2006 07:24:28 UTC\r
</div>\r
</div>\r
</body>\r
-----------
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, ie two patches that have the same "patch
+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.
<p>The <tt>git-write-tree</tt> command refuses to write a nonsensical tree, and it\r
will complain about unmerged entries if it sees a single entry that is not\r
stage 0.</p>\r
-<p>Ok, this all sounds like a collection of totally nonsensical rules,\r
+<p>OK, this all sounds like a collection of totally nonsensical rules,\r
but it's actually exactly what you want in order to do a fast\r
merge. The different stages represent the "result tree" (stage 0, aka\r
"merged"), the original tree (stage 1, aka "orig"), and the two trees\r
<p>\r
the index file saves and restores with all this information, so you\r
can merge things incrementally, but as long as it has entries in\r
- stages 1/2/3 (ie "unmerged entries") you can't write the result. So\r
+ stages 1/2/3 (i.e., "unmerged entries") you can't write the result. So\r
now the merge algorithm ends up being really simple:\r
</p>\r
<ul>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 02-Mar-2006 09:14:48 UTC\r
+Last updated 04-Jun-2006 07:24:29 UTC\r
</div>\r
</div>\r
</body>\r
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,
+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
- the index file saves and restores with all this information, so you
can merge things incrementally, but as long as it has entries in
- stages 1/2/3 (ie "unmerged entries") you can't write the result. So
+ 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,
</dt>\r
<dd>\r
<p>\r
- Default behaviour is to replace at most one line. This replaces\r
+ Default behavior is to replace at most one line. This replaces\r
all lines matching the key (and optionally the value_regex).\r
</p>\r
</dd>\r
<h2>CONFIGURATION FILE</h2>\r
<div class="sectionbody">\r
<p>The git configuration file contains a number of variables that affect\r
-the git commands behaviour. They can be used by both the git plumbing\r
+the git commands behavior. They can be used by both the git plumbing\r
and the porcelains. The variables are divided to sections, where\r
in the fully qualified variable name the variable itself is the last\r
dot-separated segment and the section name is everything before the last\r
</p>\r
<div class="literalblock">\r
<div class="content">\r
-<pre><tt>Can be overriden by the 'GIT_PROXY_COMMAND' environment variable\r
+<pre><tt>Can be overridden by the 'GIT_PROXY_COMMAND' environment variable\r
(which always applies universally, without the special "for"\r
handling).</tt></pre>\r
</div></div>\r
</p>\r
</dd>\r
<dt>\r
+core.logAllRefUpdates\r
+</dt>\r
+<dd>\r
+<p>\r
+ If true, <tt>git-update-ref</tt> will append a line to\r
+ "$GIT_DIR/logs/<ref>" listing the new SHA1 and the date/time\r
+ of the update. If the file does not exist it will be\r
+ created automatically. This information can be used to\r
+ determine what commit was the tip of a branch "2 days ago".\r
+ This value is false by default (no logging).\r
+</p>\r
+</dd>\r
+<dt>\r
core.repositoryFormatVersion\r
</dt>\r
<dd>\r
<dd>\r
<p>\r
File containing the SSL private key when fetching or pushing\r
- over HTTPS. Can be overriden by the <em>GIT_SSL_KEY</em> environment\r
+ over HTTPS. Can be overridden by the <em>GIT_SSL_KEY</em> environment\r
variable.\r
</p>\r
</dd>\r
<dd>\r
<p>\r
File containing the certificates to verify the peer with when\r
- fetching or pushing over HTTPS. Can be overriden by the\r
+ fetching or pushing over HTTPS. Can be overridden by the\r
<em>GIT_SSL_CAINFO</em> environment variable.\r
</p>\r
</dd>\r
</dt>\r
<dd>\r
<p>\r
- How many HTTP requests to launch in parallel. Can be overriden\r
+ How many HTTP requests to launch in parallel. Can be overridden\r
by the <em>GIT_HTTP_MAX_REQUESTS</em> environment variable. Default is 5.\r
</p>\r
</dd>\r
<p>\r
If the HTTP transfer speed is less than <em>http.lowSpeedLimit</em>\r
for longer than <em>http.lowSpeedTime</em> seconds, the transfer is aborted.\r
- Can be overriden by the <em>GIT_HTTP_LOW_SPEED_LIMIT</em> and\r
+ Can be overridden by the <em>GIT_HTTP_LOW_SPEED_LIMIT</em> and\r
<em>GIT_HTTP_LOW_SPEED_TIME</em> environment variables.\r
</p>\r
</dd>\r
<dd>\r
<p>\r
Your email address to be recorded in any newly created commits.\r
- Can be overriden by the <em>GIT_AUTHOR_EMAIL</em> and <em>GIT_COMMITTER_EMAIL</em>\r
+ Can be overridden by the <em>GIT_AUTHOR_EMAIL</em> and <em>GIT_COMMITTER_EMAIL</em>\r
environment variables. See <a href="git-commit-tree.html">git-commit-tree(1)</a>.\r
</p>\r
</dd>\r
<dd>\r
<p>\r
Your full name to be recorded in any newly created commits.\r
- Can be overriden by the <em>GIT_AUTHOR_NAME</em> and <em>GIT_COMMITTER_NAME</em>\r
+ Can be overridden by the <em>GIT_AUTHOR_NAME</em> and <em>GIT_COMMITTER_NAME</em>\r
environment variables. See <a href="git-commit-tree.html">git-commit-tree(1)</a>.\r
</p>\r
</dd>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 07-May-2006 23:36:12 UTC\r
+Last updated 04-Jun-2006 07:24:29 UTC\r
</div>\r
</div>\r
</body>\r
-------
--replace-all::
- Default behaviour is to replace at most one line. This replaces
+ Default behavior is to replace at most one line. This replaces
all lines matching the key (and optionally the value_regex).
--get::
</dt>\r
<dd>\r
<p>\r
- Resets the index but not the working tree (ie, the changed files\r
+ Resets the index but not the working tree (i.e., the changed files\r
are preserved but not marked for commit) and reports what has not\r
been updated. This is the default action.\r
</p>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 05-May-2006 23:14:15 UTC\r
+Last updated 04-Jun-2006 07:24:30 UTC\r
</div>\r
</div>\r
</body>\r
OPTIONS
-------
--mixed::
- Resets the index but not the working tree (ie, the changed files
+ Resets the index but not the working tree (i.e., the changed files
are preserved but not marked for commit) and reports what has not
been updated. This is the default action.
</div>\r
<h2>DESCRIPTION</h2>\r
<div class="sectionbody">\r
-<p>Many git Porcelainish commands take mixture of flags\r
+<p>Many git porcelainish commands take mixture of flags\r
(i.e. parameters that begin with a dash <em>-</em>) and parameters\r
meant for underlying <tt>git-rev-list</tt> command they use internally\r
and flags and parameters for other commands they use as the\r
<dd>\r
<p>\r
Instead of outputting the full SHA1 values of object names try to\r
- abbriviate them to a shorter unique name. When no length is specified\r
+ abbreviate them to a shorter unique name. When no length is specified\r
7 is used. The minimum length is 4.\r
</p>\r
</dd>\r
</li>\r
<li>\r
<p>\r
+A suffix <em>@</em> followed by a date specification enclosed in a brace\r
+ pair (e.g. <em>{yesterday}</em>, <em>{1 month 2 weeks 3 days 1 hour 1\r
+ second ago}</em> or <em>{1979-02-26 18:30:00}</em>) to specify the value\r
+ of the ref at a prior point in time. This suffix may only be\r
+ used immediately following a ref name and the ref must have an\r
+ existing log ($GIT_DIR/logs/<ref>).\r
+</p>\r
+</li>\r
+<li>\r
+<p>\r
A suffix <em>^</em> to a revision parameter means the first parent of\r
that commit object. <em>^<n></em> means the <n>th parent (i.e.\r
<em>rev^</em>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 17-May-2006 10:34:04 UTC\r
+Last updated 04-Jun-2006 07:24:31 UTC\r
</div>\r
</div>\r
</body>\r
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 underlying `git-rev-list` command they use internally
and flags and parameters for other commands they use as the
--short, --short=number::
Instead of outputting the full SHA1 values of object names try to
- abbriviate them to a shorter unique name. When no length is specified
+ abbreviate them to a shorter unique name. When no length is specified
7 is used. The minimum length is 4.
--since=datestring, --after=datestring::
happen to have both heads/master and tags/master, you can
explicitly say 'heads/master' to tell git which one you mean.
+* A suffix '@' followed by a date specification enclosed in a brace
+ pair (e.g. '\{yesterday\}', '\{1 month 2 weeks 3 days 1 hour 1
+ second ago\}' or '\{1979-02-26 18:30:00\}') to specify the value
+ of the ref at a prior point in time. This suffix may only be
+ used immediately following a ref name and the ref must have an
+ existing log ($GIT_DIR/logs/<ref>).
+
* A suffix '{caret}' to a revision parameter means the first parent of
that commit object. '{caret}<n>' means the <n>th parent (i.e.
'rev{caret}'
</dt>\r
<dd>\r
<p>\r
- Do not add emails foudn in Signed-off-by: lines to the cc list.\r
+ Do not add emails found in Signed-off-by: lines to the cc list.\r
</p>\r
</dd>\r
<dt>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 15-Feb-2006 02:21:51 UTC\r
+Last updated 04-Jun-2006 07:24:32 UTC\r
</div>\r
</div>\r
</body>\r
is not set, this will be prompted for.
--no-signed-off-by-cc::
- Do not add emails foudn in Signed-off-by: lines to the cc list.
+ Do not add emails found in Signed-off-by: lines to the cc list.
--quiet::
Make git-send-email less verbose. One line per email should be
<div class="sectionbody">\r
<p>There are three ways to specify which refs to update on the\r
remote end.</p>\r
-<p>With <em>--all</em> flag, all refs that exist locally are transfered to\r
+<p>With <em>--all</em> flag, all refs that exist locally are transferred to\r
the remote side. You cannot specify any <em><ref></em> if you use\r
this flag.</p>\r
<p>Without <em>--all</em> and without any <em><ref></em>, the refs that exist\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 10-Mar-2006 00:31:35 UTC\r
+Last updated 04-Jun-2006 07:24:32 UTC\r
</div>\r
</div>\r
</body>\r
There are three ways to specify which refs to update on the
remote end.
-With '--all' flag, all refs that exist locally are transfered to
+With '--all' flag, all refs that exist locally are transferred to
the remote side. You cannot specify any '<ref>' if you use
this flag.
<h2>DESCRIPTION</h2>\r
<div class="sectionbody">\r
<p>Sets up the normal git environment variables and a few helper functions\r
-(currently just "die()"), and returns ok if it all looks like a git archive.\r
+(currently just "die()"), and returns OK if it all looks like a git archive.\r
So, to make the rest of the git scripts more careful and readable,\r
use it as follows:</p>\r
<div class="listingblock">\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 10-Mar-2006 00:31:37 UTC\r
+Last updated 04-Jun-2006 07:24:33 UTC\r
</div>\r
</div>\r
</body>\r
-----------
Sets up the normal git environment variables and a few helper functions
-(currently just "die()"), and returns ok if it all looks like a git archive.
+(currently just "die()"), and returns OK if it all looks like a git archive.
So, to make the rest of the git scripts more careful and readable,
use it as follows:
<p>This document presents a brief summary of each tool and the corresponding\r
link.</p>\r
</div>\r
-<h2>Alternative/Augmentative Procelains</h2>\r
+<h2>Alternative/Augmentative Porcelains</h2>\r
<div class="sectionbody">\r
<ul>\r
<li>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 05-Mar-2006 10:51:10 UTC\r
+Last updated 04-Jun-2006 07:24:40 UTC\r
</div>\r
</div>\r
</body>\r
link.
-Alternative/Augmentative Procelains
+Alternative/Augmentative Porcelains
-----------------------------------
- *Cogito* (http://www.kernel.org/pub/software/scm/cogito/)
<p>\r
If a specified file is in the index but is missing then it's\r
removed.\r
- Default behaviour is to ignore removed file.\r
+ Default behavior is to ignore removed file.\r
</p>\r
</dd>\r
<dt>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 10-May-2006 00:13:32 UTC\r
+Last updated 04-Jun-2006 07:24:33 UTC\r
</div>\r
</div>\r
</body>\r
--remove::
If a specified file is in the index but is missing then it's
removed.
- Default behaviour is to ignore removed file.
+ Default behavior is to ignore removed file.
--refresh::
Looks at the current index and checks to see if merges or
</div>\r
<h2>SYNOPSIS</h2>\r
<div class="sectionbody">\r
-<p><em>git-update-ref</em> <ref> <newvalue> [<oldvalue>]</p>\r
+<p><em>git-update-ref</em> [-m <reason>] <ref> <newvalue> [<oldvalue>]</p>\r
</div>\r
<h2>DESCRIPTION</h2>\r
<div class="sectionbody">\r
ref symlink to some other tree, if you have copied a whole\r
archive by creating a symlink tree).</p>\r
</div>\r
+<h2>Logging Updates</h2>\r
+<div class="sectionbody">\r
+<p>If config parameter "core.logAllRefUpdates" is true or the file\r
+"$GIT_DIR/logs/<ref>" exists then <tt>git-update-ref</tt> will append\r
+a line to the log file "$GIT_DIR/logs/<ref>" (dereferencing all\r
+symbolic refs before creating the log name) describing the change\r
+in ref value. Log lines are formatted as:</p>\r
+<ol>\r
+<li>\r
+<p>\r
+oldsha1 SP newsha1 SP committer LF\r
+</p>\r
+<p>Where "oldsha1" is the 40 character hexadecimal value previously\r
+stored in <ref>, "newsha1" is the 40 character hexadecimal value of\r
+<newvalue> and "committer" is the committer's name, email address\r
+and date in the standard GIT committer ident format.</p>\r
+</li>\r
+</ol>\r
+<p>Optionally with -m:</p>\r
+<ol>\r
+<li>\r
+<p>\r
+oldsha1 SP newsha1 SP committer TAB message LF\r
+</p>\r
+<p>Where all fields are as described above and "message" is the\r
+value supplied to the -m option.</p>\r
+</li>\r
+</ol>\r
+<p>An update will fail (without changing <ref>) if the current user is\r
+unable to create a new log file, append to the existing log file\r
+or does not have committer information available.</p>\r
+</div>\r
<h2>Author</h2>\r
<div class="sectionbody">\r
<p>Written by Linus Torvalds <torvalds@osdl.org>.</p>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 06-Mar-2006 07:10:16 UTC\r
+Last updated 04-Jun-2006 07:24:34 UTC\r
</div>\r
</div>\r
</body>\r
SYNOPSIS
--------
-'git-update-ref' <ref> <newvalue> [<oldvalue>]
+'git-update-ref'
[-m <reason>] <ref> <newvalue> [<oldvalue>]
DESCRIPTION
-----------
ref symlink to some other tree, if you have copied a whole
archive by creating a symlink tree).
+Logging Updates
+---------------
+If config parameter "core.logAllRefUpdates" is true or the file
+"$GIT_DIR/logs/<ref>" exists then `git-update-ref` will append
+a line to the log file "$GIT_DIR/logs/<ref>" (dereferencing all
+symbolic refs before creating the log name) describing the change
+in ref value. Log lines are formatted as:
+
+ . oldsha1 SP newsha1 SP committer LF
++
+Where "oldsha1" is the 40 character hexadecimal value previously
+stored in <ref>, "newsha1" is the 40 character hexadecimal value of
+<newvalue> and "committer" is the committer's name, email address
+and date in the standard GIT committer ident format.
+
+Optionally with -m:
+
+ . oldsha1 SP newsha1 SP committer TAB message LF
++
+Where all fields are as described above and "message" is the
+value supplied to the -m option.
+
+An update will fail (without changing <ref>) if the current user is
+unable to create a new log file, append to the existing log file
+or does not have committer information available.
+
Author
------
Written by Linus Torvalds <torvalds@osdl.org>.
<p>This hook is invoked by <tt>git-receive-pack</tt> on the remote repository,\r
which is happens when a <tt>git push</tt> is done on a local repository.\r
Just before updating the ref on the remote repository, the update hook\r
-is invoked. It's exit status determins the success or failure of\r
+is invoked. It's exit status determines the success or failure of\r
the ref update.</p>\r
<p>The hook executes once for each ref to be updated, and takes\r
three parameters:\r
so it is a poor place to do log old..new.</p>\r
<p>The default post-update hook, when enabled, runs\r
<tt>git-update-server-info</tt> to keep the information used by dumb\r
-transports (eg, http) up-to-date. If you are publishing\r
+transports (e.g., http) up-to-date. If you are publishing\r
a git repository that is accessible via http, you should\r
probably enable this hook.</p>\r
<p>The standard output of this hook is sent to /dev/null; if you\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 26-Mar-2006 01:49:03 UTC\r
+Last updated 04-Jun-2006 07:24:39 UTC\r
</div>\r
</div>\r
</body>\r
This hook is invoked by `git-receive-pack` on the remote repository,
which is 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. It's exit status determins the success or failure of
+is invoked. It's exit status determines the success or failure of
the ref update.
The hook executes once for each ref to be updated, and takes
The default post-update hook, when enabled, runs
`git-update-server-info` to keep the information used by dumb
-transports (eg, http) up-to-date. If you are publishing
+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.
fetch</tt>, <tt>git pull</tt> and <tt>git push</tt> commands.\r
</p>\r
</dd>\r
+<dt>\r
+logs\r
+</dt>\r
+<dd>\r
+<p>\r
+ Records of changes made to refs are stored in this\r
+ directory. See the documentation on git-update-ref\r
+ for more information.\r
+</p>\r
+</dd>\r
+<dt>\r
+logs/refs/heads/<tt>name</tt>\r
+</dt>\r
+<dd>\r
+<p>\r
+ Records all changes made to the branch tip named <tt>name</tt>.\r
+</p>\r
+</dd>\r
+<dt>\r
+logs/refs/tags/<tt>name</tt>\r
+</dt>\r
+<dd>\r
+<p>\r
+ Records all changes made to the tag named <tt>name</tt>.\r
+</p>\r
+</dd>\r
</dl>\r
</div>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 26-Mar-2006 01:49:02 UTC\r
+Last updated 04-Jun-2006 07:24:39 UTC\r
</div>\r
</div>\r
</body>\r
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.
+
+logs::
+ Records of changes made to refs are stored in this
+ directory. See the documentation on git-update-ref
+ for more information.
+
+logs/refs/heads/`name`::
+ Records all changes made to the branch tip named `name`.
+
+logs/refs/tags/`name`::
+ Records all changes made to the tag named `name`.
</div></div>\r
<p>A tree can refer to one or more "blob" objects, each corresponding to\r
a file. In addition, a tree can also refer to other tree objects,\r
-thus creating a directory heirarchy. You can examine the contents of\r
+thus creating a directory hierarchy. You can examine the contents of\r
any tree using ls-tree (remember that a long enough initial portion\r
of the SHA1 will also work):</p>\r
<div class="listingblock">\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 30-May-2006 07:20:51 UTC\r
+Last updated 04-Jun-2006 07:24:35 UTC\r
</div>\r
</div>\r
</body>\r
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 heirarchy. You can examine the contents of
+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):
</div></div>\r
<p>This creates a new directory "myrepo" containing a clone of Alice's\r
repository. The clone is on an equal footing with the original\r
-project, posessing its own copy of the original project's history.</p>\r
+project, possessing its own copy of the original project's history.</p>\r
<p>Bob then makes some changes and commits them:</p>\r
<div class="listingblock">\r
<div class="content">\r
</div></div>\r
<p>shows a list of all the changes that Bob made since he branched from\r
Alice's master branch.</p>\r
-<p>After examing those changes, and possibly fixing things, Alice can\r
+<p>After examining those changes, and possibly fixing things, Alice can\r
pull the changes into her master branch:</p>\r
<div class="listingblock">\r
<div class="content">\r
<div class="content">\r
<pre><tt>$ git grep "hello" v2.5</tt></pre>\r
</div></div>\r
-<p>searches for all occurences of "hello" in v2.5.</p>\r
+<p>searches for all occurrences of "hello" in v2.5.</p>\r
<p>If you leave out the commit name, git grep will search any of the\r
files it manages in your current directory. So</p>\r
<div class="listingblock">\r
</li>\r
<li>\r
<p>\r
-<a href="everyday.html">Everday GIT with 20 Commands Or So</a>\r
+<a href="everyday.html">Everyday GIT with 20 Commands Or So</a>\r
</p>\r
</li>\r
<li>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 30-May-2006 07:20:50 UTC\r
+Last updated 04-Jun-2006 07:24:34 UTC\r
</div>\r
</div>\r
</body>\r
This creates a new directory "myrepo" containing a clone of Alice's
repository. The clone is on an equal footing with the original
-project, posessing its own copy of the original project's history.
+project, possessing its own copy of the original project's history.
Bob then makes some changes and commits them:
shows a list of all the changes that Bob made since he branched from
Alice's master branch.
-After examing those changes, and possibly fixing things, Alice can
+After examining those changes, and possibly fixing things, Alice can
pull the changes into her master branch:
-------------------------------------
$ git grep "hello" v2.5
-------------------------------------
-searches for all occurences of "hello" in 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
files it manages in your current directory. So
smart enough to perform a close-to-optimal search even in the
case of complex non-linear history with lots of merged branches.
- * link:everyday.html[Everday GIT with 20 Commands Or So]
+ * link:everyday.html[Everyday GIT with 20 Commands Or So]
* link:cvs-migration.html[git for CVS users].
projects / git.git / commitdiff