.TP
\-\-whitespace=<option>
-When applying a patch, detect a new or modified line that ends with trailing whitespaces (this includes a line that solely consists of whitespaces)\&. By default, the command outputs warning messages and applies the patch\&. 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:
+When applying a patch, detect a new or modified line that ends with trailing whitespaces (this includes a line that solely consists of whitespaces)\&. By default, the command outputs warning messages and applies the patch\&. When git\-apply is used for statistics and not applying a patch, it defaults to nowarn\&. You can use different <option> to control this behavior:
.RS
.TP 3
.SH "OPTIONS"
.TP
-\-c, \-\-compability
+\-c, \-\-compatibility
Use the same output mode as git\-annotate (Default: off)\&.
.TP
.nf
\fIgit\-branch\fR [\-r]
-\fIgit\-branch\fR [\-f] <branchname> [<start\-point>]
+\fIgit\-branch\fR [\-l] [\-f] <branchname> [<start\-point>]
\fIgit\-branch\fR (\-d | \-D) <branchname>...
.fi
In its second form, a new branch named <branchname> will be created\&. It will start out with a head equal to the one given as <start\-point>\&. If no <start\-point> is given, the branch will be created with a head equal to that of the currently checked out branch\&.
-With a \-d or \-D option, <branchname> will be deleted\&. You may specify more than one branch for deletion\&.
+With a \-d or \-D option, <branchname> will be deleted\&. You may specify more than one branch for deletion\&. If the branch currently has a ref log then the ref log will also be deleted\&.
.SH "OPTIONS"
\-D
Delete a branch irrespective of its index status\&.
+.TP
+\-l
+Create the branch's ref log\&. This activates recording of all changes to made the branch ref, enabling use of date
+
.TP
\-f
Force the creation of a new branch even if it means deleting a branch that already exists with the same name\&.
.SH "SYNOPSIS"
.nf
-\fIgit\-checkout\fR [\-f] [\-b <new_branch>] [\-m] [<branch>]
+\fIgit\-checkout\fR [\-f] [\-b <new_branch> [\-l]] [\-m] [<branch>]
\fIgit\-checkout\fR [\-m] [<branch>] <paths>...
.fi
\-b
Create a new branch named <new_branch> and start it at <branch>\&. The new branch name must pass all checks defined by \fBgit\-check\-ref\-format\fR(1)\&. Some of these checks may restrict the characters allowed in a branch name\&.
+.TP
+\-l
+Create the new branch's ref log\&. This activates recording of all changes to made the branch ref, enabling use of date
+
.TP
\-m
If you have local modifications to one or more files that are different between the current branch and the branch to which you are switching, the command refuses to switch branches in order to preserve your modifications in context\&. However, with this option, a three\-way merge between the current branch, your working tree contents, and the new branch is done, and you will be on the new branch\&.
.TP
\-i|\-\-include
-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\&.
+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 behavior\&.
.TP
\-o|\-\-only
.LP
-Protocol notes: If you are using anonymous acces via pserver, just select that\&. Those using SSH access should choose the \fIext\fR protocol, and configure \fIext\fR access on the Preferences\->Team\->CVS\->ExtConnection pane\&. Set CVS_SERVER to \fIgit\-cvsserver\fR\&. Not that password support is not good when using \fIext\fR, you will definitely want to have SSH keys setup\&.
+Protocol notes: If you are using anonymous access via pserver, just select that\&. Those using SSH access should choose the \fIext\fR protocol, and configure \fIext\fR access on the Preferences\->Team\->CVS\->ExtConnection pane\&. Set CVS_SERVER to \fIgit\-cvsserver\fR\&. Not that password support is not good when using \fIext\fR, you will definitely want to have SSH keys setup\&.
Alternatively, you can just use the non\-standard extssh protocol that Eclipse offer\&. In that case CVS_SERVER is ignored, and you will have to replace the cvs utility on the server with git\-cvsserver or manipulate your \&.bashrc so that calling \fIcvs\fR effectively calls git\-cvsserver\&.
A really simple TCP git daemon that normally listens on port "DEFAULT_GIT_PORT" aka 9418\&. It waits for a connection, and will just execute "git\-upload\-pack" 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\&.
+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\&.
It verifies that the directory has the magic file "git\-daemon\-export\-ok", and it will refuse to export any git directory that hasn't explicitly been marked for export this way (unless the \fI\-\-export\-all\fR parameter is specified)\&. If you pass some directory paths as \fIgit\-daemon\fR 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\&.
.SH "OPTIONS"
.fi
-ie 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\&.
+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\&.
.RS
.Sh "Note"
.TP
<path>...
-If provided, the results are limited to a subset of files matching one of these prefix strings\&. i
e file matches /^<pattern1>|<pattern2>|.../ Note that this parameter does not provide any wildcard or regexp features\&.
+If provided, the results are limited to a subset of files matching one of these prefix strings\&. i
\&.e\&., file matches /^<pattern1>|<pattern2>|.../ Note that this parameter does not provide any wildcard or regexp features\&.
.TP
\-r
\-\-stdin
When \fI\-\-stdin\fR is specified, the command does not take <tree\-ish> arguments from the command line\&. Instead, it reads either one <commit> or a pair of <tree\-ish> separated with a single space from its standard input\&.
-When a single commit is given on one line of such input, it compares the commit with its parents\&. The following flags further affects its behaviour\&. This does not apply to the case where two <tree\-ish> separated with a single space are given\&.
+When a single commit is given on one line of such input, it compares the commit with its parents\&. The following flags further affects its behavior\&. This does not apply to the case where two <tree\-ish> separated with a single space are given\&.
.TP
\-m
.sp
\fB1. \fRshow only modification, rename and copy, but not addition nor deletion\&.
.br
-\fB2. \fRshow 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 you would only see the directory name if there is a change in a file in a subdirectory\&.
+\fB2. \fRshow only names and the nature of change, but not actual diff output\&. \-\-name\-status disables usual patch generation 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\&.
.br
\fB3. \fRlimit diff output to named subtrees\&.
.br
.SH "SYNOPSIS"
.nf
-\fIgit\-format\-patch\fR [\-n | \-k] [\-o <dir> | \-\-stdout] [\-\-attach] [\-s] [\-c]
- [\-\-diff\-options] <his> [<mine>]
+\fIgit\-format\-patch\fR [\-n | \-k] [\-o <dir> | \-\-stdout] [\-\-attach]
+ [\-s | \-\-signoff] [\-\-diff\-options] [\-\-start\-number <n>]
+ <since>[\&.\&.<until>]
.fi
.SH "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 \fBgit\-am\fR(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\&.
-Each output file is numbered sequentially from 1, and uses the first line of the commit message (massaged for pathname safety) as the filename\&.
+The output of this command is convenient for e\-mail submission or for use with \fBgit\-am\fR(1)\&.
-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\&.
+Each output file is numbered sequentially from 1, and uses the 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 \-n is specified, instead of "[PATCH] Subject", the first line is formatted as "[PATCH N/M] Subject", unless you have only one patch\&.
+If \-o is specified, output files are created in <dir>\&. Otherwise they are created in the current working directory\&.
+
+
+If \-n is specified, instead of "[PATCH] Subject", the first line is formatted as "[PATCH n/m] Subject"\&.
.SH "OPTIONS"
.TP
\-o|\-\-output\-directory <dir>
-Use <dir> to store the resulting files, instead of the current working directory\&.
+Use <dir> to store the resulting files, instead of the current working directory\&. This option is ignored if \-\-stdout is specified\&.
.TP
\-n|\-\-numbered
Name output in \fI[PATCH n/m]\fR format\&.
+.TP
+\-\-start\-number <n>
+Start numbering the patches at <n> instead of 1\&.
+
.TP
\-k|\-\-keep\-subject
Do not strip/add \fI[PATCH]\fR from the first line of the commit log message\&.
\-s|\-\-signoff
Add Signed\-off\-by: line to the commit message, using the committer identity of yourself\&.
-.TP
-\-c|\-\-check
-Display suspicious lines in the patch\&. The definition of \fIsuspicious lines\fR is currently the lines that has trailing whitespaces, and the lines whose indentation has a SP character immediately followed by a TAB character\&.
-
.TP
\-\-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\&.
.TP
\-\-attach
.TP
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\&.
.TP
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\&.
.SH "SEE ALSO"
will do quite a _lot_ of verification on the tree\&. There are a few extra validity tests to be added (make sure that tree objects are sorted properly etc), but on the whole if "git\-fsck\-objects" is happy, you 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 the hopes that somebody else has the object you have corrupted)\&.
+Any corrupt objects you will have to find in backups or other archives (i\&.e\&., you can just remove them and do an "rsync" with some other site in the hopes that somebody else has the object you have corrupted)\&.
Of course, "valid tree" doesn't mean that it wasn't generated by some evil person, and the end result might be crap\&. git is a revision tracking system, not a quality assurance system ;)
.TP
\-\-cached
-Instead of searching in the working tree files, check the blobs registerd in the index file\&.
+Instead of searching in the working tree files, check the blobs registered in the index file\&.
.TP
\-a | \-\-text
.TP
\-[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 matches\&.
+Show context trailing (A -- after), or leading (B -- before), or both (C -- context) lines, and place a line containing \-\- between contiguous groups of matches\&.
.TP
\-f <file>
.fi
-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 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)\&.
+where the latter example shows how "git\-merge\-index" will stop trying to merge once anything has returned an error (i\&.e\&., "cat" returned an error for the AA file, because it didn't exist in the original, and thus "git\-merge\-index" didn't even try to merge the MM thing)\&.
.SH "AUTHOR"
.SH "DESCRIPTION"
-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 ID" are almost guaranteed to be the same thing\&.
+A "patch ID" is nothing but a SHA1 of the diff associated with a patch, with whitespace and line numbers ignored\&. As such, it's "reasonably stable", but at the same time also reasonably unique, i\&.e\&., two patches that have the same "patch ID" are almost guaranteed to be the same thing\&.
IOW, you can use this thing to look for likely duplicate commits\&.
This means that you can do
-.IP
+.nf
$ git\-read\-tree \-m <tree1> <tree2> <tree3>
+.fi
+
and you will end up with an index with all of the <tree1> entries in "stage1", all of the <tree2> entries in "stage2" and all of the <tree3> entries in "stage3"\&. When performing a merge of another branch into the current branch, we use the common ancestor tree as <tree1>, the current branch head as <tree2>, and the other branch head as <tree3>\&.
The git\-write\-tree command refuses to write a nonsensical tree, and it will complain about unmerged entries if it sees a single entry that is not stage 0\&.
-Ok, this all sounds like a collection of totally nonsensical rules, but it's actually exactly what you want in order to do a fast merge\&. The different stages represent the "result tree" (stage 0, aka "merged"), the original tree (stage 1, aka "orig"), and the two trees you are trying to merge (stage 2 and 3 respectively)\&.
+OK, this all sounds like a collection of totally nonsensical rules, but it's actually exactly what you want in order to do a fast merge\&. The different stages represent the "result tree" (stage 0, aka "merged"), the original tree (stage 1, aka "orig"), and the two trees you are trying to merge (stage 2 and 3 respectively)\&.
The order of stages 1, 2 and 3 (hence the order of three <tree\-ish> command line arguments) are significant when you start a 3\-way merge with an index file that is already populated\&. Here is an outline of how the algorithm works:
a file that has _any_ difference what\-so\-ever in the three trees will stay as separate entries in the index\&. It's up to "porcelain policy" to determine how to remove the non\-0 stages, and insert a merged version\&.
.TP
\(bu
-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 now the merge algorithm ends up being really simple:
+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 (i\&.e\&., "unmerged entries") you can't write the result\&. So now the merge algorithm ends up being really simple:
.RS
.TP 3
This is done to prevent you from losing your work\-in\-progress changes, and mixing your random changes in an unrelated merge commit\&. To illustrate, suppose you start from what has been commited last to your repository:
-.IP
+.nf
$ JC=`git\-rev\-parse \-\-verify "HEAD^0"`
$ git\-checkout\-index \-f \-u \-a $JC
+.fi
+
You do random edits, without running git\-update\-index\&. And then you notice that the tip of your "upstream" tree has advanced since you pulled from him:
-.IP
+.nf
$ git\-fetch git://\&.\&.\&.\&. linus
$ LT=`cat \&.git/FETCH_HEAD`
+.fi
+
Your work tree is still based on your HEAD ($JC), but you have some edits since\&. Three\-way merge makes sure that you have not added or modified index entries since $JC, and if you haven't, then does the right thing\&. So with the following sequence:
-.IP
+.nf
$ git\-read\-tree \-m \-u `git\-merge\-base $JC $LT` $JC $LT
$ git\-merge\-index git\-merge\-one\-file \-a
$ echo "Merge with Linus" | \\
git\-commit\-tree `git\-write\-tree` \-p $JC \-p $LT
+.fi
+
what you would commit is a pure merge between $JC and $LT without your work\-in\-progress changes, and your work tree would be updated to the result of the merge\&.
.TP
\-\-replace\-all
-Default behaviour is to replace at most one line\&. This replaces all lines matching the key (and optionally the value_regex)\&.
+Default behavior is to replace at most one line\&. This replaces all lines matching the key (and optionally the value_regex)\&.
.TP
\-\-get
.SH "CONFIGURATION FILE"
-The git configuration file contains a number of variables that affect the git commands behaviour\&. 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 dot\&. The variable names are case\-insensitive and only alphanumeric characters are allowed\&. Some variables may appear multiple times\&.
+The git configuration file contains a number of variables that affect 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 dot\&. The variable names are case\-insensitive and only alphanumeric characters are allowed\&. Some variables may appear multiple times\&.
The syntax is fairly flexible and permissive; whitespaces are mostly ignored\&. The \fI#\fR and \fI;\fR characters begin commends to the end of line, blank lines are ignored, lines containing strings enclosed in square brackets start sections and all the other lines are recognized as setting variables, in the form \fIname = value\fR\&. If there is no equal sign on the line, the entire line is taken as \fIname\fR and the variable is recognized as boolean "true"\&. String values may be entirely or partially enclosed in double quotes; some variables may require special value format\&.
A "proxy command" to execute (as \fIcommand host port\fR) instead of establishing direct connection to the remote server when using the git protocol for fetching\&. If the variable value is in the "COMMAND for DOMAIN" format, the command is applied only on hostnames ending with the specified domain string\&. This variable may be set multiple times and is matched in the given order; the first match wins\&.
.nf
-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)\&.
.fi
core\&.preferSymlinkRefs
Instead of the default "symref" format for HEAD and other symbolic reference files, use symbolic links\&. This is sometimes needed to work with old scripts that expect HEAD to be a symbolic link\&.
+.TP
+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)\&.
+
.TP
core\&.repositoryFormatVersion
Internal variable identifying the repository format and layout version\&.
.TP
http\&.sslKey
-File containing the SSL private key when fetching or pushing over HTTPS\&. Can be overriden by the \fIGIT_SSL_KEY\fR environment variable\&.
+File containing the SSL private key when fetching or pushing over HTTPS\&. Can be overridden by the \fIGIT_SSL_KEY\fR environment variable\&.
.TP
http\&.sslCAInfo
-File containing the certificates to verify the peer with when fetching or pushing over HTTPS\&. Can be overriden by the \fIGIT_SSL_CAINFO\fR environment variable\&.
+File containing the certificates to verify the peer with when fetching or pushing over HTTPS\&. Can be overridden by the \fIGIT_SSL_CAINFO\fR environment variable\&.
.TP
http\&.sslCAPath
.TP
http\&.maxRequests
-How many HTTP requests to launch in parallel\&. Can be overriden by the \fIGIT_HTTP_MAX_REQUESTS\fR environment variable\&. Default is 5\&.
+How many HTTP requests to launch in parallel\&. Can be overridden by the \fIGIT_HTTP_MAX_REQUESTS\fR environment variable\&. Default is 5\&.
.TP
http\&.lowSpeedLimit, http\&.lowSpeedTime
-If the HTTP transfer speed is less than \fIhttp\&.lowSpeedLimit\fR for longer than \fIhttp\&.lowSpeedTime\fR seconds, the transfer is aborted\&. Can be overriden by the \fIGIT_HTTP_LOW_SPEED_LIMIT\fR and \fIGIT_HTTP_LOW_SPEED_TIME\fR environment variables\&.
+If the HTTP transfer speed is less than \fIhttp\&.lowSpeedLimit\fR for longer than \fIhttp\&.lowSpeedTime\fR seconds, the transfer is aborted\&. Can be overridden by the \fIGIT_HTTP_LOW_SPEED_LIMIT\fR and \fIGIT_HTTP_LOW_SPEED_TIME\fR environment variables\&.
.TP
i18n\&.commitEncoding
.TP
user\&.email
-Your email address to be recorded in any newly created commits\&. Can be overriden by the \fIGIT_AUTHOR_EMAIL\fR and \fIGIT_COMMITTER_EMAIL\fR environment variables\&. See \fBgit\-commit\-tree\fR(1)\&.
+Your email address to be recorded in any newly created commits\&. Can be overridden by the \fIGIT_AUTHOR_EMAIL\fR and \fIGIT_COMMITTER_EMAIL\fR environment variables\&. See \fBgit\-commit\-tree\fR(1)\&.
.TP
user\&.name
-Your full name to be recorded in any newly created commits\&. Can be overriden by the \fIGIT_AUTHOR_NAME\fR and \fIGIT_COMMITTER_NAME\fR environment variables\&. See \fBgit\-commit\-tree\fR(1)\&.
+Your full name to be recorded in any newly created commits\&. Can be overridden by the \fIGIT_AUTHOR_NAME\fR and \fIGIT_COMMITTER_NAME\fR environment variables\&. See \fBgit\-commit\-tree\fR(1)\&.
.TP
whatchanged\&.difftree
.TP
\-\-mixed
-Resets the index but not the working tree (ie, the changed files are preserved but not marked for commit) and reports what has not been updated\&. This is the default action\&.
+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\&.
.TP
\-\-soft
.SH "DESCRIPTION"
-Many git Porcelainish commands take mixture of flags (i\&.e\&. parameters that begin with a dash \fI\-\fR) and parameters meant for underlying git\-rev\-list command they use internally and flags and parameters for other commands they use as the downstream of git\-rev\-list\&. This command is used to distinguish between them\&.
+Many git porcelainish commands take mixture of flags (i\&.e\&. parameters that begin with a dash \fI\-\fR) and parameters meant for underlying git\-rev\-list command they use internally and flags and parameters for other commands they use as the downstream of git\-rev\-list\&. This command is used to distinguish between them\&.
.SH "OPTIONS"
.TP
\-\-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 7 is used\&. The minimum length is 4\&.
+Instead of outputting the full SHA1 values of object names try to abbreviate them to a shorter unique name\&. When no length is specified 7 is used\&. The minimum length is 4\&.
.TP
\-\-since=datestring, \-\-after=datestring
A symbolic ref name\&. E\&.g\&. \fImaster\fR typically means the commit object referenced by $GIT_DIR/refs/heads/master\&. If you happen to have both heads/master and tags/master, you can explicitly say \fIheads/master\fR to tell git which one you mean\&.
.TP
\(bu
+A suffix \fI@\fR followed by a date specification enclosed in a brace pair (e\&.g\&. \fI{yesterday}\fR, \fI{1 month 2 weeks 3 days 1 hour 1 second ago}\fR or \fI{1979\-02\-26 18:30:00}\fR) 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>)\&.
+.TP
+\(bu
A suffix \fI^\fR to a revision parameter means the first parent of that commit object\&. \fI^<n>\fR means the <n>th parent (i\&.e\&. \fIrev^\fR is equivalent to \fIrev^1\fR)\&. As a special rule, \fIrev^0\fR means the commit itself and is used when \fIrev\fR is the object name of a tag object that refers to a commit object\&.
.TP
\(bu
.TP
\-\-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\&.
.TP
\-\-quiet
There are three ways to specify which refs to update on the remote end\&.
-With \fI\-\-all\fR flag, all refs that exist locally are transfered to the remote side\&. You cannot specify any \fI<ref>\fR if you use this flag\&.
+With \fI\-\-all\fR flag, all refs that exist locally are transferred to the remote side\&. You cannot specify any \fI<ref>\fR if you use this flag\&.
Without \fI\-\-all\fR and without any \fI<ref>\fR, the refs that exist both on the local side and on the remote side are updated\&.
.SH "DESCRIPTION"
-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\&. So, to make the rest of the git scripts more careful and readable, use it as follows:
+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\&. So, to make the rest of the git scripts more careful and readable, use it as follows:
.nf
\&. git\-sh\-setup || die "Not a git archive"
.TP
\-\-remove
-If a specified file is in the index but is missing then it's removed\&. Default behaviour is to ignore removed file\&.
+If a specified file is in the index but is missing then it's removed\&. Default behavior is to ignore removed file\&.
.TP
\-\-refresh
.SH "SYNOPSIS"
-\fIgit\-update\-ref\fR <ref> <newvalue> [<oldvalue>]
+\fIgit\-update\-ref\fR
[\-m <reason>] <ref> <newvalue> [<oldvalue>]
.SH "DESCRIPTION"
both from a symlink following standpoint \fIand\fR an error checking standpoint\&. The "refs/" rule for symlinks means that symlinks that point to "outside" the tree are safe: they'll be followed for reading but not for writing (so we'll never write through a ref symlink to some other tree, if you have copied a whole archive by creating a symlink tree)\&.
+.SH "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:
+
+.TP 3
+1.
+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\&.
+.LP
+
+
+Optionally with \-m:
+
+.TP 3
+1.
+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\&.
+.LP
+
+
+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\&.
+
.SH "AUTHOR"
projects / git.git / commitdiff