.SH "SYNOPSIS"
-git\-applymbox [\-u] [\-k] [\-q] [\-m] ( \-c \&.dotest/<num> | <mbox> ) [ <signoff> ]
+\fIgit\-applymbox\fR [\-u] [\-k] [\-q] [\-m] ( \-c \&.dotest/<num> | <mbox> ) [ <signoff> ]
.SH "DESCRIPTION"
.TP
\-k
-Usually the program cleans up the Subject: header line to extract the title line for the commit log message, among which (1) remove Re: or re:, (2) leading whitespaces, (3) [ up to ], typically [PATCH], and then prepends "[PATCH] "\&. This flag forbids this munging, and is most useful when used to read back git format\-patch \-\-mbox output\&.
+Usually the program \fIcleans up\fR the Subject: header line to extract the title line for the commit log message, among which (1) remove \fIRe:\fR or \fIre:\fR, (2) leading whitespaces, (3) \fI[\fR up to \fI]\fR, typically \fI[PATCH]\fR, and then prepends "[PATCH] "\&. This flag forbids this munging, and is most useful when used to read back \fIgit format\-patch \-\-mbox\fR output\&.
.TP
\-m
.TP
\-c \&.dotest/<num>
-When the patch contained in an e\-mail does not cleanly apply, the command exits with an error message\&. The patch and extracted message are found in \&.dotest/, and you could re\-run git applymbox with \-c \&.dotest/<num> flag to restart the process after inspecting and fixing them\&.
+When the patch contained in an e\-mail does not cleanly apply, the command exits with an error message\&. The patch and extracted message are found in \&.dotest/, and you could re\-run \fIgit applymbox\fR with \fI\-c \&.dotest/<num>\fR flag to restart the process after inspecting and fixing them\&.
.TP
<mbox>
-The name of the file that contains the e\-mail messages with patches\&. This file should be in the UNIX mailbox format\&. See SubmittingPatches document to learn about the formatting convention for e\-mail submission\&.
+The name of the file that contains the e\-mail messages with patches\&. This file should be in the UNIX mailbox format\&. See \fISubmittingPatches\fR document to learn about the formatting convention for e\-mail submission\&.
.TP
<signoff>
-The name of the file that contains your "Signed\-off\-by" line\&. See SubmittingPatches document to learn what "Signed\-off\-by" line means\&. You can also just say yes, true, me, or please to use an automatically generated "Signed\-off\-by" line based on your committer identity\&.
+The name of the file that contains your "Signed\-off\-by" line\&. See \fISubmittingPatches\fR document to learn what "Signed\-off\-by" line means\&. You can also just say \fIyes\fR, \fItrue\fR, \fIme\fR, or \fIplease\fR to use an automatically generated "Signed\-off\-by" line based on your committer identity\&.
.SH "SEE ALSO"
.SH "SYNOPSIS"
-git bisect <subcommand> <options>
+\fIgit bisect\fR <subcommand> <options>
.SH "DESCRIPTION"
.fi
-This command uses git\-rev\-list \-\-bisect option to help drive the binary search process to find which change introduced a bug, given an old "good" commit object name and a later "bad" commit object name\&.
+This command uses \fIgit\-rev\-list \-\-bisect\fR option to help drive the binary search process to find which change introduced a bug, given an old "good" commit object name and a later "bad" commit object name\&.
The way you use it is:
-.IP
+.nf
$ git bisect start
$ git bisect bad # Current version is bad
$ git bisect good v2\&.6\&.13\-rc2 # v2\&.6\&.13\-rc2 was the last version
# tested that was good
+.fi
+
When you give at least one bad and one good versions, it will bisect the revision tree and say something like:
-.IP
+.nf
Bisecting: 675 revisions left to test after this
+.fi
+
and check out the state in the middle\&. Now, compile that kernel, and boot it\&. Now, let's say that this booted kernel works fine, then just do
-.IP
+.nf
$ git bisect good # this one is good
+.fi
+
which will now say
-.IP
+.nf
Bisecting: 337 revisions left to test after this
+.fi
+
and you continue along, compiling that one, testing it, and depending on whether it is good or bad, you say "git bisect good" or "git bisect bad", and ask for the next bisection\&.
Oh, and then after you want to reset to the original head, do a
-.IP
+.nf
$ git bisect reset
+.fi
+
to get back to the master branch, instead of being in one of the bisection branches ("git bisect start" will do that for you too, actually: it will reset the bisection state, and before it does that it checks that you're not using some old bisection branch)\&.
During the bisection process, you can say
-.IP
+.nf
$ git bisect visualize
+.fi
+
to see the currently remaining suspects in gitk\&.
The good/bad input is logged, and git bisect log shows what you have done so far\&. You can truncate its output somewhere and save it in a file, and run
-.IP
+.nf
$ git bisect replay that\-file
+.fi
+
if you find later you made a mistake telling good/bad about a revision\&.
If in a middle of bisect session, you know what the bisect suggested to try next is not a good one to test (e\&.g\&. the change the commit introduces is known not to work in your environment and you know it does not have anything to do with the bug you are chasing), you may want to find a near\-by commit and try that instead\&. It goes something like this:
-.IP
+.nf
$ git bisect good/bad # previous round was good/bad\&.
Bisecting: 337 revisions left to test after this
$ git bisect visualize # oops, that is uninteresting\&.
$ git reset \-\-hard HEAD~3 # try 3 revs before what
# was suggested
+.fi
+
Then compile and test the one you chose to try\&. After that, tell bisect what the result was as usual\&.
You can further cut down the number of trials if you know what part of the tree is involved in the problem you are tracking down, by giving paths parameters when you say bisect start, like this:
-.IP
+.nf
$ git bisect start arch/i386 include/asm\-i386
+.fi
+
.SH "AUTHOR"
.SH "SYNOPSIS"
-
git\-commit\-tree <tree> [\-p <parent commit>]* < changelog
+
\fIgit\-commit\-tree\fR <tree> [\-p <parent commit>]* < changelog
.SH "DESCRIPTION"
.TP
\-p <parent commit>
-Each \-p indicates the id of a parent commit object\&.
+Each \fI\-p\fR indicates the id of a parent commit object\&.
.SH "COMMIT INFORMATION"
.SH "SYNOPSIS"
-git\-convert\-objects
+\fIgit\-convert\-objects\fR
.SH "DESCRIPTION"
git://host\&.xz/~user/path/to/repo\&.git/
.TP
\(bu
-ssh://host\&.xz/path/to/repo\&.git/
+ssh://[user@]host\&.xz/path/to/repo\&.git/
.TP
\(bu
-ssh://host\&.xz/~user/path/to/repo\&.git/
+ssh://[user@]host\&.xz/~user/path/to/repo\&.git/
.TP
\(bu
-ssh://host\&.xz/~/path/to/repo\&.git
+ssh://[user@]host\&.xz/~/path/to/repo\&.git
.LP
-SSH Is the default transport protocol and also supports an scp\-like syntax\&. Both syntaxes support username expansion, as does the native git protocol\&. The following three are identical to the last three above, respectively:
+SSH is the default transport protocol\&. You can optionally specify which user to log\-in as, and an alternate, scp\-like syntax is also supported\&. Both syntaxes support username expansion, as does the native git protocol\&. The following three are identical to the last three above, respectively:
.IP
.TP 3
\(bu
-host\&.xz:/path/to/repo\&.git/
+[user@]host\&.xz:/path/to/repo\&.git/
.TP
\(bu
-host\&.xz:~user/path/to/repo\&.git/
+[user@]host\&.xz:~user/path/to/repo\&.git/
.TP
\(bu
-host\&.xz:path/to/repo\&.git
+[user@]host\&.xz:path/to/repo\&.git
.LP
.SH "SYNOPSIS"
-git\-fmt\-merge\-msg <$GIT_DIR/FETCH_HEAD
+\fIgit\-fmt\-merge\-msg\fR <$GIT_DIR/FETCH_HEAD
.SH "DESCRIPTION"
-Takes the list of merged objects on stdin and produces a suitable commit message to be used for the merge commit, usually to be passed as the <merge\-message> argument of git\-merge\&.
+Takes the list of merged objects on stdin and produces a suitable commit message to be used for the merge commit, usually to be passed as the \fI<merge\-message>\fR argument of git\-merge\&.
This script is intended mostly for internal use by scripts automatically invoking git\-merge\&.
.SH "SYNOPSIS"
-git\-http\-fetch [\-c] [\-t] [\-a] [\-d] [\-v] [\-w filename] [\-\-recover] <commit> <url>
+\fIgit\-http\-fetch\fR [\-c] [\-t] [\-a] [\-d] [\-v] [\-w filename] [\-\-recover] <commit> <url>
.SH "DESCRIPTION"
.SH "SYNOPSIS"
-
git\-index\-pack [\-o <index\-file>] <pack\-file>
+
\fIgit\-index\-pack\fR [\-o <index\-file>] <pack\-file>
.SH "DESCRIPTION"
.SH "SYNOPSIS"
-git\-local\-fetch [\-c] [\-t] [\-a] [\-d] [\-v] [\-w filename] [\-\-recover] [\-l] [\-s] [\-n] commit\-id path
+\fIgit\-local\-fetch\fR [\-c] [\-t] [\-a] [\-d] [\-v] [\-w filename] [\-\-recover] [\-l] [\-s] [\-n] commit\-id path
.SH "DESCRIPTION"
An example:
.nf
- $ cat \&.git/ignore
+ $ cat \&.git/info/exclude
# ignore objects and archives, anywhere in the tree\&.
*\&.[oa]
$ cat Documentation/\&.gitignore
!foo\&.html
$ git\-ls\-files \-\-ignored \\
\-\-exclude='Documentation/*\&.[0\-9]' \\
- \-\-exclude\-from=\&.git/ignore \\
+ \-\-exclude\-from=\&.git/info/exclude \\
\-\-exclude\-per\-directory=\&.gitignore
.fi
.SH "SYNOPSIS"
-git\-merge\-one\-file
+\fIgit\-merge\-one\-file\fR
.SH "DESCRIPTION"
.SH "SYNOPSIS"
-git\-mktag < signature_file
+\fIgit\-mktag\fR < signature_file
.SH "DESCRIPTION"
.fi
-followed by some optional free\-form signature that git itself doesn't care about, but that can be verified with gpg or similar\&.
+followed by some \fIoptional\fR free\-form signature that git itself doesn't care about, but that can be verified with gpg or similar\&.
The size of the full object is artificially limited to 8kB\&. (Just because I'm a lazy bastard, and if you can't fit a signature in that size, you're doing something wrong)
.SH "EXAMPLE"
-Given a commit, find out where it is relative to the local refs\&. Say somebody wrote you about that phantastic commit 33db5f4d9027a10e477ccf054b2c1ab94f74c85a\&. Of course, you look into the commit, but that only tells you what happened, but not the context\&.
+Given a commit, find out where it is relative to the local refs\&. Say somebody wrote you about that fantastic commit 33db5f4d9027a10e477ccf054b2c1ab94f74c85a\&. Of course, you look into the commit, but that only tells you what happened, but not the context\&.
Enter git\-name\-rev:
.SH "SYNOPSIS"
-\&. git\-parse\-remote
+\fI\&. git\-parse\-remote\fR
.SH "DESCRIPTION"
git://host\&.xz/~user/path/to/repo\&.git/
.TP
\(bu
-ssh://host\&.xz/path/to/repo\&.git/
+ssh://[user@]host\&.xz/path/to/repo\&.git/
.TP
\(bu
-ssh://host\&.xz/~user/path/to/repo\&.git/
+ssh://[user@]host\&.xz/~user/path/to/repo\&.git/
.TP
\(bu
-ssh://host\&.xz/~/path/to/repo\&.git
+ssh://[user@]host\&.xz/~/path/to/repo\&.git
.LP
-SSH Is the default transport protocol and also supports an scp\-like syntax\&. Both syntaxes support username expansion, as does the native git protocol\&. The following three are identical to the last three above, respectively:
+SSH is the default transport protocol\&. You can optionally specify which user to log\-in as, and an alternate, scp\-like syntax is also supported\&. Both syntaxes support username expansion, as does the native git protocol\&. The following three are identical to the last three above, respectively:
.IP
.TP 3
\(bu
-host\&.xz:/path/to/repo\&.git/
+[user@]host\&.xz:/path/to/repo\&.git/
.TP
\(bu
-host\&.xz:~user/path/to/repo\&.git/
+[user@]host\&.xz:~user/path/to/repo\&.git/
.TP
\(bu
-host\&.xz:path/to/repo\&.git
+[user@]host\&.xz:path/to/repo\&.git
.LP
git://host\&.xz/~user/path/to/repo\&.git/
.TP
\(bu
-ssh://host\&.xz/path/to/repo\&.git/
+ssh://[user@]host\&.xz/path/to/repo\&.git/
.TP
\(bu
-ssh://host\&.xz/~user/path/to/repo\&.git/
+ssh://[user@]host\&.xz/~user/path/to/repo\&.git/
.TP
\(bu
-ssh://host\&.xz/~/path/to/repo\&.git
+ssh://[user@]host\&.xz/~/path/to/repo\&.git
.LP
-SSH Is the default transport protocol and also supports an scp\-like syntax\&. Both syntaxes support username expansion, as does the native git protocol\&. The following three are identical to the last three above, respectively:
+SSH is the default transport protocol\&. You can optionally specify which user to log\-in as, and an alternate, scp\-like syntax is also supported\&. Both syntaxes support username expansion, as does the native git protocol\&. The following three are identical to the last three above, respectively:
.IP
.TP 3
\(bu
-host\&.xz:/path/to/repo\&.git/
+[user@]host\&.xz:/path/to/repo\&.git/
.TP
\(bu
-host\&.xz:~user/path/to/repo\&.git/
+[user@]host\&.xz:~user/path/to/repo\&.git/
.TP
\(bu
-host\&.xz:path/to/repo\&.git
+[user@]host\&.xz:path/to/repo\&.git
.LP
When your topic branch modifies overlapping area that your master branch (or upstream) touched since your topic branch forked from it, you may want to test it with the latest master, even before your topic branch is ready to be pushed upstream:
-.IP
+.nf
o\-\-\-*\-\-\-o topic
/
o\-\-\-o\-\-\-o\-\-\-*\-\-\-o\-\-\-o master
+.fi
+
For such a test, you need to merge master and topic somehow\&. One way to do it is to pull master into the topic branch:
-.IP
+.nf
$ git checkout topic
$ git pull \&. master
o\-\-\-*\-\-\-o\-\-\-+ topic
/ /
o\-\-\-o\-\-\-o\-\-\-*\-\-\-o\-\-\-o master
+.fi
+
The commits marked with * touch the same area in the same file; you need to resolve the conflicts when creating the commit marked with +\&. Then you can test the result to make sure your work\-in\-progress still works with what is in the latest master\&.
After this test merge, there are two ways to continue your work on the topic\&. The easiest is to build on top of the test merge commit +, and when your work in the topic branch is finally ready, pull the topic branch into master, and/or ask the upstream to pull from you\&. By that time, however, the master or the upstream might have been advanced since the test merge +, in which case the final commit graph would look like this:
-.IP
+.nf
$ git checkout topic
$ git pull \&. master
$ \&.\&.\&. work on both topic and master branches
o\-\-\-*\-\-\-o\-\-\-+\-\-\-o\-\-\-o topic
/ / \\
o\-\-\-o\-\-\-o\-\-\-*\-\-\-o\-\-\-o\-\-\-o\-\-\-o\-\-\-+ master
+.fi
+
When your topic branch is long\-lived, however, your topic branch would end up having many such "Merge from master" commits on it, which would unnecessarily clutter the development history\&. Readers of the Linux kernel mailing list may remember that Linus complained about such too frequent test merges when a subsystem maintainer asked to pull from a branch full of "useless merges"\&.
As an alternative, to keep the topic branch clean of test merges, you could blow away the test merge, and keep building on top of the tip before the test merge:
-.IP
+.nf
$ git checkout topic
$ git pull \&. master
$ git reset \-\-hard HEAD^ ;# rewind the test merge
o\-\-\-*\-\-\-o\-\-\-\-\-\-\-o\-\-\-o topic
/ \\
o\-\-\-o\-\-\-o\-\-\-*\-\-\-o\-\-\-o\-\-\-o\-\-\-o\-\-\-+ master
+.fi
+
This would leave only one merge commit when your topic branch is finally ready and merged into the master branch\&. This merge would require you to resolve the conflict, introduced by the commits marked with *\&. However, often this conflict is the same conflict you resolved when you created the test merge you blew away\&. git\-rerere command helps you to resolve this final conflicted merge using the information from your earlier hand resolve\&.
The information git\-rerere records is also used when running git\-rebase\&. After blowing away the test merge and continuing development on the topic branch:
-.IP
+.nf
o\-\-\-*\-\-\-o\-\-\-\-\-\-\-o\-\-\-o topic
/
o\-\-\-o\-\-\-o\-\-\-*\-\-\-o\-\-\-o\-\-\-o\-\-\-o master
o\-\-\-*\-\-\-o\-\-\-\-\-\-\-o\-\-\-o topic
/
o\-\-\-o\-\-\-o\-\-\-*\-\-\-o\-\-\-o\-\-\-o\-\-\-o master
+.fi
+
you could run git rebase master topic, to keep yourself up\-to\-date even before your topic is ready to be sent upstream\&. This would result in falling back to three\-way merge, and it would conflict the same way the test merge you resolved earlier\&. git\-rerere is run by git rebase to help you resolve this conflict\&.
.SH "SYNOPSIS"
-git\-resolve <current> <merged> <message>
+\fIgit\-resolve\fR <current> <merged> <message>
.SH "DESCRIPTION"
\-\-header
Print the contents of the commit in raw\-format; each record is separated with a NUL character\&.
+.TP
+\-\-parents
+Print the parents of the commit\&.
+
.TP
\-\-objects
Print the object IDs of any object referenced by the listed commits\&. \fIgit\-rev\-list \-\-objects foo ^bar\fR thus means "send me all object IDs which I need to download if I have the commit object \fIbar\fR, but not \fIfoo\fR"\&.
\-\-remove\-empty
Stop when a given path disappears from the tree\&.
+.TP
+\-\-no\-merges
+Do not print commits with more than one parent\&.
+
.TP
\-\-not
Reverses the meaning of the \fI^\fR prefix (or lack thereof) for all following revision specifiers, up to the next \-\-not\&.
.SH "SYNOPSIS"
-git\-show\-index < idx\-file
+\fIgit\-show\-index\fR < idx\-file
.SH "DESCRIPTION"
Reads given idx file for packed git archive created with git\-pack\-objects command, and dumps its contents\&.
-The information it outputs is subset of what you can get from git\-verify\-pack \-v; this command only shows the packfile offset and SHA1 of each object\&.
+The information it outputs is subset of what you can get from \fIgit\-verify\-pack \-v\fR; this command only shows the packfile offset and SHA1 of each object\&.
.SH "AUTHOR"
.SH "SYNOPSIS"
-git\-ssh\-fetch [\-c] [\-t] [\-a] [\-d] [\-v] [\-w filename] [\-\-recover] commit\-id url
+\fIgit\-ssh\-fetch\fR [\-c] [\-t] [\-a] [\-d] [\-v] [\-w filename] [\-\-recover] commit\-id url
.SH "DESCRIPTION"
.SH "SYNOPSIS"
-git\-ssh\-upload [\-c] [\-t] [\-a] [\-d] [\-v] [\-w filename] [\-\-recover] commit\-id url
+\fIgit\-ssh\-upload\fR [\-c] [\-t] [\-a] [\-d] [\-v] [\-w filename] [\-\-recover] commit\-id url
.SH "DESCRIPTION"
.SH "SYNOPSIS"
-git\-symbolic\-ref <name> [<ref>]
+\fIgit\-symbolic\-ref\fR <name> [<ref>]
.SH "DESCRIPTION"
Traditionally, \&.git/HEAD is a symlink pointing at refs/heads/master\&. When we want to switch to another branch, we did ln \-sf refs/heads/newbranch \&.git/HEAD, and when we want to find out which branch we are on, we did readlink \&.git/HEAD\&. This was fine, and internally that is what still happens by default, but on platforms that do not have working symlinks, or that do not have the readlink(1) command, this was a bit cumbersome\&. On some platforms, ln \-sf does not even work as advertised (horrors)\&.
-A symbolic ref can be a regular file that stores a string that begins with ref: refs/\&. For example, your \&.git/HEAD can be a regular file whose contents is ref: refs/heads/master\&. This can be used on a filesystem that does not support symbolic links\&. Instead of doing readlink \&.git/HEAD, git\-symbolic\-ref HEAD can be used to find out which branch we are on\&. To point the HEAD to newbranch, instead of ln \-sf refs/heads/newbranch \&.git/HEAD, git\-symbolic\-ref HEAD refs/heads/newbranch can be used\&.
+A symbolic ref can be a regular file that stores a string that begins with ref: refs/\&. For example, your \&.git/HEAD \fIcan\fR be a regular file whose contents is ref: refs/heads/master\&. This can be used on a filesystem that does not support symbolic links\&. Instead of doing readlink \&.git/HEAD, git\-symbolic\-ref HEAD can be used to find out which branch we are on\&. To point the HEAD to newbranch, instead of ln \-sf refs/heads/newbranch \&.git/HEAD, git\-symbolic\-ref HEAD refs/heads/newbranch can be used\&.
Currently, \&.git/HEAD uses a regular file symbolic ref on Cygwin, and everywhere else it is implemented as a symlink\&. This can be changed at compilation time\&.
.SH "SYNOPSIS"
-git\-unpack\-file <blob>
+\fIgit\-unpack\-file\fR <blob>
.SH "DESCRIPTION"
.SH "SYNOPSIS"
-git\-update\-server\-info [\-\-force]
+\fIgit\-update\-server\-info\fR [\-\-force]
.SH "DESCRIPTION"
\fIGIT_DIFF_OPTS\fR, \fIGIT_EXTERNAL_DIFF\fR
see the "generating patches" section in : \fBgit\-diff\-index\fR(1); \fBgit\-diff\-files\fR(1); \fBgit\-diff\-tree\fR(1)
+.SS "other"
+
+.TP
+\fIGIT_TRACE\fR
+If this variable is set git will print trace: messages on stderr telling about alias expansion, built\-in command execution and external command execution\&.
+
.SH "DISCUSSION"
projects / git.git / commitdiff