.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
.\" Instead of manually editing it, you probably should edit the DocBook XML
.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
-.TH "GIT\-COMMIT" "1" "07/19/2007" "Git 1.5.3.rc1.4.gaf83" "Git Manual"
+.TH "GIT\-COMMIT" "1" "07/20/2007" "Git 1.5.3.rc2.22.g69a9b" "Git Manual"
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
It is a rough equivalent for:
.sp
.nf
+.ft C
$ git reset \-\-soft HEAD^
$ ... do something else to come up with the right tree ...
$ git commit \-c ORIG_HEAD
+.ft
+
.fi
but can be used to amend a merge commit.
.TP
When recording your own work, the contents of modified files in your working tree are temporarily stored to a staging area called the "index" with \fBgit\-add\fR(1). Removal of a file is staged with \fBgit\-rm\fR(1). After building the state to be committed incrementally with these commands, git commit (without any pathname parameter) is used to record what has been staged so far. This is the most basic form of the command. An example:
.sp
.nf
+.ft C
$ edit hello.c
$ git rm goodbye.c
$ git add hello.c
$ git commit
+.ft
+
.fi
Instead of staging files after each individual change, you can tell git commit to notice the changes to the files whose contents are tracked in your working tree and do corresponding git add and git rm for you. That is, this example does the same as the earlier example if there is no other change in your working tree:
.sp
.nf
+.ft C
$ edit hello.c
$ rm goodbye.c
$ git commit \-a
+.ft
+
.fi
The command git commit \-a first looks at your working tree, notices that you have modified hello.c and removed goodbye.c, and performs necessary git add and git rm for you.
After staging changes to many files, you can alter the order the changes are recorded in, by giving pathnames to git commit. When pathnames are given, the command makes a commit that only records the changes made to the named paths:
.sp
.nf
+.ft C
$ edit hello.c hello.h
$ git add hello.c hello.h
$ edit Makefile
$ git commit Makefile
+.ft
+
.fi
This makes a commit that records the modification to Makefile. The changes staged for hello.c and hello.h are not included in the resulting commit. However, their changes are not lost \(em they are still staged and merely held back. After the above sequence, if you do:
.sp
.nf
+.ft C
$ git commit
+.ft
+
.fi
this second commit would record the changes to hello.c and hello.h as expected.
After a merge (initiated by either \fBgit\-merge\fR(1) or \fBgit\-pull\fR(1)) stops because of conflicts, cleanly merged paths are already staged to be committed for you, and paths that conflicted are left in unmerged state. You would have to first check which paths are conflicting with \fBgit\-status\fR(1) and after fixing them manually in your working tree, you would stage the result as usual with \fBgit\-add\fR(1):
.sp
.nf
+.ft C
$ git status | grep unmerged
unmerged: hello.c
$ edit hello.c
$ git add hello.c
+.ft
+
.fi
After resolving conflicts and staging the result, git ls\-files \-u would stop mentioning the conflicted path. When you are done, run git commit to finally record the merge:
.sp
.nf
+.ft C
$ git commit
+.ft
+
.fi
As with the case to record your own changes, you can use \-a option to save typing. One difference is that during a merge resolution, you cannot use git commit with pathnames to alter the order the changes are committed, because the merge should be recorded as a single commit. In fact, the command refuses to run when given pathnames (but see \-i option).
.SH "DISCUSSION"
git\-commit\-tree (hence, git\-commit which uses it) issues an warning if the commit log message given to it does not look like a valid UTF\-8 string, unless you explicitly say your project uses a legacy encoding. The way to say this is to have i18n.commitencoding in .git/config file, like this:
.sp
.nf
+.ft C
[i18n]
commitencoding = ISO\-8859\-1
+.ft
+
.fi
Commit objects created with the above setting record the value of i18n.commitencoding in its encoding header. This is to help other people who look at them later. Lack of this header implies that the commit log message is encoded in UTF\-8.
.TP
git\-log, git\-show and friends looks at the encoding header of a commit object, and tries to re\-code the log message into UTF\-8 unless otherwise specified. You can specify the desired output encoding with i18n.logoutputencoding in .git/config file, like this:
.sp
.nf
+.ft C
[i18n]
logoutputencoding = ISO\-8859\-1
+.ft
+
.fi
If you do not have this configuration variable, the value of i18n.commitencoding is used instead.
Note that we deliberately chose not to re\-code the commit log message when a commit is made to force UTF\-8 at the commit object level, because re\-coding to UTF\-8 is not necessarily a reversible operation.
-.SH "ENVIRONMENT VARIABLES"
-The command specified by either the VISUAL or EDITOR environment variables is used to edit the commit log message.
+.SH "ENVIRONMENT AND CONFIGURATION VARIABLES"
+The editor used to edit the commit log message will be chosen from the GIT_EDITOR environment variable, the core.editor configuration variable, the VISUAL environment variable, or the EDITOR environment variable (in that order).
.SH "HOOKS"
This command can run commit\-msg, pre\-commit, and post\-commit hooks. See [1]\&\fIhooks\fR for more information.
.SH "SEE ALSO"
.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
.\" Instead of manually editing it, you probably should edit the DocBook XML
.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
-.TH "GIT\-CONFIG" "1" "07/19/2007" "Git 1.5.3.rc1.4.gaf83" "Git Manual"
+.TH "GIT\-CONFIG" "1" "07/20/2007" "Git 1.5.3.rc2.22.g69a9b" "Git Manual"
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
you can set the filemode to true with
.sp
.nf
+.ft C
% git config core.filemode true
+.ft
+
.fi
The hypothetical proxy command entries actually have a postfix to discern what URL they apply to. Here is how to change the entry for kernel.org to "ssh".
.sp
.nf
+.ft C
% git config core.gitproxy '"ssh" for kernel.org' 'for kernel.org$'
+.ft
+
.fi
This makes sure that only the key/value pair for kernel.org is replaced.
To delete the entry for renames, do
.sp
.nf
+.ft C
% git config \-\-unset diff.renames
+.ft
+
.fi
If you want to delete an entry for a multivar (like core.gitproxy above), you have to provide a regex matching the value of exactly one line.
To query the value for a given key, do
.sp
.nf
+.ft C
% git config \-\-get core.filemode
+.ft
+
.fi
or
.sp
.nf
+.ft C
% git config core.filemode
+.ft
+
.fi
or, to query a multivar:
.sp
.nf
+.ft C
% git config \-\-get core.gitproxy "for kernel.org$"
+.ft
+
.fi
If you want to know all the values for a multivar, do:
.sp
.nf
+.ft C
% git config \-\-get\-all core.gitproxy
+.ft
+
.fi
If you like to live dangerous, you can replace \fBall\fR core.gitproxy by a new one with
.sp
.nf
+.ft C
% git config \-\-replace\-all core.gitproxy ssh
+.ft
+
.fi
However, if you really only want to replace the line for the default proxy, i.e. the one without a "for \&..." postfix, do something like this:
.sp
.nf
+.ft C
% git config core.gitproxy ssh '! for '
+.ft
+
.fi
To actually match only values with an exclamation mark, you have to
.sp
.nf
+.ft C
% git config section.key value '[!]'
+.ft
+
.fi
To add a new proxy, without altering any of the existing ones, use
.sp
.nf
+.ft C
% git config core.gitproxy '"proxy" for example.com'
+.ft
+
.fi
.SH "CONFIGURATION FILE"
The git configuration file contains a number of variables that affect the git command's behavior. .git/config file for each repository is used to store the information for that repository, and $HOME/.gitconfig is used to store per user information to give fallback values for .git/config file. The file /etc/gitconfig can be used to store system\-wide defaults.
Sections can be further divided into subsections. To begin a subsection put its name in double quotes, separated by space from the section name, in the section header, like in example below:
.sp
.nf
+.ft C
[section "subsection"]
+.ft
+
.fi
Subsection names can contain any characters except newline (doublequote \fI"\fR and backslash have to be escaped as \fI\\"\fR and \fI\\\\\fR, respectively) and are case sensitive. Section header cannot span multiple lines. Variables may belong directly to a section or to a given subsection. You can have [section] if you have [section "subsection"], but you don't need to.
core.excludesfile
In addition to \fI.gitignore\fR (per\-directory) and \fI.git/info/exclude\fR, git looks into this file for patterns of files which are not meant to be tracked. See \fBgitignore\fR(5).
.TP
+core.editor
+Commands such as commit and tag that lets you edit messages by lauching 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, EDITOR and VISUAL environment variables and then finally vi.
+.TP
core.pager
The command that git will use to paginate output. Can be overridden with the GIT_PAGER environment variable.
.TP
.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
.\" Instead of manually editing it, you probably should edit the DocBook XML
.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
-.TH "GIT\-SEND\-EMAIL" "1" "07/19/2007" "Git 1.5.3.rc2.19.gc4fba" "Git Manual"
+.TH "GIT\-SEND\-EMAIL" "1" "07/20/2007" "Git 1.5.3.rc2.22.g69a9b" "Git Manual"
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
If this is set, each email will be sent as a reply to the previous email sent. If disabled with "\-\-no\-chain\-reply\-to", all emails after the first will be sent as replies to the first email sent. When using this, it is recommended that the first file given be an overview of the entire patch series. Default is the value of the \fIsendemail.chainreplyto\fR configuration value; if that is unspecified, default to \-\-chain\-reply\-to.
.TP
\-\-compose
-Use $EDITOR to edit an introductory message for the patch series.
+Use $GIT_EDITOR, core.editor, $VISUAL, or $EDITOR to edit an introductory message for the patch series.
.TP
\-\-from
Specify the sender of the emails. This will default to the value GIT_COMMITTER_IDENT, as returned by "git\-var \-l". The user will still be prompted to confirm this entry.
.\" It was generated using the DocBook XSL Stylesheets (version 1.69.1).
.\" Instead of manually editing it, you probably should edit the DocBook XML
.\" source for it and then use the DocBook XSL Stylesheets to regenerate it.
-.TH "GIT" "7" "07/19/2007" "Git 1.5.3.rc1.4.gaf83" "Git Manual"
+.TH "GIT" "7" "07/20/2007" "Git 1.5.3.rc2.22.g69a9b" "Git Manual"
.\" disable hyphenation
.nh
.\" disable justification (adjust text to left margin only)
Starting from 0.99.9 (actually mid 0.99.8.GIT), .git/config file is used to hold per\-repository configuration options. It is a simple text file modeled after .ini format familiar to some people. Here is an example:
.sp
.nf
+.ft C
#
# A '#' or ';' character indicates a comment.
#
[user]
name = "Junio C Hamano"
email = "junkio@twinsun.com"
+.ft
+
.fi
Various commands read from the configuration file and adjust their operation accordingly.
.SH "IDENTIFIER TERMINOLOGY"
A number controlling the amount of output shown by the recursive merge strategy. Overrides merge.verbosity. See \fBgit\-merge\fR(1)
.TP
\fIGIT_PAGER\fR
-This environment variable overrides $PAGER.
+This environment variable overrides $PAGER. If it is set to an empty string or to the value "cat", git will not launch a pager.
.TP
\fIGIT_FLUSH\fR
If this environment variable is set to "1", then commands such as git\-blame (in incremental mode), git\-rev\-list, git\-log, git\-whatchanged, etc., will force a flush of the output stream after each commit\-oriented record have been flushed. If this variable is set to "0", the output of these commands will be done using completely buffered I/O. If this environment variable is not set, git will choose buffered or record\-oriented flushing based on whether stdout appears to be redirected to a file or not.
Here is an ASCII art by Jon Loeliger that illustrates how various pieces fit together.
.sp
.nf
+.ft C
+
commit\-tree
commit obj
+\-\-\-\-+
| Working |
| Directory |
+\-\-\-\-\-\-\-\-\-\-\-+
+.ft
+
.fi
.SS "6) Examining the data"
You can examine the data represented in the object database and the index with various helper tools. For every object, you can use \fBgit\-cat\-file\fR(1) to examine details about the object:
You can examine such index state with git\-ls\-files \-\-unmerged command. An example:
.sp
.nf
+.ft C
$ git\-read\-tree \-m $orig HEAD $target
$ git\-ls\-files \-\-unmerged
100644 263414f423d0e4d70dae8fe53fa34614ff3e2860 1 hello.c
100644 06fa6a24256dc7e560efa5687fa84b51f0263c3a 2 hello.c
100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello.c
+.ft
+
.fi
Each line of the git\-ls\-files \-\-unmerged output begins with the blob mode bits, blob SHA1, \fIstage number\fR, and the filename. The \fIstage number\fR is git's way to say which tree it came from: stage 1 corresponds to $orig tree, stage 2 HEAD tree, and stage3 $target tree.
Earlier we said that trivial merges are done inside git\-read\-tree \-m. For example, if the file did not change from $orig to HEAD nor $target, or if the file changed from $orig to HEAD and $orig to $target the same way, obviously the final outcome is what is in HEAD. What the above example shows is that file hello.c was changed from $orig to HEAD and $orig to $target in a different way. You could resolve this by running your favorite 3\-way merge program, e.g. diff3 or merge, on the blob objects from these three stages yourself, like this:
.sp
.nf
+.ft C
$ git\-cat\-file blob 263414f... >hello.c~1
$ git\-cat\-file blob 06fa6a2... >hello.c~2
$ git\-cat\-file blob cc44c73... >hello.c~3
$ merge hello.c~2 hello.c~1 hello.c~3
+.ft
+
.fi
This would leave the merge result in hello.c~2 file, along with conflict markers if there are conflicts. After verifying the merge result makes sense, you can tell git what the final merge result for this file is by:
.sp
projects / git.git / commitdiff