@ -381,7 +381,7 @@ false), while all other repositories are assumed to be bare (bare
@@ -381,7 +381,7 @@ false), while all other repositories are assumed to be bare (bare
core.worktree::
Set the path to the root of the working tree.
This can be overridden by the GIT_WORK_TREE environment
variable and the '--work-tree' command line option.
variable and the '--work-tree' command-line option.
The value can be an absolute path or relative to the path to
the .git directory, which is either specified by --git-dir
@ -256,7 +256,7 @@ All writing options will per default write to the repository specific
@@ -256,7 +256,7 @@ 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*.
You can override these rules either by command line options or by environment
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
to the global or system-wide file respectively. The GIT_CONFIG environment
variable has a similar effect, but you can specify any filename you want.
@ -169,7 +169,7 @@ Git configuration files in that directory are readable by `<user>`.
@@ -169,7 +169,7 @@ Git configuration files in that directory are readable by `<user>`.
--forbid-override=<service>::
Allow/forbid overriding the site-wide default with per
repository configuration. By default, all the services
are overridable.
may be overridden.
--[no-]informative-errors::
When informative errors are turned on, git-daemon will report
@ -184,7 +184,7 @@ Git configuration files in that directory are readable by `<user>`.
@@ -184,7 +184,7 @@ Git configuration files in that directory are readable by `<user>`.
Every time a client connects, first run an external command
specified by the <path> with service name (e.g. "upload-pack"),
path to the repository, hostname (%H), canonical hostname
(%CH), ip address (%IP), and tcp port (%P) as its command line
(%CH), IP address (%IP), and TCP port (%P) as its command-line
arguments. The external command can decide to decline the
service by exiting with a non-zero status (or to allow it by
exiting with a zero status). It can also look at the $REMOTE_ADDR
@ -231,7 +231,7 @@ Date Formats
@@ -231,7 +231,7 @@ Date Formats
~~~~~~~~~~~~
The following date formats are supported. A frontend should select
the format it will use for this import by passing the format name
in the \--date-format=<fmt> command line option.
in the \--date-format=<fmt> command-line option.
`raw`::
This is the Git native format and is `<time> SP <offutc>`.
@ -348,7 +348,7 @@ and control the current import process. More detailed discussion
@@ -348,7 +348,7 @@ and control the current import process. More detailed discussion
`done`::
Marks the end of the stream. This command is optional
unless the `done` feature was requested using the
`--done` command line option or `feature done` command.
`--done` command-line option or `feature done` command.
`cat-blob`::
Causes fast-import to print a blob in 'cat-file --batch'
@ -437,7 +437,7 @@ the email address from the other fields in the line. Note that
@@ -437,7 +437,7 @@ the email address from the other fields in the line. Note that
of bytes, except `LT`, `GT` and `LF`. `<name>` is typically UTF-8 encoded.
The time of the change is specified by `<when>` using the date format
that was selected by the \--date-format=<fmt> command line option.
that was selected by the \--date-format=<fmt> command-line option.
See ``Date Formats'' above for the set of supported formats, and
their syntax.
@ -1085,7 +1085,7 @@ Option commands must be the first commands on the input (not counting
@@ -1085,7 +1085,7 @@ 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
The following command-line options change import semantics and may therefore
not be passed as option:
* date-format
@ -1099,7 +1099,7 @@ not be passed as option:
@@ -1099,7 +1099,7 @@ not be passed as option:
If the `done` feature is not in use, treated as if EOF was read.
This can be used to tell fast-import to finish early.
If the `--done` command line option or `feature done` command is
If the `--done` command-line option or `feature done` command is
in use, the `done` command is mandatory and marks the end of the
@ -283,7 +283,7 @@ merge. The different stages represent the "result tree" (stage 0, aka
@@ -283,7 +283,7 @@ merge. The different stages represent the "result tree" (stage 0, aka
you are trying to merge (stage 2 and 3 respectively).
The order of stages 1, 2 and 3 (hence the order of three
<tree-ish> command line arguments) are significant when you
<tree-ish> command-line arguments) are significant when you
start a 3-way merge with an index file that is already
populated. Here is an outline of how the algorithm works:
@ -20,7 +20,7 @@ files in the directory), or directly as a revision list. In the
@@ -20,7 +20,7 @@ files in the directory), or directly as a revision list. In the
last case, any format accepted by linkgit:git-format-patch[1] can
be passed to git send-email.
The header of the email is configurable by command line options. If not
The header of the email is configurable via command-line options. If not
specified on the command line, the user will be prompted with a ReadLine
enabled interface to provide the necessary information.
@ -68,7 +68,7 @@ The --cc option must be repeated for each user you want on the cc list.
@@ -68,7 +68,7 @@ The --cc option must be repeated for each user you want on the cc list.
When '--compose' is used, git send-email will use the From, Subject, and
In-Reply-To headers specified in the message. If the body of the message
(what you type after the headers and a blank line) only contains blank
(or Git: prefixed) lines the summary won't be sent, but From, Subject,
(or Git: prefixed) lines, the summary won't be sent, but From, Subject,
and In-Reply-To headers will be used unless they are removed.
+
Missing From or In-Reply-To headers will be prompted for.
@ -78,7 +78,7 @@ See the CONFIGURATION section for 'sendemail.multiedit'.
@@ -78,7 +78,7 @@ See the CONFIGURATION section for 'sendemail.multiedit'.
--from=<address>::
Specify the sender of the emails. If not specified on the command line,
the value of the 'sendemail.from' configuration option is used. If
neither the command line option nor 'sendemail.from' are set, then the
neither the command-line option nor 'sendemail.from' are set, then the
user will be prompted for the value. The default for the prompt will be
the value of GIT_AUTHOR_IDENT, or GIT_COMMITTER_IDENT if that is not
gitcli - Git command line interface and conventions
gitcli - Git command-line interface and conventions
SYNOPSIS
--------
@ -66,13 +66,13 @@ you will.
@@ -66,13 +66,13 @@ you will.
Here are the rules regarding the "flags" that you should follow when you are
scripting Git:
* it's preferred to use the non dashed form of Git commands, which means that
* it's preferred to use the non-dashed form of Git commands, which means that
you should prefer `git foo` to `git-foo`.
* splitting short options to separate words (prefer `git foo -a -b`
to `git foo -ab`, the latter may not even work).
* when a command line option takes an argument, use the 'stuck' form. In
* when a command-line option takes an argument, use the 'stuck' form. In
other words, write `git foo -oArg` instead of `git foo -o Arg` for short
options, and `git foo --long-opt=Arg` instead of `git foo --long-opt Arg`
for long options. An option that takes optional option-argument must be
@ -103,7 +103,7 @@ Here is a list of the facilities provided by this option parser.
@@ -103,7 +103,7 @@ Here is a list of the facilities provided by this option parser.
Magic Options
~~~~~~~~~~~~~
Commands which have the enhanced option parser activated all understand a
@ -4231,9 +4231,9 @@ Most of what `git rev-list` did is contained in `revision.c` and
@@ -4231,9 +4231,9 @@ Most of what `git rev-list` did is contained in `revision.c` and
controls how and what revisions are walked, and more.
The original job of `git rev-parse` is now taken by the function
`setup_revisions()`, which parses the revisions and the common command line
`setup_revisions()`, which parses the revisions and the common command-line
options for the revision walker. This information is stored in the struct
`rev_info` for later consumption. You can do your own command line option
`rev_info` for later consumption. You can do your own command-line option
parsing after calling `setup_revisions()`. After that, you have to call
`prepare_revision_walk()` for initialization, and then you can get the
commits one by one with the function `get_revision()`.