a string, an integer, or a boolean. Boolean values may be given as yes/no,
0/1, true/false or on/off. Case is not significant in boolean values, when
converting value to the canonical form using '--bool' type specifier;
- 'git-config' will ensure that the output is "true" or "false".
+ 'git config' will ensure that the output is "true" or "false".
String values may be entirely or partially enclosed in double quotes.
You need to enclose variable values in double quotes if you want to
Advice shown when linkgit:git-merge[1] refuses to
merge to avoid overwritting local changes.
Default: true.
+ resolveConflict::
+ Advices shown by various commands when conflicts
+ prevent the operation from being performed.
+ Default: true.
+ implicitIdentity::
+ Advice on how to set your identity configuration when
+ your information is guessed from the system username and
+ domain name. Default: true.
--
core.fileMode::
core.whitespace::
A comma separated list of common whitespace problems to
- notice. 'git-diff' will use `color.diff.whitespace` to
- highlight them, and 'git-apply --whitespace=error' will
+ notice. 'git diff' will use `color.diff.whitespace` to
+ highlight them, and 'git apply --whitespace=error' will
consider them as errors. You can prefix `-` to disable
any of them (e.g. `-trailing-space`):
+
This setting defaults to "refs/notes/commits", and can be overridden by
the `GIT_NOTES_REF` environment variable.
+core.sparseCheckout::
+ Enable "sparse checkout" feature. See section "Sparse checkout" in
+ linkgit:git-read-tree[1] for more information.
+
add.ignore-errors::
- Tells 'git-add' to continue adding files when some files cannot be
+ Tells 'git add' to continue adding files when some files cannot be
added due to indexing errors. Equivalent to the '--ignore-errors'
option of linkgit:git-add[1].
not necessarily be the current directory.
apply.ignorewhitespace::
- When set to 'change', tells 'git-apply' to ignore changes in
+ When set to 'change', tells 'git apply' to ignore changes in
whitespace, in the same way as the '--ignore-space-change'
option.
- When set to one of: no, none, never, false tells 'git-apply' to
+ When set to one of: no, none, never, false tells 'git apply' to
respect all whitespace differences.
See linkgit:git-apply[1].
apply.whitespace::
- Tells 'git-apply' how to handle whitespaces, in the same way
+ Tells 'git apply' how to handle whitespaces, in the same way
as the '--whitespace' option. See linkgit:git-apply[1].
branch.autosetupmerge::
- Tells 'git-branch' and 'git-checkout' to set up new branches
- Tells 'git branch' and 'git checkout' to setup new branches
++ Tells 'git branch' and 'git checkout' to set up new branches
so that linkgit:git-pull[1] will appropriately merge from the
starting point branch. Note that even if this option is not set,
this behavior can be chosen per-branch using the `--track`
branch. This option defaults to true.
branch.autosetuprebase::
- When a new branch is created with 'git-branch' or 'git-checkout'
+ When a new branch is created with 'git branch' or 'git checkout'
that tracks another branch, this variable tells git to set
up pull to rebase instead of merge (see "branch.<name>.rebase").
When `never`, rebase is never automatically set to true.
This option defaults to never.
branch.<name>.remote::
- When in branch <name>, it tells 'git-fetch' and 'git-push' which
+ When in branch <name>, it tells 'git fetch' and 'git push' which
remote to fetch from/push to. It defaults to `origin` if no remote is
configured. `origin` is also used if you are not on any branch.
branch.<name>.merge::
Defines, together with branch.<name>.remote, the upstream branch
- for the given branch. It tells 'git-fetch'/'git-pull' which
- branch to merge and can also affect 'git-push' (see push.default).
- When in branch <name>, it tells 'git-fetch' the default
+ for the given branch. It tells 'git fetch'/'git pull' which
+ branch to merge and can also affect 'git push' (see push.default).
+ When in branch <name>, it tells 'git fetch' the default
refspec to be marked for merging in FETCH_HEAD. The value is
handled like the remote part of a refspec, and must match a
ref which is fetched from the remote given by
"branch.<name>.remote".
- The merge information is used by 'git-pull' (which at first calls
- 'git-fetch') to lookup the default branch for merging. Without
- this option, 'git-pull' defaults to merge the first refspec fetched.
+ The merge information is used by 'git pull' (which at first calls
+ 'git fetch') to lookup the default branch for merging. Without
+ this option, 'git pull' defaults to merge the first refspec fetched.
Specify multiple values to get an octopus merge.
- If you wish to setup 'git-pull' so that it merges into <name> from
+ If you wish to setup 'git pull' so that it merges into <name> from
another branch in the local repository, you can point
branch.<name>.merge to the desired branch, and use the special setting
`.` (a period) for branch.<name>.remote.
`never`), never. When set to `true` or `auto`, use color only
when the output is written to the terminal. Defaults to `false`.
-color.grep.external::
- The string value of this variable is passed to an external 'grep'
- command as a command line option if match highlighting is turned
- on. If set to an empty string, no option is passed at all,
- turning off coloring for external 'grep' calls; this is the default.
- For GNU grep, set it to `--color=always` to highlight matches even
- when a pager is used.
-
color.grep.match::
Use customized color for matches. The value of this variable
may be specified as in color.branch.<slot>. It is passed using
colors only when the output is to the terminal. Defaults to false.
color.interactive.<slot>::
- Use customized color for 'git-add --interactive'
+ Use customized color for 'git add --interactive'
output. `<slot>` may be `prompt`, `header`, `help` or `error`, for
four distinct types of normal output from interactive
commands. The values of these variables may be specified as
terminal. When more specific variables of color.* are set, they always
take precedence over this setting. Defaults to false.
+commit.status
+ A boolean to enable/disable inclusion of status information in the
+ commit message template when using an editor to prepare the commit
+ message. Defaults to true.
+
commit.template::
Specify a file to use as the template for new commit messages.
"{tilde}/" is expanded to the value of `$HOME` and "{tilde}user/" to the
specified user's home directory.
diff.autorefreshindex::
- When using 'git-diff' to compare with work tree
+ When using 'git diff' to compare with work tree
files, do not consider stat-only change as changed.
Instead, silently run `git update-index --refresh` to
update the cached stat information for paths whose
contents in the work tree match the contents in the
index. This option defaults to true. Note that this
- affects only 'git-diff' Porcelain, and not lower level
- 'diff' commands such as 'git-diff-files'.
+ affects only 'git diff' Porcelain, and not lower level
- 'diff' commands, such as 'git diff-files'.
++ 'diff' commands such as 'git diff-files'.
diff.external::
If this config variable is set, diff generation is not
your files, you might want to use linkgit:gitattributes[5] instead.
diff.mnemonicprefix::
- If set, 'git-diff' uses a prefix pair that is different from the
+ If set, 'git diff' uses a prefix pair that is different from the
standard "a/" and "b/" depending on what is being compared. When
this configuration is in effect, reverse diff output also swaps
the order of the prefixes:
- 'git-diff';;
+ `git diff`;;
compares the (i)ndex and the (w)ork tree;
- 'git-diff HEAD';;
+ `git diff HEAD`;;
compares a (c)ommit and the (w)ork tree;
- 'git diff --cached';;
+ `git diff --cached`;;
compares a (c)ommit and the (i)ndex;
- 'git-diff HEAD:file1 file2';;
+ `git diff HEAD:file1 file2`;;
compares an (o)bject and a (w)ork tree entity;
- 'git diff --no-index a b';;
+ `git diff --no-index a b`;;
compares two non-git things (1) and (2).
diff.renameLimit::
The number of files to consider when performing the copy/rename
- detection; equivalent to the 'git-diff' option '-l'.
+ detection; equivalent to the 'git diff' option '-l'.
diff.renames::
Tells git to detect renames. If set to any boolean value, it
linkgit:git-whatchanged[1].
format.thread::
- The default threading style for 'git-format-patch'. Can be
+ The default threading style for 'git format-patch'. Can be
- either a boolean value, `shallow` or `deep`. `shallow`
- threading makes every mail a reply to the head of the series,
+ a boolean value, or `shallow` or `deep`. `shallow` threading
+ makes every mail a reply to the head of the series,
where the head is chosen from the cover letter, the
`\--in-reply-to`, and the first patch mail, in this order.
`deep` threading makes every mail a reply to the previous one.
gc.aggressiveWindow::
The window size parameter used in the delta compression
- algorithm used by 'git-gc --aggressive'. This defaults
+ algorithm used by 'git gc --aggressive'. This defaults
to 10.
gc.auto::
default value is 50. Setting this to 0 disables it.
gc.packrefs::
- 'git gc' does not run `git pack-refs` in a bare repository by
- default so that older dumb-transport clients can still fetch
- from the repository. Setting this to `true` lets 'git gc'
- to run `git pack-refs`. Setting this to `false` tells
- 'git gc' never to run `git pack-refs`. The default setting is
- `notbare`. Enable it only when you know you do not have to
- support such clients. The default setting will change to `true`
- at some stage, and setting this to `false` will continue to
- prevent `git pack-refs` from being run from 'git gc'.
+ Running `git pack-refs` in a repository renders it
+ unclonable by Git versions prior to 1.5.1.2 over dumb
+ transports such as HTTP. This variable determines whether
- 'git gc' runs `git pack-refs`. This can be set to "nobare"
++ 'git gc' runs `git pack-refs`. This can be set to `nobare`
+ to enable it within all non-bare repos or it can be set to a
+ boolean value. The default is `true`.
gc.pruneexpire::
- When 'git-gc' is run, it will call 'prune --expire 2.weeks.ago'.
+ When 'git gc' is run, it will call 'prune --expire 2.weeks.ago'.
Override the grace period with this config variable. The value
"now" may be used to disable this grace period and always prune
unreachable objects immediately.
gc.reflogexpire::
- 'git-reflog expire' removes reflog entries older than
+ 'git reflog expire' removes reflog entries older than
this time; defaults to 90 days.
gc.reflogexpireunreachable::
- 'git-reflog expire' removes reflog entries older than
+ 'git reflog expire' removes reflog entries older than
this time and are not reachable from the current tip;
defaults to 30 days.
gc.rerereresolved::
Records of conflicted merge you resolved earlier are
- kept for this many days when 'git-rerere gc' is run.
+ kept for this many days when 'git rerere gc' is run.
The default is 60 days. See linkgit:git-rerere[1].
gc.rerereunresolved::
Records of conflicted merge you have not resolved are
- kept for this many days when 'git-rerere gc' is run.
+ kept for this many days when 'git rerere gc' is run.
The default is 15 days. See linkgit:git-rerere[1].
gitcvs.commitmsgannotation::
off.
gui.fastcopyblame::
- If true, 'git gui blame' uses '-C' instead of '-C -C' for original
+ If true, 'git gui blame' uses `-C` instead of `-C -C` for original
location detection. It makes blame significantly faster on huge
repositories at the expense of less thorough copy detection.
How many HTTP requests to launch in parallel. Can be overridden
by the 'GIT_HTTP_MAX_REQUESTS' environment variable. Default is 5.
+http.minSessions::
+ The number of curl sessions (counted across slots) to be kept across
+ requests. They will not be ended with curl_easy_cleanup() until
+ http_cleanup() is invoked. If USE_CURL_MULTI is not defined, this
+ value will be capped at 1. Defaults to 1.
+
http.postBuffer::
Maximum size in bytes of the buffer used by smart HTTP
transports when POSTing data to the remote system.
i18n.logOutputEncoding::
Character encoding the commit messages are converted to when
- running 'git-log' and friends.
+ running 'git log' and friends.
imap::
The configuration variables in the 'imap' section are described
log.date::
Set default date-time mode for the log command. Setting log.date
- value is similar to using 'git-log'\'s --date option. The value is one of the
+ value is similar to using 'git log'\'s --date option. The value is one of the
following alternatives: {relative,local,default,iso,rfc,short}.
See linkgit:git-log[1].
--------
[verse]
'git blame' [-c] [-b] [-l] [--root] [-t] [-f] [-n] [-s] [-p] [-w] [--incremental] [-L n,m]
- [-S <revs-file>] [-M] [-C] [-C] [--since=<date>]
+ [-S <revs-file>] [-M] [-C] [-C] [-C] [--since=<date>]
[<rev> | --contents <file> | --reverse <rev>] [--] <file>
DESCRIPTION
The command can also limit the range of lines annotated.
The report does not tell you anything about lines which have been deleted or
- replaced; you need to use a tool such as 'git-diff' or the "pickaxe"
+ replaced; you need to use a tool such as 'git diff' or the "pickaxe"
interface briefly mentioned in the following paragraph.
Apart from supporting file annotation, git also supports searching the
file (see `-M`). The first number listed is the score.
This is the number of alphanumeric characters detected
as having been moved between or within files. This must be above
- a certain threshold for 'git-blame' to consider those lines
+ a certain threshold for 'git blame' to consider those lines
of code to have been moved.
-f::
SPECIFYING RANGES
-----------------
- Unlike 'git-blame' and 'git-annotate' in older versions of git, the extent
+ Unlike 'git blame' and 'git annotate' in older versions of git, the extent
of the annotation can be limited to both line ranges and revision
ranges. When you are interested in finding the origin for
lines 40-60 for file `foo`, you can use the `-L` option like so
When you are not interested in changes older than version
v2.6.18, or changes older than 3 weeks, you can use revision
- range specifiers similar to 'git-rev-list':
+ range specifiers similar to 'git rev-list':
git blame v2.6.18.. -- foo
git blame --since=3.weeks -- foo
'git commit' [-a | --interactive] [-s] [-v] [-u<mode>] [--amend] [--dry-run]
[(-c | -C) <commit>] [-F <file> | -m <msg>] [--reset-author]
[--allow-empty] [--no-verify] [-e] [--author=<author>]
- [--date=<date>] [--cleanup=<mode>] [--] [[-i | -o ]<file>...]
+ [--date=<date>] [--cleanup=<mode>] [--status | --no-status] [--]
+ [[-i | -o ]<file>...]
DESCRIPTION
-----------
The content to be added can be specified in several ways:
- 1. by using 'git-add' to incrementally "add" changes to the
+ 1. by using 'git add' to incrementally "add" changes to the
index before using the 'commit' command (Note: even modified
files must be "added");
- 2. by using 'git-rm' to remove files from the working tree
+ 2. by using 'git rm' to remove files from the working tree
and the index, again before using the 'commit' command;
3. by listing files as arguments to the 'commit' command, in which
5. by using the --interactive switch with the 'commit' command to decide one
by one which files should be part of the commit, before finalizing the
- operation. Currently, this is done by invoking 'git-add --interactive'.
+ operation. Currently, this is done by invoking 'git add --interactive'.
The `--dry-run` option can be used to obtain a
summary of what is included by any of the above for the next
commit by giving the same set of parameters (options and paths).
If you make a commit and then find a mistake immediately after
- that, you can recover from it with 'git-reset'.
+ that, you can recover from it with 'git reset'.
OPTIONS
Make a commit only from the paths specified on the
command line, disregarding any contents that have been
staged so far. This is the default mode of operation of
- 'git-commit' if any paths are given on the command line,
+ 'git commit' if any paths are given on the command line,
in which case this option can be omitted.
If this option is specified together with '--amend', then
no paths need to be specified, which can be used to amend
to be committed, paths with local changes that will be left
uncommitted and paths that are untracked.
+--status::
+ Include the output of linkgit:git-status[1] in the commit
+ message template when using an editor to prepare the commit
+ message. Defaults to on, but can be used to override
+ configuration variable commit.status.
+
+--no-status::
+ Do not include the output of linkgit:git-status[1] in the
+ commit message template when using an editor to prepare the
+ default commit message.
+
\--::
Do not interpret any more arguments as options.
--------
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 'git-add'. A file can be
+ called the "index" with 'git add'. A file can be
reverted back, only in the index but not in the working tree,
to that of the last commit with `git reset HEAD -- <file>`,
- which effectively reverts 'git-add' and prevents the changes to
+ which effectively reverts 'git add' and prevents the changes to
this file from participating in the next commit. After building
the state to be committed incrementally with these commands,
`git commit` (without any pathname parameter) is used to record what
this second commit would record the changes to `hello.c` and
`hello.h` as expected.
- After a merge (initiated by 'git-merge' or 'git-pull') stops
+ After a merge (initiated by 'git merge' or 'git pull') 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 'git-status'
+ check which paths are conflicting with 'git status'
and after fixing them manually in your working tree, you would
- stage the result as usual with 'git-add':
+ stage the result as usual with 'git add':
------------
$ git status | grep unmerged
you want to handle the lines that do *not* match the regex, just
prepend a single exclamation mark in front (see also <<EXAMPLES>>).
-The type specifier can be either '--int' or '--bool', which will make
+The type specifier can be either '--int' or '--bool', to make
- 'git-config' ensure that the variable(s) are of the given type and
+ 'git config' ensure that the variable(s) are of the given type and
convert the value to the canonical form (simple decimal number for int,
-a "true" or "false" string for bool). If no type specifier is passed,
-no checks or transformations are performed on the value.
+a "true" or "false" string for bool), or '--path', which does some
+path expansion (see '--path' below). If no type specifier is passed, no
+checks or transformations are performed on the value.
The file-option can be one of '--system', '--global' or '--file'
which specify where the values will be read from or written to.
List all variables set in config file.
--bool::
- 'git-config' will ensure that the output is "true" or "false"
+ 'git config' will ensure that the output is "true" or "false"
--int::
- 'git-config' will ensure that the output is a simple
+ 'git config' will ensure that the output is a simple
decimal number. An optional value suffix of 'k', 'm', or 'g'
in the config file will cause the value to be multiplied
by 1024, 1048576, or 1073741824 prior to output.
--bool-or-int::
- 'git-config' will ensure that the output matches the format of
+ 'git config' will ensure that the output matches the format of
either --bool or --int, as described above.
+--path::
+ 'git-config' will expand leading '{tilde}' to the value of
+ '$HOME', and '{tilde}user' to the home directory for the
+ specified user. This option has no effect when setting the
+ value (but you can use 'git config bla {tilde}/' from the
+ command line to let your shell do the expansion).
+
-z::
--null::
For all options that output values and/or keys, always
-----
If not set explicitly with '--file', there are three files where
- 'git-config' will search for configuration options:
+ 'git config' will search for configuration options:
$GIT_DIR/config::
Repository specific configuration file. (The filename is
If no further options are given, all reading options will read all of these
files that are available. If the global or the system-wide configuration
file are not available they will be ignored. If the repository configuration
- file is not available or readable, 'git-config' will exit with a non-zero
+ file is not available or readable, 'git config' will exit with a non-zero
error code. However, in neither case will an error message be issued.
All writing options will per default write to the repository specific
configuration file. Note that this also affects options like '--replace-all'
- and '--unset'. *'git-config' will only ever change one file at a time*.
+ and '--unset'. *'git config' will only ever change one file at a time*.
You can override these rules either by command line options or by environment
variables. The '--global' and the '--system' options will limit the file used
Usage:
[verse]
- 'git cvsserver' [options] [pserver|server] [<directory> ...]
+ 'git-cvsserver' [options] [pserver|server] [<directory> ...]
OPTIONS
-------
The database can not be reliably regenerated in a
consistent form after the branch it is tracking has changed.
Example: For merged branches, 'git-cvsserver' only tracks
- one branch of development, and after a 'git-merge' an
+ one branch of development, and after a 'git merge' an
incrementally updated database may track a different branch
than a database regenerated from scratch, causing inconsistent
CVS revision numbers. `git-cvsserver` has no way of knowing which
If no name can be determined, the
numeric uid is used.
+ENVIRONMENT
+-----------
+
+These variables obviate the need for command-line options in some
+circumstances, allowing easier restricted usage through git-shell.
+
+GIT_CVSSERVER_BASE_PATH takes the place of the argument to --base-path.
+
+GIT_CVSSERVER_ROOT specifies a single-directory whitelist. The
+repository must still be configured to allow access through
+git-cvsserver, as described above.
+
+When these environment variables are set, the corresponding
+command-line arguments may not be used.
+
Eclipse CVS Client Notes
------------------------
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'". Note that password support is not good when using 'ext',
+ "`git cvsserver`". Note that password support is not good when using 'ext',
you will definitely want to have SSH keys setup.
Alternatively, you can just use the non-standard extssh protocol that Eclipse
SYNOPSIS
--------
-'git difftool' [--tool=<tool>] [-y|--no-prompt|--prompt] [<'git diff' options>]
+'git difftool' [<options>] <commit>{0,2} [--] [<path>...]
DESCRIPTION
-----------
- 'git-difftool' is a git command that allows you to compare and edit files
+ 'git difftool' is a git command that allows you to compare and edit files
between revisions using common diff tools. 'git difftool' is a frontend
- to 'git-diff' and accepts the same options and arguments.
+ to 'git diff' and accepts the same options and arguments.
OPTIONS
-------
kdiff3, kompare, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff,
ecmerge, diffuse, opendiff, p4merge and araxis.
+
- If a diff tool is not specified, 'git-difftool'
+ If a diff tool is not specified, 'git difftool'
will use the configuration variable `diff.tool`. If the
- configuration variable `diff.tool` is not set, 'git-difftool'
+ configuration variable `diff.tool` is not set, 'git difftool'
will pick a suitable default.
+
You can explicitly provide a full path to the tool by setting the
configuration variable `difftool.<tool>.path`. For example, you
can configure the absolute path to kdiff3 by setting
- `difftool.kdiff3.path`. Otherwise, 'git-difftool' assumes the
+ `difftool.kdiff3.path`. Otherwise, 'git difftool' assumes the
tool is available in PATH.
+
Instead of running one of the known diff tools,
- 'git-difftool' can be customized to run an alternative program
+ 'git difftool' can be customized to run an alternative program
by specifying the command line to invoke in a configuration
variable `difftool.<tool>.cmd`.
+
- When 'git-difftool' is invoked with this tool (either through the
+ When 'git difftool' is invoked with this tool (either through the
`-t` or `--tool` option or the `diff.tool` configuration variable)
the configured command line will be invoked with the following
variables available: `$LOCAL` is set to the name of the temporary
of the diff post-image. `$BASE` is provided for compatibility
with custom merge tool commands and has the same value as `$LOCAL`.
+-x <command>::
+--extcmd=<command>::
+ Specify a custom command for viewing diffs.
+ 'git-difftool' ignores the configured defaults and runs
+ `$command $LOCAL $REMOTE` when this option is specified.
+
+-g::
+--gui::
+ When 'git-difftool' is invoked with the `-g` or `--gui` option
+ the default diff tool will be read from the configured
+ `diff.guitool` variable instead of `diff.tool`.
+
See linkgit:git-diff[1] for the full list of supported options.
CONFIG VARIABLES
----------------
- 'git-difftool' falls back to 'git-mergetool' config variables when the
+ 'git difftool' falls back to 'git mergetool' config variables when the
difftool equivalents have not been defined.
diff.tool::
The default diff tool to use.
+diff.guitool::
+ The default diff tool to use when `--gui` is specified.
+
difftool.<tool>.path::
Override the path for the given tool. This is useful in case
your tool is not in the PATH.
This program is usually not what the end user wants to run directly.
Most end users want to use one of the existing frontend programs,
which parses a specific type of foreign source and feeds the contents
- stored there to 'git-fast-import'.
+ stored there to 'git fast-import'.
fast-import reads a mixed command/data stream from standard input and
writes one or more packfiles directly into the current repository.
with the newly imported data.
The fast-import backend itself can import into an empty repository (one that
- has already been initialized by 'git-init') or incrementally
+ has already been initialized by 'git init') or incrementally
update an existing populated repository. Whether or not incremental
imports are supported from a particular foreign source depends on
the frontend program in use.
set of marks. If a mark is defined to different values,
the last file wins.
+--relative-marks::
+ After specifying --relative-marks= the paths specified
+ with --import-marks= and --export-marks= are relative
+ to an internal directory in the current repository.
+ In git-fast-import this means that the paths are relative
+ to the .git/info/fast-import directory. However, other
+ importers may use a different location.
+
+--no-relative-marks::
+ Negates a previous --relative-marks. Allows for combining
+ relative and non-relative marks by interweaving
+ --(no-)-relative-marks= with the --(import|export)-marks=
+ options.
+
--export-pack-edges=<file>::
After creating a packfile, print a line of data to
<file> listing the filename of the packfile and the last
This information may be useful after importing projects
whose total object set exceeds the 4 GiB packfile limit,
as these commits can be used as edge points during calls
- to 'git-pack-objects'.
+ to 'git pack-objects'.
--quiet::
Disable all non-fatal output, making fast-import silent when it
Parallel Operation
------------------
- Like 'git-push' or 'git-fetch', imports handled by fast-import are safe to
+ Like 'git push' or 'git fetch', imports handled by fast-import are safe to
run alongside parallel `git repack -a -d` or `git gc` invocations,
- or any other Git operation (including 'git-prune', as loose objects
+ or any other Git operation (including 'git prune', as loose objects
are never used by fast-import).
fast-import does not lock the branch or tag refs it is actively importing.
+
An example value is ``Tue Feb 6 11:22:18 2007 -0500''. The Git
parser is accurate, but a little on the lenient side. It is the
- same parser used by 'git-am' when applying patches
+ same parser used by 'git am' when applying patches
received from email.
+
Some malformed strings may be accepted as valid dates. In some of
This particular format is supplied as its short to implement and
may be useful to a process that wants to create a new commit
right now, without needing to use a working directory or
- 'git-update-index'.
+ 'git update-index'.
+
If separate `author` and `committer` commands are used in a `commit`
the timestamps may not match, as the system clock will be polled
standard output. This command is optional and is not needed
to perform an import.
+`feature`::
+ Require that fast-import supports the specified feature, or
+ abort if it does not.
+
+`option`::
+ Specify any of the options listed under OPTIONS that do not
+ change stream semantic to suit the frontend's needs. This
+ command is optional and is not needed to perform an import.
+
`commit`
~~~~~~~~
Create or update a branch with a new commit, recording one logical
complete set of bytes which normally goes into such a signature.
If signing is required, create lightweight tags from within fast-import with
`reset`, then create the annotated versions of those tags offline
- with the standard 'git-tag' process.
+ with the standard 'git tag' process.
`reset`
~~~~~~~
inform the reader when the `checkpoint` has been completed and it
can safely access the refs that fast-import updated.
+`feature`
+~~~~~~~~~
+Require that fast-import supports the specified feature, or abort if
+it does not.
+
+....
+ 'feature' SP <feature> LF
+....
+
+The <feature> part of the command may be any string matching
+^[a-zA-Z][a-zA-Z-]*$ and should be understood by fast-import.
+
+Feature work identical as their option counterparts with the
+exception of the import-marks feature, see below.
+
+The following features are currently supported:
+
+* date-format
+* import-marks
+* export-marks
+* relative-marks
+* no-relative-marks
+* force
+
+The import-marks behaves differently from when it is specified as
+commandline option in that only one "feature import-marks" is allowed
+per stream. Also, any --import-marks= specified on the commandline
+will override those from the stream (if any).
+
+`option`
+~~~~~~~~
+Processes the specified option so that git fast-import behaves in a
+way that suits the frontend's needs.
+Note that options specified by the frontend are overridden by any
+options the user may specify to git fast-import itself.
+
+....
+ 'option' SP <option> LF
+....
+
+The `<option>` part of the command may contain any of the options
+listed in the OPTIONS section that do not change import semantics,
+without the leading '--' and is treated in the same way.
+
+Option commands must be the first commands on the input (not counting
+feature commands), to give an option command after any non-option
+command is an error.
+
+The following commandline options change import semantics and may therefore
+not be passed as option:
+
+* date-format
+* import-marks
+* export-marks
+* force
+
Crash Reports
-------------
If fast-import is supplied invalid input it will terminate with a
When committing fixups, consider using `merge` to connect the
commit(s) which are supplying file revisions to the fixup branch.
- Doing so will allow tools such as 'git-blame' to track
+ Doing so will allow tools such as 'git blame' to track
through the real commit history and properly annotate the source
files.
~~~~~~~~~~~~~~~~~~~~~~~~~
If you are repacking very old imported data (e.g. older than the
last year), consider expending some extra CPU time and supplying
- \--window=50 (or higher) when you run 'git-repack'.
+ \--window=50 (or higher) when you run 'git repack'.
This will take longer, but will also produce a smaller packfile.
You only need to expend the effort once, and everyone using your
project will benefit from the smaller repository.
SYNOPSIS
--------
[verse]
- 'git-http-backend'
+ 'git http-backend'
DESCRIPTION
-----------
and the backwards-compatible dumb HTTP protocol, as well as clients
pushing using the smart HTTP protocol.
+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
+GIT_HTTP_EXPORT_ALL environmental variable is set).
+
By default, only the `upload-pack` service is enabled, which serves
- 'git-fetch-pack' and 'git-ls-remote' clients, which are invoked from
- 'git-fetch', 'git-pull', and 'git-clone'. If the client is authenticated,
- the `receive-pack` service is enabled, which serves 'git-send-pack'
- clients, which is invoked from 'git-push'.
+ 'git fetch-pack' and 'git ls-remote' clients, which are invoked from
+ 'git fetch', 'git pull', and 'git clone'. If the client is authenticated,
+ the `receive-pack` service is enabled, which serves 'git send-pack'
+ clients, which is invoked from 'git push'.
SERVICES
--------
by setting this configuration item to `false`.
http.uploadpack::
- This serves 'git-fetch-pack' and 'git-ls-remote' clients.
+ This serves 'git fetch-pack' and 'git ls-remote' clients.
It is enabled by default, but a repository can disable it
by setting this configuration item to `false`.
http.receivepack::
- This serves 'git-send-pack' clients, allowing push. It is
+ This serves 'git send-pack' clients, allowing push. It is
disabled by default for anonymous users, and enabled by
default for users authenticated by the web server. It can be
disabled by setting this item to `false`, or enabled for all
URL TRANSLATION
---------------
- To determine the location of the repository on disk, 'git-http-backend'
+ To determine the location of the repository on disk, 'git http-backend'
concatenates the environment variables PATH_INFO, which is set
automatically by the web server, and GIT_PROJECT_ROOT, which must be set
manually in the web server configuration. If GIT_PROJECT_ROOT is not
- set, 'git-http-backend' reads PATH_TRANSLATED, which is also set
+ set, 'git http-backend' reads PATH_TRANSLATED, which is also set
automatically by the web server.
EXAMPLES
+
----------------------------------------------------------------
SetEnv GIT_PROJECT_ROOT /var/www/git
+SetEnv GIT_HTTP_EXPORT_ALL
ScriptAlias /git/ /usr/libexec/git-core/git-http-backend/
----------------------------------------------------------------
+
----------------------------------------------------------------
+
To serve gitweb at the same url, use a ScriptAliasMatch to only
- those URLs that 'git-http-backend' can handle, and forward the
+ those URLs that 'git http-backend' can handle, and forward the
rest to gitweb:
+
----------------------------------------------------------------
ENVIRONMENT
-----------
- 'git-http-backend' relies upon the CGI environment variables set
+ 'git http-backend' relies upon the CGI environment variables set
by the invoking web server, including:
* PATH_INFO (if GIT_PROJECT_ROOT is set, otherwise PATH_TRANSLATED)
* QUERY_STRING
* REQUEST_METHOD
+The GIT_HTTP_EXPORT_ALL environmental variable may be passed to
+'git-http-backend' to bypass the check for the "git-daemon-export-ok"
+file in each repository before allowing export of that repository.
+
The backend process sets GIT_COMMITTER_NAME to '$REMOTE_USER' and
GIT_COMMITTER_EMAIL to '$\{REMOTE_USER}@http.$\{REMOTE_ADDR\}',
ensuring that any reflogs created by 'git-receive-pack' contain some
Identify the file status with the following tags (followed by
a space) at the start of each line:
H:: cached
+ S:: skip-worktree
M:: unmerged
R:: removed/deleted
C:: modified/changed
[<tag> ]<mode> <object> <stage> <file>
- 'git-ls-files --unmerged' and 'git-ls-files --stage' can be used to examine
+ 'git ls-files --unmerged' and 'git ls-files --stage' can be used to examine
detailed information on unmerged paths.
For an unmerged path, instead of recording a single mode/SHA1 pair,
Exclude Patterns
----------------
- 'git-ls-files' can use a list of "exclude patterns" when
+ 'git ls-files' can use a list of "exclude patterns" when
traversing the directory tree and finding files to show when the
flags --others or --ignored are specified. linkgit:gitignore[5]
specifies the format of exclude patterns.
in the same order they appear in the file.
3. command line flag --exclude-per-directory=<name> specifies
- a name of the file in each directory 'git-ls-files'
+ a name of the file in each directory 'git ls-files'
examines, normally `.gitignore`. Files in deeper
directories take precedence. Patterns are ordered in the
same order they appear in the files.
--------
[verse]
'git merge' [-n] [--stat] [--no-commit] [--squash] [-s <strategy>]...
- [--[no-]rerere-autoupdate] [-m <msg>] <remote>...
- 'git merge' <msg> HEAD <remote>...
- [-m <msg>] <commit>...
++ [--[no-]rerere-autoupdate] [-m <msg>] <commit>...
+ 'git merge' <msg> HEAD <commit>...
DESCRIPTION
-----------
- This is the top-level interface to the merge machinery
- which drives multiple merge strategy scripts.
+ Merges the history specified by <commit> into HEAD, optionally using a
+ specific merge strategy.
- The second syntax (<msg> `HEAD` <remote>) is supported for
+ The second syntax (<msg> `HEAD` <commit>...) is supported for
historical reasons. Do not use it from the command line or in
- new scripts. It is the same as `git merge -m <msg> <remote>`.
+ new scripts. It is the same as `git merge -m <msg> <commit>...`.
+
+ *Warning*: Running 'git merge' with uncommitted changes is
+ discouraged: while possible, it leaves you in a state that is hard to
+ back out of in the case of a conflict.
OPTIONS
used to give a good default for automated 'git merge'
invocations.
- <remote>...::
- Other branch heads to merge into our branch. You need at
- least one <remote>. Specifying more than one <remote>
- obviously means you are trying an Octopus.
+--rerere-autoupdate::
+--no-rerere-autoupdate::
+ Allow the rerere mechanism to update the index with the
+ result of auto-conflict resolution if possible.
+
+ <commit>...::
+ Commits, usually other branch heads, to merge into our branch.
+ You need at least one <commit>. Specifying more than one
+ <commit> obviously means you are trying an Octopus.
include::merge-strategies.txt[]
If you tried a merge which resulted in complex conflicts and
- want to start over, you can recover with 'git-reset'.
+ want to start over, you can recover with 'git reset'.
CONFIGURATION
-------------
will write out your local changes already registered in your
index file along with the merge result, which is not good.
Because 1. involves only those paths differing between your
- branch and the remote branch you are pulling from during the
- merge (which is typically a fraction of the whole tree), you can
+ branch and the branch you are merging
+ (which is typically a fraction of the whole tree), you can
have local modifications in your working tree as long as they do
not overlap with what the merge updates.
3. For conflicting paths, the index file records up to three
versions; stage1 stores the version from the common ancestor,
- stage2 from `HEAD`, and stage3 from the remote branch (you
+ stage2 from `HEAD`, and stage3 from the other branch (you
can inspect the stages with `git ls-files -u`). The working
tree files contain the result of the "merge" program; i.e. 3-way
merge results with familiar conflict markers `<<< === >>>`.
* Decide not to merge. The only clean-ups you need are to reset
the index file to the `HEAD` commit to reverse 2. and to clean
- up working tree changes made by 2. and 3.; 'git-reset --hard' can
+ up working tree changes made by 2. and 3.; `git-reset --hard` can
be used for this.
* Resolve the conflicts. Git will mark the conflicts in
the working tree. Edit the files into shape and
- 'git-add' them to the index. Use 'git-commit' to seal the deal.
+ 'git add' them to the index. Use 'git commit' to seal the deal.
You can work through the conflict with a number of tools:
- * Use a mergetool. 'git mergetool' to launch a graphical
+ * Use a mergetool. `git mergetool` to launch a graphical
mergetool which will work you through the merge.
- * Look at the diffs. 'git diff' will show a three-way diff,
- highlighting changes from both the HEAD and remote versions.
+ * Look at the diffs. `git diff` will show a three-way diff,
+ highlighting changes from both the HEAD and their versions.
- * Look at the diffs on their own. 'git log --merge -p <path>'
- will show diffs first for the HEAD version and then the
- remote version.
+ * Look at the diffs on their own. `git log --merge -p <path>`
+ will show diffs first for the HEAD version and then
+ their version.
- * Look at the originals. 'git show :1:filename' shows the
- common ancestor, 'git show :2:filename' shows the HEAD
- version and 'git show :3:filename' shows the remote version.
+ * Look at the originals. `git show :1:filename` shows the
+ common ancestor, `git show :2:filename` shows the HEAD
+ version and `git show :3:filename` shows their version.
EXAMPLES
--------
[verse]
'git push' [--all | --mirror | --tags] [-n | --dry-run] [--receive-pack=<git-receive-pack>]
- [--repo=<repository>] [-f | --force] [-v | --verbose]
+ [--repo=<repository>] [-f | --force] [-v | --verbose] [-u | --set-upstream]
[<repository> <refspec>...]
DESCRIPTION
will be tab-separated and sent to stdout instead of stderr. The full
symbolic names of the refs will be given.
+--delete::
+ All listed refs are deleted from the remote repository. This is
+ the same as prefixing all refs with a colon.
+
--tags::
All refs under `$GIT_DIR/refs/tags` are pushed, in
addition to refspecs explicitly listed on the command
--repo=<repository>::
This option is only relevant if no <repository> argument is
- passed in the invocation. In this case, 'git-push' derives the
+ passed in the invocation. In this case, 'git push' derives the
remote name from the current branch: If it tracks a remote
branch, then that remote repository is pushed to. Otherwise,
the name "origin" is used. For this latter case, this option
can be used to override the name "origin". In other words,
the difference between these two commands
+
+-u::
+--set-upstream::
+ For every branch that is up to date or successfully pushed, add
+ upstream (tracking) reference, used by argument-less
+ linkgit:git-pull[1] and other commands. For more information,
+ see 'branch.<name>.merge' in linkgit:git-config[1].
+
--------------------------
git push public #1
+
is that #1 always pushes to "public" whereas #2 pushes to "public"
only if the current branch does not track a remote branch. This is
- useful if you write an alias or script around 'git-push'.
+ useful if you write an alias or script around 'git push'.
--thin::
--no-thin::
- These options are passed to 'git-send-pack'. Thin
+ These options are passed to 'git send-pack'. Thin
transfer spends extra cycles to minimize the number of
objects to be sent and meant to be used on slower connection.
--------
'git read-tree' [[-m [--trivial] [--aggressive] | --reset | --prefix=<prefix>]
[-u [--exclude-per-directory=<gitignore>] | -i]]
- [--index-output=<file>]
+ [--index-output=<file>] [--no-sparse-checkout]
<tree-ish1> [<tree-ish2> [<tree-ish3>]]
flag. When used with `-m`, the `-u` flag causes it to also update
the files in the work tree with the result of the merge.
- Trivial merges are done by 'git-read-tree' itself. Only conflicting paths
- will be in unmerged state when 'git-read-tree' returns.
+ Trivial merges are done by 'git read-tree' itself. Only conflicting paths
+ will be in unmerged state when 'git read-tree' returns.
OPTIONS
-------
Show the progress of checking files out.
--trivial::
- Restrict three-way merge by 'git-read-tree' to happen
+ Restrict three-way merge by 'git read-tree' to happen
only if there is no file-level merging required, instead
of resolving merge for trivial cases and leaving
conflicting files unresolved in the index.
--aggressive::
- Usually a three-way merge by 'git-read-tree' resolves
+ Usually a three-way merge by 'git read-tree' resolves
the merge for really trivial cases and leaves other
cases unresolved in the index, so that Porcelains can
implement different merge policies. This flag makes the
directories the index file and index output file are
located in.
+--no-sparse-checkout::
+ Disable sparse checkout support even if `core.sparseCheckout`
+ is true.
+
<tree-ish#>::
The id of the tree object(s) to be read/merged.
Merging
-------
- If `-m` is specified, 'git-read-tree' can perform 3 kinds of
+ If `-m` is specified, 'git read-tree' can perform 3 kinds of
merge, a single tree merge if only 1 tree is given, a
fast-forward merge with 2 trees, or a 3-way merge if 3 trees are
provided.
Single Tree Merge
~~~~~~~~~~~~~~~~~
- If only 1 tree is specified, 'git-read-tree' operates as if the user did not
+ If only 1 tree is specified, 'git read-tree' operates as if the user did not
specify `-m`, except that if the original index has an entry for a
given pathname, and the contents of the path matches with the tree
being read, the stat info from the index is used. (In other words, the
index's stat()s take precedence over the merged tree's).
That means that if you do a `git read-tree -m <newtree>` followed by a
- `git checkout-index -f -u -a`, the 'git-checkout-index' only checks out
+ `git checkout-index -f -u -a`, the 'git checkout-index' only checks out
the stuff that really changed.
- This is used to avoid unnecessary false hits when 'git-diff-files' is
- run after 'git-read-tree'.
+ This is used to avoid unnecessary false hits when 'git diff-files' is
+ run after 'git read-tree'.
Two Tree Merge
of a foreign tree, which is simply ahead of $H (i.e. we are in a
fast-forward situation).
- When two trees are specified, the user is telling 'git-read-tree'
+ When two trees are specified, the user is telling 'git read-tree'
the following:
1. The current index and work tree is derived from $H, but
In all "keep index" cases, the index entry stays as in the
original index file. If the entry were not up to date,
- 'git-read-tree' keeps the copy in the work tree intact when
+ 'git read-tree' keeps the copy in the work tree intact when
operating under the -u flag.
- When this form of 'git-read-tree' returns successfully, you can
+ When this form of 'git read-tree' returns successfully, you can
see what "local changes" you made are carried forward by running
`git diff-index --cached $M`. Note that this does not
necessarily match `git diff-index --cached $H` would have
Each "index" entry has two bits worth of "stage" state. stage 0 is the
normal one, and is the only one you'd see in any kind of normal use.
- However, when you do 'git-read-tree' with three trees, the "stage"
+ However, when you do 'git read-tree' with three trees, the "stage"
starts out at 1.
This means that you can do
as <tree1>, the current branch head as <tree2>, and the other
branch head as <tree3>.
- Furthermore, 'git-read-tree' has special-case logic that says: if you see
+ Furthermore, 'git read-tree' has special-case logic that says: if you see
a file that matches in all respects in the following states, it
"collapses" back to "stage0":
- stage 1 and stage 3 are the same and stage 2 is different take
stage 2 (we did something while they did nothing)
- The 'git-write-tree' command refuses to write a nonsensical tree, and it
+ 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.
populated. Here is an outline of how the algorithm works:
- if a file exists in identical format in all three trees, it will
- automatically collapse to "merged" state by 'git-read-tree'.
+ automatically collapse to "merged" state by 'git read-tree'.
- 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
matching "stage1" entry if it exists too. .. all the normal
trivial rules ..
- You would normally use 'git-merge-index' with supplied
- 'git-merge-one-file' to do this last step. The script updates
+ You would normally use 'git merge-index' with supplied
+ 'git merge-one-file' to do this last step. The script updates
the files in the working tree as it merges each path and at the
end of a successful merge.
$ git checkout-index -f -u -a $JC
----------------
- You do random edits, without running 'git-update-index'. And then
+ 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:
updated to the result of the merge.
However, if you have local changes in the working tree that
- would be overwritten by this merge, 'git-read-tree' will refuse
+ would be overwritten by this merge, 'git read-tree' will refuse
to run to prevent your changes from being lost.
In other words, there is no need to worry about what exists only
in the working tree. When you have local changes in a part of
the project that is not involved in the merge, your changes do
not interfere with the merge, and are kept intact. When they
- *do* interfere, the merge does not even start ('git-read-tree'
+ *do* interfere, the merge does not even start ('git read-tree'
complains loudly and fails without modifying anything). In such
a case, you can simply continue doing what you were in the
middle of doing, and when your working tree is ready (i.e. you
have finished your work-in-progress), attempt the merge again.
+Sparse checkout
+---------------
+
+"Sparse checkout" allows to sparsely populate working directory.
+It uses skip-worktree bit (see linkgit:git-update-index[1]) to tell
+Git whether a file on working directory is worth looking at.
+
+"git read-tree" and other merge-based commands ("git merge", "git
+checkout"...) can help maintaining skip-worktree bitmap and working
+directory update. `$GIT_DIR/info/sparse-checkout` is used to
+define the skip-worktree reference bitmap. When "git read-tree" needs
+to update working directory, it will reset skip-worktree bit in index
+based on this file, which uses the same syntax as .gitignore files.
+If an entry matches a pattern in this file, skip-worktree will be
+set on that entry. Otherwise, skip-worktree will be unset.
+
+Then it compares the new skip-worktree value with the previous one. If
+skip-worktree turns from unset to set, it will add the corresponding
+file back. If it turns from set to unset, that file will be removed.
+
+While `$GIT_DIR/info/sparse-checkout` is usually used to specify what
+files are in. You can also specify what files are _not_ in, using
+negate patterns. For example, to remove file "unwanted":
+
+----------------
+*
+!unwanted
+----------------
+
+Another tricky thing is fully repopulating working directory when you
+no longer want sparse checkout. You cannot just disable "sparse
+checkout" because skip-worktree are still in the index and you working
+directory is still sparsely populated. You should re-populate working
+directory with the `$GIT_DIR/info/sparse-checkout` file content as
+follows:
+
+----------------
+*
+----------------
+
+Then you can disable sparse checkout. Sparse checkout support in "git
+read-tree" and similar commands is disabled by default. You need to
+turn `core.sparseCheckout` on in order to have sparse checkout
+support.
+
+
SEE ALSO
--------
linkgit:git-write-tree[1]; linkgit:git-ls-files[1];
DESCRIPTION
-----------
- If <branch> is specified, 'git-rebase' will perform an automatic
+ If <branch> is specified, 'git rebase' will perform an automatic
`git checkout <branch>` before doing anything else. Otherwise
it remains on the current branch.
part of topicA. Note that the argument to --onto and the <upstream>
parameter can be any valid commit-ish.
- In case of conflict, 'git-rebase' will stop at the first problematic commit
- and leave conflict markers in the tree. You can use 'git-diff' to locate
+ In case of conflict, 'git rebase' will stop at the first problematic commit
+ and leave conflict markers in the tree. You can use 'git diff' to locate
the markers (<<<<<<) and make edits to resolve the conflict. For each
file you edit, you need to tell git that the conflict has been resolved,
typically this would be done with
git rebase --continue
- Alternatively, you can undo the 'git-rebase' with
+ Alternatively, you can undo the 'git rebase' with
git rebase --abort
-s <strategy>::
--strategy=<strategy>::
Use the given merge strategy.
- If there is no `-s` option 'git-merge-recursive' is used
+ If there is no `-s` option 'git merge-recursive' is used
instead. This implies --merge.
+
- Because 'git-rebase' replays each commit from the working branch
+ Because 'git rebase' replays each commit from the working branch
on top of the <upstream> branch using the given strategy, using
the 'ours' strategy simply discards all patches from the <branch>,
which makes little sense.
--ignore-whitespace::
--whitespace=<option>::
- These flag are passed to the 'git-apply' program
+ These flag are passed to the 'git apply' program
(see linkgit:git-apply[1]) that applies the patch.
Incompatible with the --interactive option.
--committer-date-is-author-date::
--ignore-date::
- These flags are passed to 'git-am' to easily change the dates
+ These flags are passed to 'git am' to easily change the dates
of the rebased commits (see linkgit:git-am[1]).
-i::
root commits will be rewritten to have <newbase> as parent
instead.
+--autosquash::
+ When the commit log message begins with "squash! ..." (or
+ "fixup! ..."), and there is a commit whose title begins with
+ the same ..., automatically modify the todo list of rebase -i
+ so that the commit marked for quashing come right after the
+ commit to be modified, and change the action of the moved
+ commit from `pick` to `squash` (or `fixup`).
++
+This option is only valid when '--interactive' option is used.
+
include::merge-strategies.txt[]
NOTES
-----
- You should understand the implications of using 'git-rebase' on a
+ You should understand the implications of using 'git rebase' on a
repository that you share. See also RECOVERING FROM UPSTREAM REBASE
below.
...
-------------------------------------------
- The oneline descriptions are purely for your pleasure; 'git-rebase' will
+ The oneline descriptions are purely for your pleasure; 'git rebase' will
not look at them but at the commit names ("deadbee" and "fa1afe1" in this
example), so do not delete or edit the names.
By replacing the command "pick" with the command "edit", you can tell
- 'git-rebase' to stop after applying that commit, so that you can edit
+ 'git rebase' to stop after applying that commit, so that you can edit
the files and/or the commit message, amend the commit, and continue
rebasing.
command "pick" with the command "reword".
If you want to fold two or more commits into one, replace the command
-"pick" with "squash" for the second and subsequent commit. If the
-commits had different authors, it will attribute the squashed commit to
-the author of the first commit.
+"pick" for the second and subsequent commits with "squash" or "fixup".
+If the commits had different authors, the folded commit will be
+attributed to the author of the first commit. The suggested commit
+message for the folded commit is the concatenation of the commit
+messages of the first commit and of those with the "squash" command,
+but omits the commit messages of commits with the "fixup" command.
- 'git-rebase' will stop when "pick" has been replaced with "edit" or
+ 'git rebase' will stop when "pick" has been replaced with "edit" or
when a command fails due to merge errors. When you are done editing
and/or resolving conflicts you can continue with `git rebase --continue`.
For example, if you want to reorder the last 5 commits, such that what
was HEAD~4 becomes the new HEAD. To achieve that, you would call
- 'git-rebase' like this:
+ 'git rebase' like this:
----------------------
$ git rebase -i HEAD~5
-----------------
In interactive mode, you can mark commits with the action "edit". However,
- this does not necessarily mean that 'git-rebase' expects the result of this
+ this does not necessarily mean that 'git rebase' expects the result of this
edit to be exactly one commit. Indeed, you can undo the commit, or you can
add other commits. This can be used to split a commit into two:
- Now add the changes to the index that you want to have in the first
commit. You can use `git add` (possibly interactively) or
- 'git-gui' (or both) to do that.
+ 'git gui' (or both) to do that.
- Commit the now-current index with whatever commit message is appropriate
now.
If you are not absolutely sure that the intermediate revisions are
consistent (they compile, pass the testsuite, etc.) you should use
- 'git-stash' to stash away the not-yet-committed changes
+ 'git stash' to stash away the not-yet-committed changes
after each commit, test, and amend the commit if fixes are necessary.
Hard case: The changes are not the same.::
This happens if the 'subsystem' rebase had conflicts, or used
- `\--interactive` to omit, edit, or squash commits; or if the
- upstream used one of `commit \--amend`, `reset`, or
+ `\--interactive` to omit, edit, squash, or fixup commits; or
+ if the upstream used one of `commit \--amend`, `reset`, or
`filter-branch`.
'subsystem' are literally the same before and after the rebase
'subsystem' did.
- In that case, the fix is easy because 'git-rebase' knows to skip
+ In that case, the fix is easy because 'git rebase' knows to skip
changes that are already present in the new upstream. So if you say
(assuming you're on 'topic')
------------
example, a commit that was removed via `git rebase
\--interactive` will be **resurrected**!
- The idea is to manually tell 'git-rebase' "where the old 'subsystem'
+ The idea is to manually tell 'git rebase' "where the old 'subsystem'
ended and your 'topic' began", that is, what the old merge-base
between them was. You will have to find a way to name the last commit
of the old 'subsystem', for example:
- * With the 'subsystem' reflog: after 'git-fetch', the old tip of
+ * With the 'subsystem' reflog: after 'git fetch', the old tip of
'subsystem' is at `subsystem@\{1}`. Subsequent fetches will
increase the number. (See linkgit:git-reflog[1].)
--soft::
Does not touch the index file nor the working tree at all, but
requires them to be in a good order. This leaves all your changed
- files "Changes to be committed", as 'git-status' would
+ files "Changes to be committed", as 'git status' would
put it.
--hard::
linkgit:git-add[1]).
-q::
+--quiet::
Be quiet, only report errors.
<commit>::
Commit to make the current HEAD. If not given defaults to HEAD.
+DISCUSSION
+----------
+
+The tables below show what happens when running:
+
+----------
+git reset --option target
+----------
+
+to reset the HEAD to another commit (`target`) with the different
+reset options depending on the state of the files.
+
+In these tables, A, B, C and D are some different states of a
+file. For example, the first line of the first table means that if a
+file is in state A in the working tree, in state B in the index, in
+state C in HEAD and in state D in the target, then "git reset --soft
+target" will put the file in state A in the working tree, in state B
+in the index and in state D in HEAD.
+
+ working index HEAD target working index HEAD
+ ----------------------------------------------------
+ A B C D --soft A B D
+ --mixed A D D
+ --hard D D D
+ --merge (disallowed)
+
+ working index HEAD target working index HEAD
+ ----------------------------------------------------
+ A B C C --soft A B C
+ --mixed A C C
+ --hard C C C
+ --merge (disallowed)
+
+ working index HEAD target working index HEAD
+ ----------------------------------------------------
+ B B C D --soft B B D
+ --mixed B D D
+ --hard D D D
+ --merge D D D
+
+ working index HEAD target working index HEAD
+ ----------------------------------------------------
+ B B C C --soft B B C
+ --mixed B C C
+ --hard C C C
+ --merge C C C
+
+ working index HEAD target working index HEAD
+ ----------------------------------------------------
+ B C C D --soft B C D
+ --mixed B D D
+ --hard D D D
+ --merge (disallowed)
+
+ working index HEAD target working index HEAD
+ ----------------------------------------------------
+ B C C C --soft B C C
+ --mixed B C C
+ --hard C C C
+ --merge B C C
+
+"reset --merge" is meant to be used when resetting out of a conflicted
+merge. Any mergy operation guarantees that the work tree file that is
+involved in the merge does not have local change wrt the index before
+it starts, and that it writes the result out to the work tree. So if
+we see some difference between the index and the target and also
+between the index and the work tree, then it means that we are not
+resetting out from a state that a mergy operation left after failing
+with a conflict. That is why we disallow --merge option in this case.
+
+The following tables show what happens when there are unmerged
+entries:
+
+ working index HEAD target working index HEAD
+ ----------------------------------------------------
+ X U A B --soft (disallowed)
+ --mixed X B B
+ --hard B B B
+ --merge B B B
+
+ working index HEAD target working index HEAD
+ ----------------------------------------------------
+ X U A A --soft (disallowed)
+ --mixed X A A
+ --hard A A A
+ --merge A A A
+
+X means any state and U means an unmerged index.
+
Examples
--------
Many git porcelainish commands take mixture of flags
(i.e. parameters that begin with a dash '-') and parameters
- meant for the underlying 'git-rev-list' command they use internally
+ meant for the underlying 'git rev-list' command they use internally
and flags and parameters for the other commands they use
- downstream of 'git-rev-list'. This command is used to
+ downstream of 'git rev-list'. This command is used to
distinguish between them.
OPTIONS
-------
--parseopt::
- Use 'git-rev-parse' in option parsing mode (see PARSEOPT section below).
+ Use 'git rev-parse' in option parsing mode (see PARSEOPT section below).
--keep-dashdash::
Only meaningful in `--parseopt` mode. Tells the option parser to echo
that take options themself.
--sq-quote::
- Use 'git-rev-parse' in shell quoting mode (see SQ-QUOTE
+ Use 'git rev-parse' in shell quoting mode (see SQ-QUOTE
section below). In contrast to the `--sq` option below, this
mode does only quoting. Nothing else is done to command input.
--revs-only::
Do not output flags and parameters not meant for
- 'git-rev-list' command.
+ 'git rev-list' command.
--no-revs::
Do not output flags and parameters meant for
- 'git-rev-list' command.
+ 'git rev-list' command.
--flags::
Do not output non-flag parameters.
properly quoted for consumption by shell. Useful when
you expect your parameter to contain whitespaces and
newlines (e.g. when using pickaxe `-S` with
- 'git-diff-\*'). In contrast to the `--sq-quote` option,
+ 'git diff-\*'). In contrast to the `--sq-quote` option,
the command input is still interpreted as usual.
--not::
--remotes::
Show tag refs found in `$GIT_DIR/refs/remotes`.
+--show-toplevel::
+ Show the absolute path of the top-level directory.
+
--show-prefix::
When the command is invoked from a subdirectory, show the
path of the current directory relative to the top-level
--since=datestring::
--after=datestring::
Parse the date string, and output the corresponding
- --max-age= parameter for 'git-rev-list'.
+ --max-age= parameter for 'git rev-list'.
--until=datestring::
--before=datestring::
Parse the date string, and output the corresponding
- --min-age= parameter for 'git-rev-list'.
+ --min-age= parameter for 'git rev-list'.
<args>...::
Flags and parameters to be parsed.
name the same commit object if there are no other object in
your repository whose object name starts with dae86e.
- * An output from 'git-describe'; i.e. a closest tag, optionally
+ * An output from 'git describe'; i.e. a closest tag, optionally
followed by a dash and a number of commits, followed by a dash, a
`g`, and an abbreviated object name.
+
HEAD names the commit your changes in the working tree is based on.
FETCH_HEAD records the branch you fetched from a remote repository
- with your last 'git-fetch' invocation.
+ with your last 'git fetch' invocation.
ORIG_HEAD is created by commands that moves your HEAD in a drastic
way, to record the position of the HEAD before their operation, so that
you can change the tip of the branch back to the state before you ran
them easily.
MERGE_HEAD records the commit(s) you are merging into your branch
- when you run 'git-merge'.
+ when you run 'git merge'.
* A ref followed by the suffix '@' with a date specification
enclosed in a brace
SPECIFYING RANGES
-----------------
- History traversing commands such as 'git-log' operate on a set
+ History traversing commands such as 'git log' operate on a set
of commits, not just a single commit. To these commands,
specifying a single revision with the notation described in the
previous section means the set of commits reachable from that
PARSEOPT
--------
- In `--parseopt` mode, 'git-rev-parse' helps massaging options to bring to shell
+ In `--parseopt` mode, 'git rev-parse' helps massaging options to bring to shell
scripts the same facilities C builtins have. It works as an option normalizer
(e.g. splits single switches aggregate values), a bit like `getopt(1)` does.
Input Format
~~~~~~~~~~~~
- 'git-rev-parse --parseopt' input format is fully text based. It has two parts,
+ 'git rev-parse --parseopt' input format is fully text based. It has two parts,
separated by a line that contains only `--`. The lines before the separator
(should be more than one) are used for the usage.
The lines after the separator describe the options.
SQ-QUOTE
--------
- In `--sq-quote` mode, 'git-rev-parse' echoes on the standard output a
+ In `--sq-quote` mode, 'git rev-parse' echoes on the standard output a
single line suitable for `sh(1)` `eval`. This line is made by
normalizing the arguments following `--sq-quote`. Nothing other than
quoting the arguments is done.
If you want command input to still be interpreted as usual by
- 'git-rev-parse' before the output is shell quoted, see the `--sq`
+ 'git rev-parse' before the output is shell quoted, see the `--sq`
option.
Example
[--cacheinfo <mode> <object> <file>]\*
[--chmod=(+|-)x]
[--assume-unchanged | --no-assume-unchanged]
+ [--skip-worktree | --no-skip-worktree]
[--ignore-submodules]
[--really-refresh] [--unresolve] [--again | -g]
[--info-only] [--index-info]
See also linkgit:git-add[1] for a more user-friendly way to do some of
the most common operations on the index.
- The way 'git-update-index' handles files it is told about can be modified
+ The way 'git update-index' handles files it is told about can be modified
using the various options:
OPTIONS
-q::
Quiet. If --refresh finds that the index needs an update, the
default behavior is to error out. This option makes
- 'git-update-index' continue anyway.
+ 'git update-index' continue anyway.
--ignore-submodules::
Do not try to update submodules. This option is only respected
--unmerged::
If --refresh finds unmerged changes in the index, the default
- behavior is to error out. This option makes 'git-update-index'
+ behavior is to error out. This option makes 'git update-index'
continue anyway.
--ignore-missing::
Like '--refresh', but checks stat information unconditionally,
without regard to the "assume unchanged" setting.
+--skip-worktree::
+--no-skip-worktree::
+ When one of these flags is specified, the object name recorded
+ for the paths are not updated. Instead, these options
+ set and unset the "skip-worktree" bit for the paths. See
+ section "Skip-worktree bit" below for more information.
+
-g::
--again::
- Runs 'git-update-index' itself on the paths whose index
+ Runs 'git update-index' itself on the paths whose index
entries are different from those from the `HEAD` commit.
--unresolve::
--replace::
By default, when a file `path` exists in the index,
- 'git-update-index' refuses an attempt to add `path/file`.
+ 'git update-index' refuses an attempt to add `path/file`.
Similarly if a file `path/file` exists, a file `path`
cannot be added. With --replace flag, existing entries
that conflict with the entry being added are
can refresh the index for a file that hasn't been changed but where
the stat entry is out of date.
- For example, you'd want to do this after doing a 'git-read-tree', to link
+ For example, you'd want to do this after doing a 'git read-tree', to link
up the stat index details with the proper files.
Using --cacheinfo or --info-only
. mode SP type SP sha1 TAB path
+
- The second format is to stuff 'git-ls-tree' output
+ The second format is to stuff 'git ls-tree' output
into the index file.
. mode SP sha1 SP stage TAB path
+
This format is to put higher order stages into the
- index file and matches 'git-ls-files --stage' output.
+ index file and matches 'git ls-files --stage' output.
To place a higher stage entry to the index, the path should
first be removed by feeding a mode=0 entry for the path, and
The command looks at `core.ignorestat` configuration variable. When
this is true, paths updated with `git update-index paths...` and
paths updated with other git commands that update both index and
- working tree (e.g. 'git-apply --index', 'git-checkout-index -u',
- and 'git-read-tree -u') are automatically marked as "assume
+ working tree (e.g. 'git apply --index', 'git checkout-index -u',
+ and 'git read-tree -u') are automatically marked as "assume
unchanged". Note that "assume unchanged" bit is *not* set if
`git update-index --refresh` finds the working tree file matches
the index (use `git update-index --really-refresh` if you want
<9> now it checks with lstat(2) and finds it has been changed.
+Skip-worktree bit
+-----------------
+
+Skip-worktree bit can be defined in one (long) sentence: When reading
+an entry, if it is marked as skip-worktree, then Git pretends its
+working directory version is up to date and read the index version
+instead.
+
+To elaborate, "reading" means checking for file existence, reading
+file attributes or file content. The working directory version may be
+present or absent. If present, its content may match against the index
+version or not. Writing is not affected by this bit, content safety
+is still first priority. Note that Git _can_ update working directory
+file, that is marked skip-worktree, if it is safe to do so (i.e.
+working directory version matches index version)
+
+Although this bit looks similar to assume-unchanged bit, its goal is
+different from assume-unchanged bit's. Skip-worktree also takes
+precedence over assume-unchanged bit when both are set.
+
+
Configuration
-------------
This causes the command to ignore differences in file modes recorded
in the index and the file mode on the filesystem if they differ only on
executable bit. On such an unfortunate filesystem, you may
- need to use 'git-update-index --chmod='.
+ need to use 'git update-index --chmod='.
Quite similarly, if `core.symlinks` configuration variable is set
to 'false' (see linkgit:git-config[1]), symbolic links are checked out
branch of the `git.git` repository.
Documentation for older releases are available here:
-* link:v1.6.6/git.html[documentation for release 1.6.6]
+* link:v1.6.6.1/git.html[documentation for release 1.6.6.1]
* release notes for
+ link:RelNotes-1.6.6.1.txt[1.6.6.1],
link:RelNotes-1.6.6.txt[1.6.6].
-* link:v1.6.5.7/git.html[documentation for release 1.6.5.7]
+* link:v1.6.5.8/git.html[documentation for release 1.6.5.8]
* release notes for
+ link:RelNotes-1.6.5.8.txt[1.6.5.8],
link:RelNotes-1.6.5.7.txt[1.6.5.7],
link:RelNotes-1.6.5.6.txt[1.6.5.6],
link:RelNotes-1.6.5.5.txt[1.6.5.5],
linkgit:git-config[1].
'GIT_SSH'::
- If this environment variable is set then 'git-fetch'
- and 'git-push' will use this command instead
+ If this environment variable is set then 'git fetch'
+ and 'git push' will use this command instead
of 'ssh' when they need to connect to a remote system.
The '$GIT_SSH' command will be given exactly two arguments:
the 'username@host' (or just 'host') from the URL and the
'GIT_FLUSH'::
If this environment variable is set to "1", then commands such
- as 'git-blame' (in incremental mode), 'git-rev-list', 'git-log',
- and 'git-whatchanged' will force a flush of the output stream
+ as 'git blame' (in incremental mode), 'git rev-list', 'git log',
+ and 'git whatchanged' 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
plumbing directly very often, but it can be good to know what the
plumbing does for when the porcelain isn't flushing.
+Back when this document was originally written, many porcelain
+commands were shell scripts. For simplicity, it still uses them as
+examples to illustrate how plumbing is fit together to form the
+porcelain commands. The source tree includes some of these scripts in
+contrib/examples/ for reference. Although these are not implemented as
+shell scripts anymore, the description of what the plumbing layer
+commands do is still valid.
+
[NOTE]
Deeper technical details are often marked as Notes, which you can
skip on your first reading.
For our first example, we're going to start a totally new repository from
scratch, with no pre-existing files, and we'll call it 'git-tutorial'.
To start up, create a subdirectory for it, change into that
- subdirectory, and initialize the git infrastructure with 'git-init':
+ subdirectory, and initialize the git infrastructure with 'git init':
------------------------------------------------
$ mkdir git-tutorial
- commit that index file as an object.
The first step is trivial: when you want to tell git about any changes
- to your working tree, you use the 'git-update-index' program. That
+ to your working tree, you use the 'git update-index' program. That
program normally just takes a list of filenames you want to update, but
to avoid trivial mistakes, it refuses to add new entries to the index
(or remove existing ones) unless you explicitly tell it that you're
which correspond with the objects with names of `557db...` and
`f24c7...` respectively.
- If you want to, you can use 'git-cat-file' to look at those objects, but
+ If you want to, you can use 'git cat-file' to look at those objects, but
you'll have to use the object name, not the filename of the object:
----------------
$ git cat-file -t 557db03de997c86a4a028e1ebd3a1ceb225be238
----------------
- where the `-t` tells 'git-cat-file' to tell you what the "type" of the
+ 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 (i.e., just a
regular file), and you can see the contents with
Anyway, as we mentioned previously, you normally never actually take a
look at the objects themselves, and typing long 40-character hex
names is not something you'd normally want to do. The above digression
- was just to show that 'git-update-index' did something magical, and
+ was just to show that 'git update-index' did something magical, and
actually saved away the contents of your files into the git object
database.
and you can now, since you told git about the previous state of `hello`, ask
git what has changed in the tree compared to your old index, using the
- 'git-diff-files' command:
+ 'git diff-files' command:
------------
$ git diff-files
that it has noticed that "hello" has been modified, and that the old object
contents it had have been replaced with something else.
- To make it readable, we can tell 'git-diff-files' to output the
+ To make it readable, we can tell 'git diff-files' to output the
differences as a patch, using the `-p` flag:
------------
i.e. the diff of the change we caused by adding another line to `hello`.
- In other words, 'git-diff-files' always shows us the difference between
+ In other words, 'git diff-files' always shows us the difference between
what is recorded in the index, and what is currently in the working
tree. That's very useful.
object as a 'commit' object together with an explanation of what the
tree was all about, along with information of how we came to that state.
- Creating a tree object is trivial, and is done with 'git-write-tree'.
+ Creating a tree object is trivial, and is done with 'git write-tree'.
There are no options or other input: `git write-tree` will take the
current index state, and write an object that describes that whole
index. In other words, we're now tying together all the different
`git cat-file` to actually output the raw object contents, but you'll see
mainly a binary mess, so that's less interesting).
- However -- normally you'd never use 'git-write-tree' on its own, because
+ However -- normally you'd never use 'git write-tree' on its own, because
normally you always commit a tree into a commit object using the
- 'git-commit-tree' command. In fact, it's easier to not actually use
- 'git-write-tree' on its own at all, but to just pass its result in as an
- argument to 'git-commit-tree'.
+ 'git commit-tree' command. In fact, it's easier to not actually use
+ 'git write-tree' on its own at all, but to just pass its result in as an
+ argument to 'git commit-tree'.
- 'git-commit-tree' normally takes several arguments -- it wants to know
+ 'git commit-tree' normally takes several arguments -- it wants to know
what the 'parent' of a commit was, but since this is the first commit
ever in this new repository, and it has no parents, we only need to pass in
- the object name of the tree. However, 'git-commit-tree' also wants to get a
+ the object name of the tree. However, 'git commit-tree' also wants to get a
commit message on its standard input, and it will write out the resulting
object name for the commit to its standard output.
And this is where we create the `.git/refs/heads/master` file
which is pointed at by `HEAD`. This file is supposed to contain
the reference to the top-of-tree of the master branch, and since
- that's exactly what 'git-commit-tree' spits out, we can do this
+ that's exactly what 'git commit-tree' spits out, we can do this
all with a sequence of simple shell commands:
------------------------------------------------
Making a change
---------------
- Remember how we did the 'git-update-index' on file `hello` and then we
+ Remember how we did the 'git update-index' on file `hello` and then we
changed `hello` afterward, and could compare the new state of `hello` with the
state we saved in the index file?
- Further, remember how I said that 'git-write-tree' writes the contents
+ Further, remember how I said that 'git write-tree' writes the contents
of the *index* file to the tree, and thus what we just committed was in
fact the *original* contents of the file `hello`, not the new ones. We did
that on purpose, to show the difference between the index state, and the
we'll still see the same difference we saw last time: the index file
hasn't changed by the act of committing anything. However, now that we
have committed something, we can also learn to use a new command:
- 'git-diff-index'.
+ 'git diff-index'.
- Unlike 'git-diff-files', which showed the difference between the index
- file and the working tree, 'git-diff-index' shows the differences
+ Unlike 'git diff-files', which showed the difference between the index
+ file and the working tree, 'git diff-index' shows the differences
between a committed *tree* and either the index file or the working
- tree. In other words, 'git-diff-index' wants a tree to be diffed
+ tree. In other words, 'git diff-index' wants a tree to be diffed
against, and before we did the commit, we couldn't do that, because we
didn't have anything to diff against.
$ git diff-index -p HEAD
----------------
- (where `-p` has the same meaning as it did in 'git-diff-files'), and it
+ (where `-p` has the same meaning as it did in 'git diff-files'), and it
will show us the same difference, but for a totally different reason.
Now we're comparing the working tree not against the index file,
but against the tree we just wrote. It just so happens that those two
which ends up doing the above for you.
- In other words, 'git-diff-index' normally compares a tree against the
+ In other words, 'git diff-index' normally compares a tree against the
working tree, but when given the `\--cached` flag, it is told to
instead compare against just the index cache contents, and ignore the
current working tree state entirely. Since we just wrote the index
[NOTE]
================
- 'git-diff-index' really always uses the index for its
+ 'git diff-index' really always uses the index for its
comparisons, and saying that it compares a tree against the working
tree is thus not strictly accurate. In particular, the list of
files to compare (the "meta-data") *always* comes from the index file,
(note how we didn't need the `\--add` flag this time, since git knew
about the file already).
- Note what happens to the different 'git-diff-\*' versions here. After
+ Note what happens to the different 'git diff-\*' versions here. After
we've updated `hello` in the index, `git diff-files -p` now shows no
differences, but `git diff-index -p HEAD` still *does* show that the
current state is different from the state we committed. In fact, now
- 'git-diff-index' shows the same difference whether we use the `--cached`
+ 'git diff-index' shows the same difference whether we use the `--cached`
flag or not, since now the index is coherent with the working tree.
Now, since we've updated `hello` in the index, we can commit the new
looking at what `git commit` really does, feel free to investigate:
it's a few very simple shell scripts to generate the helpful (?) commit
message headers, and a few one-liners that actually do the
- commit itself ('git-commit').
+ commit itself ('git commit').
Inspecting Changes
While creating changes is useful, it's even more useful if you can tell
later what changed. The most useful command for this is another of the
- 'diff' family, namely 'git-diff-tree'.
+ 'diff' family, namely 'git diff-tree'.
- 'git-diff-tree' can be given two arbitrary trees, and it will tell you the
+ 'git diff-tree' can be given two arbitrary trees, and it will tell you the
differences between them. Perhaps even more commonly, though, you can
give it just a single commit object, and it will figure out the parent
of that commit itself, and show the difference directly. Thus, to get
+-----------+
============
- More interestingly, you can also give 'git-diff-tree' the `--pretty` flag,
+ More interestingly, you can also give 'git diff-tree' the `--pretty` flag,
which tells it to also show the commit message and author and date of the
commit, and you can tell it to show a whole series of diffs.
Alternatively, you can tell it to be "silent", and not show the diffs at
all, but just show the actual commit message.
- In fact, together with the 'git-rev-list' program (which generates a
- list of revisions), 'git-diff-tree' ends up being a veritable fount of
- changes. A trivial (but very useful) script called 'git-whatchanged' is
+ In fact, together with the 'git rev-list' program (which generates a
+ list of revisions), 'git diff-tree' ends up being a veritable fount of
+ changes. A trivial (but very useful) script called 'git whatchanged' is
included with git which does exactly this, and shows a log of recent
activities.
If this is a problem because it is huge, you can hide it by setting
the log.showroot configuration variable to false. Having this, you
can still show it for each command just adding the `\--root` option,
- which is a flag for 'git-diff-tree' accepted by both commands.
+ which is a flag for 'git diff-tree' accepted by both commands.
With that, you should now be having some inkling of what git does, and
can explore on your own.
[NOTE]
Most likely, you are not directly using the core
- git Plumbing commands, but using Porcelain such as 'git-add', `git-rm'
+ git Plumbing commands, but using Porcelain such as 'git add', `git-rm'
and `git-commit'.
message, along with optionally a PGP signature that says that yes,
you really did
that tag. You create these annotated tags with either the `-a` or
- `-s` flag to 'git-tag':
+ `-s` flag to 'git tag':
----------------
$ git tag -s <tagname>
history outside the project you created.
- if you want to move or duplicate a git repository, you can do so. There
- is 'git-clone' command, but if all you want to do is just to
+ is 'git clone' command, but if all you want to do is just to
create a copy of your repository (with all the full history that
went along with it), you can do so with a regular
`cp -a git-tutorial new-git-tutorial`.
index cache when you do this, and especially with other peoples'
repositories you often want to make sure that the index cache is in some
known state (you don't know *what* they've done and not yet checked in),
- so usually you'll precede the 'git-update-index' with a
+ so usually you'll precede the 'git update-index' with a
----------------
$ git read-tree --reset HEAD
----------------
which will force a total index re-build from the tree pointed to by `HEAD`.
- It resets the index contents to `HEAD`, and then the 'git-update-index'
+ It resets the index contents to `HEAD`, and then the 'git update-index'
makes sure to match up all index entries with the checked-out files.
If the original repository had uncommitted changes in its
working tree, `git update-index --refresh` notices them and
and in fact a lot of the common git command combinations can be scripted
with the `git xyz` interfaces. You can learn things by just looking
at what the various git scripts do. For example, `git reset` used to be
- the above two lines implemented in 'git-reset', but some things like
- 'git-status' and 'git-commit' are slightly more complex scripts around
+ the above two lines implemented in 'git reset', but some things like
+ 'git status' and 'git commit' are slightly more complex scripts around
the basic git commands.
Many (most?) public remote repositories will not contain any of
up-to-date (so that you don't have to refresh it afterward), and the
`-a` flag means "check out all files" (if you have a stale copy or an
older version of a checked out tree you may also need to add the `-f`
- flag first, to tell 'git-checkout-index' to *force* overwriting of any old
+ flag first, to tell 'git checkout-index' to *force* overwriting of any old
files).
Again, this can all be simplified with
================================================
If you make the decision to start your new branch at some
other point in the history than the current `HEAD`, you can do so by
- just telling 'git-checkout' what the base of the checkout would be.
+ just telling 'git checkout' what the base of the checkout would be.
In other words, if you have an earlier tag or branch, you'd just do
------------
which will simply _create_ the branch, but will not do anything further.
You can then later -- once you decide that you want to actually develop
- on that branch -- switch to that branch with a regular 'git-checkout'
+ on that branch -- switch to that branch with a regular 'git checkout'
with the branchname as the argument.
Anyway, let's exit 'gitk' (`^Q` or the File menu), and decide that we want
to merge the work we did on the `mybranch` branch into the `master`
branch (which is currently our `HEAD` too). To do that, there's a nice
- script called 'git-merge', which wants to know which branches you want
+ script called 'git merge', which wants to know which branches you want
to resolve and what the merge is all about:
------------
which will very loudly warn you that you're now committing a merge
(which is correct, so never mind), and you can write a small merge
- message about your adventures in 'git-merge'-land.
+ message about your adventures in 'git merge'-land.
After you're done, start up `gitk \--all` to see graphically what the
history looks like. Notice that `mybranch` still exists, and you can
see more complex cases.
[NOTE]
- Without the '--more=1' option, 'git-show-branch' would not output the
+ Without the '--more=1' option, 'git show-branch' would not output the
'[master^]' commit, as '[mybranch]' commit is a common ancestor of
both 'master' and 'mybranch' tips. Please see linkgit:git-show-branch[1]
for details.
[NOTE]
If there were more commits on the 'master' branch after the merge, the
- merge commit itself would not be shown by 'git-show-branch' by
+ merge commit itself would not be shown by 'git show-branch' by
default. You would need to provide '--sparse' option to make the
merge commit visible in this case.
Now, let's pretend you are the one who did all the work in
`mybranch`, and the fruit of your hard work has finally been merged
to the `master` branch. Let's go back to `mybranch`, and run
- 'git-merge' to get the "upstream changes" back to your branch.
+ 'git merge' to get the "upstream changes" back to your branch.
------------
$ git checkout mybranch
It's usually much more common that you merge with somebody else than
merging with your own branches, so it's worth pointing out that git
makes that very easy too, and in fact, it's not that different from
- doing a 'git-merge'. In fact, a remote merge ends up being nothing
+ doing a 'git merge'. In fact, a remote merge ends up being nothing
more than "fetch the work from a remote repository into a temporary tag"
- followed by a 'git-merge'.
+ followed by a 'git merge'.
Fetching from a remote repository is done by, unsurprisingly,
- 'git-fetch':
+ 'git fetch':
----------------
$ git fetch <remote-repository>
transports', because they do not require any git aware smart
server like git Native transport does. Any stock HTTP server
that does not even support directory index would suffice. But
- you must prepare your repository with 'git-update-server-info'
+ you must prepare your repository with 'git update-server-info'
to help dumb transport downloaders.
Once you fetch from the remote repository, you `merge` that
[NOTE]
You could do without using any branches at all, by
keeping as many local repositories as you would like to have
- branches, and merging between them with 'git-pull', just like
+ branches, and merging between them with 'git pull', just like
you merge between branches. The advantage of this approach is
that it lets you keep a set of files for each `branch` checked
out and you may find it easier to switch back and forth if you
$ git config remote.linus.url http://www.kernel.org/pub/scm/git/git.git/
------------------------------------------------
- and use the "linus" keyword with 'git-pull' instead of the full URL.
+ and use the "linus" keyword with 'git pull' instead of the full URL.
Examples.
+* [master^] Some fun.
------------
- Remember, before running 'git-merge', our `master` head was at
+ Remember, before running 'git merge', our `master` head was at
"Some fun." commit, while our `mybranch` head was at "Some
work." commit.
`git merge` command, when merging two branches, uses 3-way merge
algorithm. First, it finds the common ancestor between them.
- The command it uses is 'git-merge-base':
+ The command it uses is 'git merge-base':
------------
$ mb=$(git merge-base HEAD mybranch)
$ git read-tree -m -u $mb HEAD mybranch
------------
- This is the same 'git-read-tree' command we have already seen,
+ This is the same 'git read-tree' command we have already seen,
but it takes three trees, unlike previous examples. This reads
the contents of each tree into different 'stage' in the index
file (the first tree goes to stage 1, the second to stage 2,
The next step of merging is to merge these three versions of the
file, using 3-way merge. This is done by giving
- 'git-merge-one-file' command as one of the arguments to
- 'git-merge-index' command:
+ 'git merge-one-file' command as one of the arguments to
+ 'git merge-index' command:
------------
$ git merge-index git-merge-one-file hello
fatal: merge program failed
------------
- 'git-merge-one-file' script is called with parameters to
+ 'git merge-one-file' script is called with parameters to
describe those three versions, and is responsible to leave the
merge results in the working tree.
It is a fairly straightforward shell script, and
------------
This is the state of the index file and the working file after
- 'git-merge' returns control back to you, leaving the conflicting
+ 'git merge' returns control back to you, leaving the conflicting
merge for you to resolve. Notice that the path `hello` is still
- unmerged, and what you see with 'git-diff' at this point is
+ unmerged, and what you see with 'git diff' at this point is
differences since stage 2 (i.e. your version).
done only once.
[NOTE]
- 'git-push' uses a pair of commands,
- 'git-send-pack' on your local machine, and 'git-receive-pack'
+ 'git push' uses a pair of commands,
+ 'git send-pack' on your local machine, and 'git-receive-pack'
on the remote machine. The communication between the two over
the network internally uses an SSH connection.
------------
Then, make that directory into a git repository by running
- 'git-init', but this time, since its name is not the usual
+ 'git init', but this time, since its name is not the usual
`.git`, we do things slightly differently:
------------
will do it for you. If you followed the tutorial examples, you
would have accumulated about 17 objects in `.git/objects/??/`
- directories by now. 'git-repack' tells you how many objects it
+ directories by now. 'git repack' tells you how many objects it
packed, and stores the packed file in `.git/objects/pack`
directory.
in the pack, and the latter holds the index for random
access.
- If you are paranoid, running 'git-verify-pack' command would
+ If you are paranoid, running 'git verify-pack' command would
detect if you have a corrupt pack, but do not worry too much.
Our programs are always perfect ;-).
transport protocols (HTTP), you need to keep this repository
'dumb transport friendly'. After `git init`,
`$GIT_DIR/hooks/post-update.sample` copied from the standard templates
- would contain a call to 'git-update-server-info'
+ would contain a call to 'git update-server-info'
but you need to manually enable the hook with
`mv post-update.sample post-update`. This makes sure
- 'git-update-server-info' keeps the necessary files up-to-date.
+ 'git update-server-info' keeps the necessary files up-to-date.
3. Push into the public repository from your primary
repository.
- 4. 'git-repack' the public repository. This establishes a big
+ 4. 'git repack' the public repository. This establishes a big
pack that contains the initial set of objects as the
- baseline, and possibly 'git-prune' if the transport
+ baseline, and possibly 'git prune' if the transport
used for pulling from your repository supports packed
repositories.
6. Push your changes to the public repository, and announce it
to the public.
- 7. Every once in a while, 'git-repack' the public repository.
+ 7. Every once in a while, 'git repack' the public repository.
Go back to step 5. and continue working.
A recommended work cycle for a "subsystem maintainer" who works
on that project and has an own "public repository" goes like this:
- 1. Prepare your work repository, by 'git-clone' the public
+ 1. Prepare your work repository, by 'git clone' the public
repository of the "project lead". The URL used for the
initial cloning is stored in the remote.origin.url
configuration variable.
point at the repository you are borrowing from.
4. Push into the public repository from your primary
- repository. Run 'git-repack', and possibly 'git-prune' if the
+ repository. Run 'git repack', and possibly 'git prune' if the
transport used for pulling from your repository supports
packed repositories.
"project lead" and possibly your "sub-subsystem
maintainers" to pull from it.
- 7. Every once in a while, 'git-repack' the public repository.
+ 7. Every once in a while, 'git repack' the public repository.
Go back to step 5. and continue working.
not have a "public" repository is somewhat different. It goes
like this:
- 1. Prepare your work repository, by 'git-clone' the public
+ 1. Prepare your work repository, by 'git clone' the public
repository of the "project lead" (or a "subsystem
maintainer", if you work on a subsystem). The URL used for
the initial cloning is stored in the remote.origin.url
------------
You can make sure `git show-branch` matches the state before
- those two 'git-merge' you just did. Then, instead of running
- two 'git-merge' commands in a row, you would merge these two
+ those two 'git merge' you just did. Then, instead of running
+ two 'git merge' commands in a row, you would merge these two
branch heads (this is known as 'making an Octopus'):
------------