Again, we do not usually process release notes with AsciiDoc, but it
is better to be consistent.
This incidentally reveals breakages left by an ancient
5e00439f
(Documentation: build html for all files in technical and howto,
2012-10-23). The index-format documentation was originally written
to be read as straight text without formatting and when the commit
forced everything in Documentation/ to go through AsciiDoc, it did
not do any adjustment--hence the double-dashes will be seen in the
resulting text that is rendered as preformatted fixed-width without
converted into em-dashes.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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
* 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.
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).
* 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
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>`.
+
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), ...