Merge branch 'jc/em-dash-in-doc'
AsciiDoc markup fixes. * jc/em-dash-in-doc: Documentation: AsciiDoc spells em-dash as double-dashes, not triple
This commit is contained in:
commit
73167677c0
@ -84,7 +84,7 @@ Updates since v1.7.6
|
||||
logic used by "git diff" to determine the hunk header.
|
||||
|
||||
* Invoking the low-level "git http-fetch" without "-a" option (which
|
||||
git itself never did---normal users should not have to worry about
|
||||
git itself never did--normal users should not have to worry about
|
||||
this) is now deprecated.
|
||||
|
||||
* The "--decorate" option to "git log" and its family learned to
|
||||
|
@ -177,7 +177,7 @@ Performance, Internal Implementation, etc.
|
||||
* The naming convention of the packfiles has been updated; it used to
|
||||
be based on the enumeration of names of the objects that are
|
||||
contained in the pack, but now it also depends on how the packed
|
||||
result is represented---packing the same set of objects using
|
||||
result is represented--packing the same set of objects using
|
||||
different settings (or delta order) would produce a pack with
|
||||
different name.
|
||||
|
||||
|
@ -335,7 +335,7 @@ cannot be tested. If the script exits with this code, the current
|
||||
revision will be skipped (see `git bisect skip` above). 125 was chosen
|
||||
as the highest sensible value to use for this purpose, because 126 and 127
|
||||
are used by POSIX shells to signal specific error status (127 is for
|
||||
command not found, 126 is for command found but not executable---these
|
||||
command not found, 126 is for command found but not executable--these
|
||||
details do not matter, as they are normal errors in the script, as far as
|
||||
`bisect run` is concerned).
|
||||
|
||||
|
@ -71,7 +71,7 @@ This configuration is used in two ways:
|
||||
* When `git fetch` is run without specifying what branches
|
||||
and/or tags to fetch on the command line, e.g. `git fetch origin`
|
||||
or `git fetch`, `remote.<repository>.fetch` values are used as
|
||||
the refspecs---they specify which refs to fetch and which local refs
|
||||
the refspecs--they specify which refs to fetch and which local refs
|
||||
to update. The example above will fetch
|
||||
all branches that exist in the `origin` (i.e. any ref that matches
|
||||
the left-hand side of the value, `refs/heads/*`) and update the
|
||||
|
@ -62,7 +62,7 @@ be named.
|
||||
If `git push [<repository>]` without any `<refspec>` argument is set to
|
||||
update some ref at the destination with `<src>` with
|
||||
`remote.<repository>.push` configuration variable, `:<dst>` part can
|
||||
be omitted---such a push will update a ref that `<src>` normally updates
|
||||
be omitted--such a push will update a ref that `<src>` normally updates
|
||||
without any `<refspec>` on the command line. Otherwise, missing
|
||||
`:<dst>` means to update the same ref as the `<src>`.
|
||||
+
|
||||
|
@ -170,7 +170,7 @@ Git index format
|
||||
|
||||
The entries are written out in the top-down, depth-first order. The
|
||||
first entry represents the root level of the repository, followed by the
|
||||
first subtree---let's call this A---of the root level (with its name
|
||||
first subtree--let's call this A--of the root level (with its name
|
||||
relative to the root level), followed by the first subtree of A (with
|
||||
its name relative to A), ...
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user