Diff best viewed with --color-diff.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
[[summary]]
== Summary
-This document gathers tips, scripts and configuration files to help people
+This document gathers tips, scripts, and configuration files to help people
working on Git's codebase use their favorite tools while following Git's
coding style.
clean.requireForce::
A boolean to make git-clean do nothing unless given -f,
- -i or -n. Defaults to true.
+ -i, or -n. Defaults to true.
matching text in context lines
`matchSelected`;;
matching text in selected lines. Also, used to customize the following
- linkgit:git-log[1] subcommands: `--grep`, `--author` and `--committer`.
+ linkgit:git-log[1] subcommands: `--grep`, `--author`, and `--committer`.
`selected`;;
non-matching text in selected lines. Also, used to customize the
following linkgit:git-log[1] subcommands: `--grep`, `--author` and
credential.<url>.*::
Any of the credential.* options above can be applied selectively to
- some credentials. For example "credential.https://example.com.username"
+ some credentials. For example, "credential.https://example.com.username"
would set the default username only for https connections to
example.com. See linkgit:gitcredentials[7] for details on how URLs are
matched.
fastimport.unpackLimit::
If the number of objects imported by linkgit:git-fast-import[1]
is below this limit, then the objects will be unpacked into
- loose object files. However if the number of imported objects
- equals or exceeds this limit then the pack will be stored as a
+ loose object files. However, if the number of imported objects
+ equals or exceeds this limit, then the pack will be stored as a
pack. Storing the pack from a fast-import can make the import
operation complete faster, especially on slow filesystems. If
not set, the value of `transfer.unpackLimit` is used instead.
same applies for the corresponding `receive.fsck.*` and
`fetch.fsck.*`. variables.
+
-Unlike variables like `color.ui` and `core.editor` the
+Unlike variables like `color.ui` and `core.editor`, the
`receive.fsck.<msg-id>` and `fetch.fsck.<msg-id>` variables will not
fall back on the `fsck.<msg-id>` configuration if they aren't set. To
-uniformly configure the same fsck settings in different circumstances
+uniformly configure the same fsck settings in different circumstances,
all three of them must be set to the same values.
+
When `fsck.<msg-id>` is set, errors can be switched to warnings and
fsck.skipList::
The path to a list of object names (i.e. one unabbreviated SHA-1 per
line) that are known to be broken in a non-fatal way and should
- be ignored. On versions of Git 2.20 and later comments ('#'), empty
+ be ignored. On versions of Git 2.20 and later, comments ('#'), empty
lines, and any leading and trailing whitespace are ignored. Everything
but a SHA-1 per line will error out on older versions.
+
This feature is useful when an established project should be accepted
-despite early commits containing errors that can be safely ignored
+despite early commits containing errors that can be safely ignored,
such as invalid committer email addresses. Note: corrupt objects
cannot be skipped with this setting.
+
Unlike variables like `color.ui` and `core.editor` the
`receive.fsck.skipList` and `fetch.fsck.skipList` variables will not
fall back on the `fsck.skipList` configuration if they aren't set. To
-uniformly configure the same fsck settings in different circumstances
+uniformly configure the same fsck settings in different circumstances,
all three of them must be set to the same values.
+
Older versions of Git (before 2.20) documented that the object names
`--date` option. See linkgit:git-log[1] for details.
+
If the format is set to "auto:foo" and the pager is in use, format
-"foo" will be used for the date format. Otherwise "default" will
+"foo" will be used for the date format. Otherwise, "default" will
be used.
log.decorate::
marker and the original text before the `=======` marker. The
"merge" style tends to produce smaller conflict regions than diff3,
both because of the exclusion of the original text, and because
- when a subset of lines match on the two sides they are just pulled
+ when a subset of lines match on the two sides, they are just pulled
out of the conflict region. Another alternate style, "zdiff3", is
similar to diff3 but removes matching lines on the two sides from
the conflict region when those matching lines appear near either
For a custom merge command, specify whether the exit code of
the merge command can be used to determine whether the merge was
successful. If this is not set to true then the merge target file
- timestamp is checked and the merge is assumed to have been successful
- if the file has been updated, otherwise the user is prompted to
+ timestamp is checked, and the merge is assumed to have been successful
+ if the file has been updated; otherwise, the user is prompted to
indicate the success of the merge.
mergetool.meld.hasOutput::
mergetool.meld.useAutoMerge::
When the `--auto-merge` is given, meld will merge all non-conflicting
- parts automatically, highlight the conflicting parts and wait for
+ parts automatically, highlight the conflicting parts, and wait for
user decision. Setting `mergetool.meld.useAutoMerge` to `true` tells
Git to unconditionally use the `--auto-merge` option with `meld`.
Setting this value to `auto` makes git detect whether `--auto-merge`
for details.
mergetool.hideResolved::
- During a merge Git will automatically resolve as many conflicts as
+ During a merge, Git will automatically resolve as many conflicts as
possible and write the 'MERGED' file containing conflict markers around
any conflicts that it cannot resolve; 'LOCAL' and 'REMOTE' normally
represent the versions of the file from before Git's conflict
When invoking a custom merge tool, Git uses a set of temporary
files to pass to the tool. If the tool returns an error and this
variable is set to `true`, then these temporary files will be
- preserved, otherwise they will be removed after the tool has
+ preserved; otherwise, they will be removed after the tool has
exited. Defaults to `false`.
mergetool.writeToTemp::
--
push.followTags::
- If set to true enable `--follow-tags` option by default. You
+ If set to true, enable `--follow-tags` option by default. You
may override this configuration at time of push by specifying
`--no-follow-tags`.
Text editor used by `git rebase -i` for editing the rebase instruction file.
The value is meant to be interpreted by the shell when it is used.
It can be overridden by the `GIT_SEQUENCE_EDITOR` environment variable.
- When not configured the default commit message editor is used instead.
+ When not configured, the default commit message editor is used instead.
percent of entries the split index can contain compared to the
total number of entries in both the split index and the shared
index before a new shared index is written.
- The value should be between 0 and 100. If the value is 0 then
- a new shared index is always written, if it is 100 a new
+ The value should be between 0 and 100. If the value is 0, then
+ a new shared index is always written; if it is 100, a new
shared index is never written.
- By default the value is 20, so a new shared index is written
+ By default, the value is 20, so a new shared index is written
if the number of entries in the split index would be greater
than 20 percent of the total number of entries.
See linkgit:git-update-index[1].
up in the `author` and `committer` fields of commit
objects.
If you need the `author` or `committer` to be different, the
- `author.name`, `author.email`, `committer.name` or
+ `author.name`, `author.email`, `committer.name`, or
`committer.email` variables can be set.
All of these can be overridden by the `GIT_AUTHOR_NAME`,
`GIT_AUTHOR_EMAIL`, `GIT_COMMITTER_NAME`,
- `GIT_COMMITTER_EMAIL` and `EMAIL` environment variables.
+ `GIT_COMMITTER_EMAIL`, and `EMAIL` environment variables.
+
Note that the `name` forms of these variables conventionally refer to
some form of a personal name. See linkgit:git-commit[1] and the
configuration, then all "1.0-preX" tags will be listed before any
"1.0-rcX" tags. The placement of the main release tag relative to tags
with various suffixes can be determined by specifying the empty suffix
-among those other suffixes. E.g. if the suffixes "-rc", "", "-ck" and
+among those other suffixes. E.g. if the suffixes "-rc", "", "-ck", and
"-bfs" appear in the configuration in this order, then all "v4.8-rcX" tags
are listed first, followed by "v4.8", then "v4.8-ckX" and finally
"v4.8-bfsX".
files.
+
However, if the --combined-all-paths option is provided, instead of a
-two-line from-file/to-file you get an N+1 line from-file/to-file header,
+two-line from-file/to-file, you get an N+1 line from-file/to-file header,
where N is the number of parents in the merge commit:
--- a/file
In the above example output, the function signature was changed
from both files (hence two `-` removals from both file1 and
file2, plus `++` to mean one line that was added does not appear
-in either file1 or file2). Also eight other lines are the same
+in either file1 or file2). Also, eight other lines are the same
from file1 but do not appear in file2 (hence prefixed with `+`).
When shown by `git diff-tree -c`, it compares the parents of a
-f::
--force::
- When 'git fetch' is used with `<src>:<dst>` refspec it may
+ When 'git fetch' is used with `<src>:<dst>` refspec, it may
refuse to update the local branch as discussed
ifdef::git-pull[]
in the `<refspec>` part of the linkgit:git-fetch[1]
DESCRIPTION
-----------
Splits mail messages in a mailbox into commit log messages,
-authorship information and patches, and applies them to the
+authorship information, and patches, and applies them to the
current branch. You could think of it as a reverse operation
of linkgit:git-format-patch[1] run on a branch with a straight
history without merges.
automatically. This option allows the user to bypass the automatic
detection and specify the patch format that the patch(es) should be
interpreted as. Valid formats are mbox, mboxrd,
- stgit, stgit-series and hg.
+ stgit, stgit-series, and hg.
-i::
--interactive::
Reads the supplied diff output (i.e. "a patch") and applies it to files.
When running from a subdirectory in a repository, patched paths
outside the directory are ignored.
-With the `--index` option the patch is also applied to the index, and
-with the `--cached` option the patch is only applied to the index.
+With the `--index` option, the patch is also applied to the index, and
+with the `--cached` option, the patch is only applied to the index.
Without these options, the command applies the patch only to files,
and does not require them to be in a Git repository.
--summary::
Instead of applying the patch, output a condensed
summary of information obtained from git diff extended
- headers, such as creations, renames and mode changes.
+ headers, such as creations, renames, and mode changes.
Turns off "apply".
--check::
applying a diff generated with `--unified=0`. To bypass these
checks use `--unidiff-zero`.
+
-Note, for the reasons stated above the usage of context-free patches is
+Note, for the reasons stated above, the usage of context-free patches is
discouraged.
--apply::
--binary::
Historically we did not allow binary patch application
without an explicit permission from the user, and this
- flag was the way to do so. Currently we always allow binary
+ flag was the way to do so. Currently, we always allow binary
patch application, so this is a no-op.
--exclude=<path-pattern>::
--source=<tree-ish>::
Check attributes against the specified tree-ish. It is common to
- specify the source tree by naming a commit, branch or tag associated
+ specify the source tree by naming a commit, branch, or tag associated
with it.
\--::
<path> is the path of a file being queried, <attribute> is an attribute
-being queried and <info> can be either:
+being queried, and <info> can be either:
'unspecified';; when the attribute is not defined for the path.
'unset';; when the attribute is defined as false.
Note: --stage=all automatically implies --temp.
--temp::
- Instead of copying the files to the working directory
+ Instead of copying the files to the working directory,
write the content to temporary files. The temporary name
associations will be written to stdout.
-2 --ours::
-3 --theirs::
-0::
- Diff against the "base" version, "our branch" or "their
+ Diff against the "base" version, "our branch", or "their
branch" respectively. With these options, diffs for
merged entries are not shown.
+
-c::
--cc::
This compares stage 2 (our branch), stage 3 (their
- branch) and the working tree file and outputs a combined
+ branch), and the working tree file and outputs a combined
diff, similar to the way 'diff-tree' shows a merge
commit with these flags.
accuracy and completeness of the import by comparing each Git
commit to the corresponding source revision.
-Coming from a system such as Perforce or Subversion this should be
+Coming from a system such as Perforce or Subversion, this should be
quite simple, as the fast-import mark can also be the Perforce changeset
number or the Subversion revision number.
By default, the fsmonitor daemon refuses to work with network-mounted
repositories; this may be overridden by setting `fsmonitor.allowRemote` to
`true`. Note, however, that the fsmonitor daemon is not guaranteed to work
-correctly with all network-mounted repositories and such use is considered
+correctly with all network-mounted repositories, so such use is considered
experimental.
On Mac OS, the inter-process communication (IPC) between various Git
By default, the socket is created in the `.git` directory. However, if the
`.git` directory is on a network-mounted filesystem, it will instead be
created at `$HOME/.git-fsmonitor-*` unless `$HOME` itself is on a
-network-mounted filesystem in which case you must set the configuration
+network-mounted filesystem, in which case you must set the configuration
variable `fsmonitor.socketDir` to the path of a directory on a Mac OS native
filesystem in which to create the socket file.
aliases.
--verbose::
- When used with `--all` print description for all recognized
+ When used with `--all`, print description for all recognized
commands. This is the default.
-c::
* "info" corresponds to '-i|--info',
* "web" or "html" correspond to '-w|--web'.
-help.browser, web.browser and browser.<tool>.path
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+help.browser, web.browser, and browser.<tool>.path
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The `help.browser`, `web.browser` and `browser.<tool>.path` will also
be checked if the 'web' format is chosen (either by command-line
-d::
-D::
Remove <ref> from remote repository. The specified branch
- cannot be the remote HEAD. If -d is specified the following
+ cannot be the remote HEAD. If -d is specified, the following
other conditions must also be met:
- Remote HEAD must resolve to an object that exists locally
the merge base between 'A' and 'B' is '1'.
-Given three commits 'A', 'B' and 'C', `git merge-base A B C` will compute the
+Given three commits 'A', 'B', and 'C', `git merge-base A B C` will compute the
merge base between 'A' and a hypothetical commit 'M', which is a merge
between 'B' and 'C'. For example, with this topology:
$ git rebase --onto origin/master $fork_point topic
-will replay D0, D1 and D on top of B to create a new history of this
+will replay D0, D1, and D on top of B to create a new history of this
shape:
....
+
When 'git mergetool' is invoked with this tool (either through the
`-t` or `--tool` option or the `merge.tool` configuration
-variable) the configured command line will be invoked with `$BASE`
+variable), the configured command line will be invoked with `$BASE`
set to the name of a temporary file containing the common base for
the merge, if available; `$LOCAL` set to the name of a temporary
file containing the contents of the file on the current branch;
-g::
--gui::
- When 'git-mergetool' is invoked with the `-g` or `--gui` option
+ When 'git-mergetool' is invoked with the `-g` or `--gui` option,
the default merge tool will be read from the configured
`merge.guitool` variable instead of `merge.tool`. If
`merge.guitool` is not set, we will fallback to the tool
DESCRIPTION
-----------
-Move or rename a file, directory or symlink.
+Move or rename a file, directory, or symlink.
git mv [-v] [-f] [-n] [-k] <source> <destination>
git mv [-v] [-f] [-n] [-k] <source> ... <destination directory>
--refs=<pattern>::
Only use refs whose names match a given shell pattern. The pattern
- can be one of branch name, tag name or fully qualified ref name. If
+ can be a branch name, a tag name, or a fully qualified ref name. If
given multiple times, use refs whose names match any of the given shell
patterns. Use `--no-refs` to clear any previous ref patterns given.
-----------
This helper uses specified file descriptors to connect to a remote Git server.
This is not meant for end users but for programs and scripts calling git
-fetch, push or archive.
+fetch, push, or archive.
If only <infd> is given, it is assumed to be a bidirectional socket connected
-to remote Git server (git-upload-pack, git-receive-pack or
+to a remote Git server (git-upload-pack, git-receive-pack, or
git-upload-archive). If both <infd> and <outfd> are given, they are assumed
to be pipes connected to a remote Git server (<infd> being the inbound pipe
and <outfd> being the outbound pipe.
Generate a request asking your upstream project to pull changes into
their tree. The request, printed to the standard output,
begins with the branch description, summarizes
-the changes and indicates from where they can be pulled.
+the changes, and indicates from where they can be pulled.
The upstream project is expected to have the commit named by
`<start>` and the output asks it to integrate the changes you made
default to color output.
Same as `--color=never`.
-Note that --more, --list, --independent and --merge-base options
+Note that --more, --list, --independent, and --merge-base options
are mutually exclusive.
a `-` sign. Each commit shows a short name that
can be used as an extended SHA-1 to name that commit.
-The following example shows three branches, "master", "fixes"
+The following example shows three branches, "master", "fixes",
and "mhf":
------------------------------------------------
--index-version <n>::
Write the resulting index out in the named on-disk format version.
- Supported versions are 2, 3 and 4. The current default version is 2
+ Supported versions are 2, 3, and 4. The current default version is 2
or 3, depending on whether extra features are used, such as
`git add -N`. With `--verbose`, also report the version the index
file uses before and after this command.
* -B/60 (the same as above, since diffcore-break defaults to 50%).
Note that earlier implementation left a broken pair as separate
-creation and deletion patches. This was an unnecessary hack and
+creation and deletion patches. This was an unnecessary hack, and
the latest implementation always merges all the broken pairs
back into modifications, but the resulting patch output is
formatted differently for easier review in case of such
regular expression. This means that it will detect in-file (or what
rename-detection considers the same file) moves, which is noise. The
implementation runs diff twice and greps, and this can be quite
-expensive. To speed things up binary files without textconv filters
+expensive. To speed things up, binary files without textconv filters
will be ignored.
When `-S` or `-G` are used without `--pickaxe-all`, only filepairs
-----------
The Git pack format is how Git stores most of its primary repository
-data. Over the lifetime of a repository loose objects (if any) and
+data. Over the lifetime of a repository, loose objects (if any) and
smaller packs are consolidated into larger pack(s). See
linkgit:git-gc[1] and linkgit:git-pack-objects[1].
For example, the `fsmonitor--daemon` feature will be built as a server
application on top of the IPC-server library routines. It will have
threads watching for file system events and a thread pool waiting for
-client connections. Clients, such as `git status` will request a list
+client connections. Clients, such as `git status`, will request a list
of file system events since a point in time and the server will
respond with a list of changed files and directories. The formats of
the request and response are application-specific; the IPC-client and
The Simple-IPC mechanism differs from the existing `sub-process.c`
model (Documentation/technical/long-running-process-protocol.txt) and
-used by applications like Git-LFS. In the LFS-style sub-process model
+used by applications like Git-LFS. In the LFS-style sub-process model,
the helper is started by the foreground process, communication happens
via a pair of file descriptors bound to the stdin/stdout of the
sub-process, the sub-process only serves the current foreground
footer
....
-In a log-only file the first log block immediately follows the file
+In a log-only file, the first log block immediately follows the file
header, without padding to block alignment.
Block size
projects / rit / commitdiff