summaryrefslogtreecommitdiff
path: root/Documentation
AgeCommit message (Collapse)AuthorFilesLines
2015-08-19submodule: use new config API for worktree configurationsLibravatar Heiko Voigt1-1/+18
We remove the extracted functions and directly parse into and read out of the cache. This allows us to have one unified way of accessing submodule configuration values specific to single submodules. Regardless whether we need to access a configuration from history or from the worktree. Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-08-19submodule: implement a config API for lookup of .gitmodules valuesLibravatar Heiko Voigt1-0/+45
In a superproject some commands need to interact with submodules. They need to query values from the .gitmodules file either from the worktree of from certain revisions. At the moment this is quite hard since a caller would need to read the .gitmodules file from the history and then parse the values. We want to provide an API for this so we have one place to get values from .gitmodules from any revision (including the worktree). The API is realized as a cache which allows us to lazily read .gitmodules configurations by commit into a runtime cache which can then be used to easily lookup values from it. Currently only the values for path or name are stored but it can be extended for any value needed. It is expected that .gitmodules files do not change often between commits. Thats why we lookup the .gitmodules sha1 from a commit and then either lookup an already parsed configuration or parse and cache an unknown one for each sha1. The cache is lazily build on demand for each requested commit. This cache can be used for all purposes which need knowledge about submodule configurations. Example use cases are: * Recursive submodule checkout needs to lookup a submodule name from its path when a submodule first appears. This needs be done before this configuration exists in the worktree. * The implementation of submodule support for 'git archive' needs to lookup the submodule name to generate the archive when given a revision that is not checked out. * 'git fetch' when given the --recurse-submodules=on-demand option (or configuration) needs to lookup submodule names by path from the database rather than reading from the worktree. For new submodule it needs to lookup the name from its path to allow cloning new submodules into the .git folder so they can be checked out without any network interaction when the user does a checkout of that revision. Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-01Sixth batch for 2.5 cycleLibravatar Junio C Hamano1-1/+50
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-06-01Merge branch 'fm/fetch-raw-sha1'Libravatar Junio C Hamano3-3/+17
"git upload-pack" that serves "git fetch" can be told to serve commits that are not at the tip of any ref, as long as they are reachable from a ref, with uploadpack.allowReachableSHA1InWant configuration variable. * fm/fetch-raw-sha1: upload-pack: optionally allow fetching reachable sha1 upload-pack: prepare to extend allow-tip-sha1-in-want config.txt: clarify allowTipSHA1InWant with camelCase
2015-06-01Merge branch 'sg/help-group'Libravatar Junio C Hamano2-1/+7
Group list of commands shown by "git help" along the workflow elements to help early learners. * sg/help-group: help: respect new common command grouping command-list.txt: drop the "common" tag generate-cmdlist: parse common group commands command-list.txt: add the common groups block command-list: prepare machinery for upcoming "common groups" section
2015-06-01Merge branch 'mm/log-format-raw-doc'Libravatar Junio C Hamano2-2/+14
Clarify that "log --raw" and "log --format=raw" are unrelated concepts. * mm/log-format-raw-doc: Documentation/log: clarify sha1 non-abbreviation in log --raw Documentation/log: clarify what --raw means
2015-06-01Merge branch 'dt/cat-file-follow-symlinks'Libravatar Junio C Hamano1-1/+98
"git cat-file --batch(-check)" learned the "--follow-symlinks" option that follows an in-tree symbolic link when asked about an object via extended SHA-1 syntax, e.g. HEAD:RelNotes that points at Documentation/RelNotes/2.5.0.txt. With the new option, the command behaves as if HEAD:Documentation/RelNotes/2.5.0.txt was given as input instead. * dt/cat-file-follow-symlinks: cat-file: add --follow-symlinks to --batch sha1_name: get_sha1_with_context learns to follow symlinks tree-walk: learn get_tree_entry_follow_symlinks
2015-06-01Merge branch 'mc/commit-doc-grammofix'Libravatar Junio C Hamano1-1/+1
Doc grammar fix. * mc/commit-doc-grammofix: Documentation/git-commit: grammofix
2015-06-01Merge branch 'jk/http-backend-deadlock'Libravatar Junio C Hamano1-0/+9
Communication between the HTTP server and http_backend process can lead to a dead-lock when relaying a large ref negotiation request. Diagnose the situation better, and mitigate it by reading such a request first into core (to a reasonable limit). * jk/http-backend-deadlock: http-backend: spool ref negotiation requests to buffer t5551: factor out tag creation http-backend: fix die recursion with custom handler
2015-05-26Sync with 2.4.2Libravatar Junio C Hamano2-1/+47
2015-05-26Git 2.4.2Libravatar Junio C Hamano2-1/+47
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-26Merge branch 'jc/hash-object' into maintLibravatar Junio C Hamano1-2/+8
"hash-object --literally" introduced in v2.2 was not prepared to take a really long object type name. * jc/hash-object: write_sha1_file(): do not use a separate sha1[] array t1007: add hash-object --literally tests hash-object --literally: fix buffer overrun with extra-long object type git-hash-object.txt: document --literally option
2015-05-26Fifth batch for 2.5 cycleLibravatar Junio C Hamano1-6/+28
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-26Merge branch 'nd/untracked-cache'Libravatar Junio C Hamano3-1/+80
Teach the index to optionally remember already seen untracked files to speed up "git status" in a working tree with tons of cruft. * nd/untracked-cache: (24 commits) git-status.txt: advertisement for untracked cache untracked cache: guard and disable on system changes mingw32: add uname() t7063: tests for untracked cache update-index: test the system before enabling untracked cache update-index: manually enable or disable untracked cache status: enable untracked cache untracked-cache: temporarily disable with $GIT_DISABLE_UNTRACKED_CACHE untracked cache: mark index dirty if untracked cache is updated untracked cache: print stats with $GIT_TRACE_UNTRACKED_STATS untracked cache: avoid racy timestamps read-cache.c: split racy stat test to a separate function untracked cache: invalidate at index addition or removal untracked cache: load from UNTR index extension untracked cache: save to an index extension ewah: add convenient wrapper ewah_serialize_strbuf() untracked cache: don't open non-existent .gitignore untracked cache: mark what dirs should be recursed/saved untracked cache: record/validate dir mtime and reuse cached output untracked cache: make a wrapper around {open,read,close}dir() ...
2015-05-26Merge branch 'pt/pull-ff-vs-merge-ff'Libravatar Junio C Hamano1-1/+1
The pull.ff configuration was supposed to override the merge.ff configuration, but it didn't. * pt/pull-ff-vs-merge-ff: pull: parse pull.ff as a bool or string pull: make pull.ff=true override merge.ff
2015-05-25Merge branch 'jk/http-backend-deadlock-2.3' into jk/http-backend-deadlockLibravatar Junio C Hamano1-0/+9
* jk/http-backend-deadlock-2.3: http-backend: spool ref negotiation requests to buffer t5551: factor out tag creation http-backend: fix die recursion with custom handler
2015-05-25Merge branch 'jk/http-backend-deadlock-2.2' into jk/http-backend-deadlock-2.3Libravatar Junio C Hamano1-0/+9
* jk/http-backend-deadlock-2.2: http-backend: spool ref negotiation requests to buffer t5551: factor out tag creation http-backend: fix die recursion with custom handler
2015-05-25http-backend: spool ref negotiation requests to bufferLibravatar Jeff King1-0/+9
When http-backend spawns "upload-pack" to do ref negotiation, it streams the http request body to upload-pack, who then streams the http response back to the client as it reads. In theory, git can go full-duplex; the client can consume our response while it is still sending the request. In practice, however, HTTP is a half-duplex protocol. Even if our client is ready to read and write simultaneously, we may have other HTTP infrastructure in the way, including the webserver that spawns our CGI, or any intermediate proxies. In at least one documented case[1], this leads to deadlock when trying a fetch over http. What happens is basically: 1. Apache proxies the request to the CGI, http-backend. 2. http-backend gzip-inflates the data and sends the result to upload-pack. 3. upload-pack acts on the data and generates output over the pipe back to Apache. Apache isn't reading because it's busy writing (step 1). This works fine most of the time, because the upload-pack output ends up in a system pipe buffer, and Apache reads it as soon as it finishes writing. But if both the request and the response exceed the system pipe buffer size, then we deadlock (Apache blocks writing to http-backend, http-backend blocks writing to upload-pack, and upload-pack blocks writing to Apache). We need to break the deadlock by spooling either the input or the output. In this case, it's ideal to spool the input, because Apache does not start reading either stdout _or_ stderr until we have consumed all of the input. So until we do so, we cannot even get an error message out to the client. The solution is fairly straight-forward: we read the request body into an in-memory buffer in http-backend, freeing up Apache, and then feed the data ourselves to upload-pack. But there are a few important things to note: 1. We limit the in-memory buffer to prevent an obvious denial-of-service attack. This is a new hard limit on requests, but it's unlikely to come into play. The default value is 10MB, which covers even the ridiculous 100,000-ref negotation in the included test (that actually caps out just over 5MB). But it's configurable on the off chance that you don't mind spending some extra memory to make even ridiculous requests work. 2. We must take care only to buffer when we have to. For pushes, the incoming packfile may be of arbitrary size, and we should connect the input directly to receive-pack. There's no deadlock problem here, though, because we do not produce any output until the whole packfile has been read. For upload-pack's initial ref advertisement, we similarly do not need to buffer. Even though we may generate a lot of output, there is no request body at all (i.e., it is a GET, not a POST). [1] http://article.gmane.org/gmane.comp.version-control.git/269020 Test-adapted-from: Dennis Kaarsemaker <dennis@kaarsemaker.net> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-22upload-pack: optionally allow fetching reachable sha1Libravatar Fredrik Medley3-1/+15
With uploadpack.allowReachableSHA1InWant configuration option set on the server side, "git fetch" can make a request with a "want" line that names an object that has not been advertised (likely to have been obtained out of band or from a submodule pointer). Only objects reachable from the branch tips, i.e. the union of advertised branches and branches hidden by transfer.hideRefs, will be processed. Note that there is an associated cost of having to walk back the history to check the reachability. This feature can be used when obtaining the content of a certain commit, for which the sha1 is known, without the need of cloning the whole repository, especially if a shallow fetch is used. Useful cases are e.g. repositories containing large files in the history, fetching only the needed data for a submodule checkout, when sharing a sha1 without telling which exact branch it belongs to and in Gerrit, if you think in terms of commits instead of change numbers. (The Gerrit case has already been solved through allowTipSHA1InWant as every Gerrit change has a ref.) Signed-off-by: Fredrik Medley <fredrik.medley@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-22Fourth batch for 2.5 cycleLibravatar Junio C Hamano1-0/+75
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-22Merge branch 'ps/doc-packfile-vs-pack-file'Libravatar Junio C Hamano3-9/+9
Doc consistency updates. * ps/doc-packfile-vs-pack-file: doc: fix inconsistent spelling of "packfile" pack-protocol.txt: fix insconsistent spelling of "packfile" git-unpack-objects.txt: fix inconsistent spelling of "packfile" git-verify-pack.txt: fix inconsistent spelling of "packfile"
2015-05-22Merge branch 'mh/lockfile-retry'Libravatar Junio C Hamano1-0/+6
Instead of dying immediately upon failing to obtain a lock, retry after a short while with backoff. * mh/lockfile-retry: lock_packed_refs(): allow retries when acquiring the packed-refs lock lockfile: allow file locking to be retried with a timeout
2015-05-22Merge branch 'jk/asciidoc-markup-fix'Libravatar Junio C Hamano19-102/+107
Various documentation mark-up fixes to make the output more consistent in general and also make AsciiDoctor (an alternative formatter) happier. * jk/asciidoc-markup-fix: doc: convert AsciiDoc {?foo} to ifdef::foo[] doc: put example URLs and emails inside literal backticks doc: drop backslash quoting of some curly braces doc: convert \--option to --option doc/add: reformat `--edit` option doc: fix length of underlined section-title doc: fix hanging "+"-continuation doc: fix unquoted use of "{type}" doc: fix misrendering due to `single quote'
2015-05-22Merge branch 'jk/stripspace-asciidoctor-fix'Libravatar Junio C Hamano1-3/+3
A literal block in the tutorial had lines with unequal lengths to delimit it from the rest of the document, which choke GitHub's AsciiDoc renderer. * jk/stripspace-asciidoctor-fix: doc: fix unmatched code fences in git-stripspace
2015-05-22Merge branch 'ja/tutorial-asciidoctor-fix'Libravatar Junio C Hamano1-1/+1
A literal block in the tutorial had lines with unequal lengths to delimit it from the rest of the document, which choke GitHub's AsciiDoc renderer. * ja/tutorial-asciidoctor-fix: doc: fix unmatched code fences
2015-05-22Merge branch 'ls/http-ssl-cipher-list'Libravatar Junio C Hamano1-0/+13
Introduce http.<url>.SSLCipherList configuration variable to tweak the list of cipher suite to be used with libcURL when talking with https:// sites. * ls/http-ssl-cipher-list: http: add support for specifying an SSL cipher list
2015-05-22doc: fix inconsistent spelling of "packfile"Libravatar Patrick Steinhardt2-3/+3
Fix remaining instances where "pack-file" is used instead of "packfile". Some places remain where we still use "pack-file", This is the case when we explicitly refer to a file with a ".pack" extension as opposed to a data source providing a pack data stream. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-21config.txt: clarify allowTipSHA1InWant with camelCaseLibravatar Fredrik Medley1-2/+2
Most of the options in config.txt are camelCase. Improve the readability for allowtipsha1inwant by changing to allowTipSHA1InWant. Signed-off-by: Fredrik Medley <fredrik.medley@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-21command-list.txt: add the common groups blockLibravatar Sébastien Guimmara1-1/+3
The ultimate goal is for "git help" to display common commands in groups rather than alphabetically. As a first step, define the groups in a new block, and then assign a group to each common command. Add a block at the beginning of command-list.txt: init start a working area (see also: git help tutorial) worktree work on the current change (see also:[...] info examine the history and state (see also: git [...] history grow, mark and tweak your history remote collaborate (see also: git help workflows) storing information about common commands group, then map each common command to a group: git-add mainporcelain common worktree Helped-by: Eric Sunshine <sunshine@sunshineco.com> Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Emma Jane Hogbin Westby <emma.westby@gmail.com> Signed-off-by: Sébastien Guimmara <sebastien.guimmara@gmail.com> Reviewed-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-21command-list: prepare machinery for upcoming "common groups" sectionLibravatar Eric Sunshine1-0/+4
The ultimate goal is for "git help" to classify common commands by group. Toward this end, a subsequent patch will add a new "common groups" section to command-list.txt preceding the actual command list. As preparation, teach existing command-list.txt parsing machinery, which doesn't care about grouping, to skip over this upcoming "common groups" section. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Sébastien Guimmara <sebastien.guimmara@gmail.com> Reviewed-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-20Documentation/log: clarify sha1 non-abbreviation in log --rawLibravatar Matthieu Moy1-1/+4
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-20cat-file: add --follow-symlinks to --batchLibravatar David Turner1-1/+98
This wires the in-repo-symlink following code through to the cat-file builtin. In the event of an out-of-repo link, cat-file will print the link in a new format. Signed-off-by: David Turner <dturner@twopensource.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-19Documentation/git-commit: grammofixLibravatar Michael Coleman1-1/+1
Signed-off-by: Michael Coleman <michael.karl.coleman@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-19Third batch for 2.5 cycleLibravatar Junio C Hamano1-0/+81
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-19Merge branch 'kn/cat-file-literally'Libravatar Junio C Hamano1-1/+4
Add the "--allow-unknown-type" option to "cat-file" to allow inspecting loose objects of an experimental or a broken type. * kn/cat-file-literally: t1006: add tests for git cat-file --allow-unknown-type cat-file: teach cat-file a '--allow-unknown-type' option cat-file: make the options mutually exclusive sha1_file: support reading from a loose object of unknown type
2015-05-19Merge branch 'jc/merge'Libravatar Junio C Hamano1-0/+4
"git merge FETCH_HEAD" learned that the previous "git fetch" could be to create an Octopus merge, i.e. recording multiple branches that are not marked as "not-for-merge"; this allows us to lose an old style invocation "git merge <msg> HEAD $commits..." in the implementation of "git pull" script; the old style syntax can now be deprecated. * jc/merge: merge: deprecate 'git merge <message> HEAD <commit>' syntax merge: handle FETCH_HEAD internally merge: decide if we auto-generate the message early in collect_parents() merge: make collect_parents() auto-generate the merge message merge: extract prepare_merge_message() logic out merge: narrow scope of merge_names merge: split reduce_parents() out of collect_parents() merge: clarify collect_parents() logic merge: small leakfix and code simplification merge: do not check argc to determine number of remote heads merge: clarify "pulling into void" special case t5520: test pulling an octopus into an unborn branch t5520: style fixes merge: simplify code flow merge: test the top-level merge driver
2015-05-19Merge branch 'fg/document-commit-message-stripping'Libravatar Junio C Hamano1-4/+7
* fg/document-commit-message-stripping: Documentation: clarify how "git commit" cleans up the edited log message
2015-05-18Documentation/log: clarify what --raw meansLibravatar Matthieu Moy1-1/+10
There are several "raw formats", and describing --raw as "Generate the raw format" in the documentation for git-log seems to imply that it generates the raw *log* format. Clarify the wording by saying "raw diff format" explicitly, and make a special-case for "git log": "git log --raw" does not just change the format, it shows something which is not shown by default. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-18pull: make pull.ff=true override merge.ffLibravatar Paul Tan1-1/+1
Since b814da8 (pull: add pull.ff configuration, 2014-01-15), running git-pull with the configuration pull.ff=false or pull.ff=only is equivalent to passing --no-ff and --ff-only to git-merge. However, if pull.ff=true, no switch is passed to git-merge. This leads to the confusing behavior where pull.ff=false or pull.ff=only is able to override merge.ff, while pull.ff=true is unable to. Fix this by adding the --ff switch if pull.ff=true, and add a test to catch future regressions. Furthermore, clarify in the documentation that pull.ff overrides merge.ff. Signed-off-by: Paul Tan <pyokagan@gmail.com> Reviewed-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-17pack-protocol.txt: fix insconsistent spelling of "packfile"Libravatar Patrick Steinhardt1-3/+3
Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-17git-unpack-objects.txt: fix inconsistent spelling of "packfile"Libravatar Patrick Steinhardt1-2/+2
Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-17git-verify-pack.txt: fix inconsistent spelling of "packfile"Libravatar Patrick Steinhardt1-1/+1
Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-14lock_packed_refs(): allow retries when acquiring the packed-refs lockLibravatar Michael Haggerty1-0/+6
Currently, there is only one attempt to acquire any lockfile, and if the lock is held by another process, the locking attempt fails immediately. This is not such a limitation for loose reference files. First, they don't take long to rewrite. Second, most reference updates have a known "old" value, so if another process is updating a reference at the same moment that we are trying to lock it, then probably the expected "old" value will not longer be valid, and the update will fail anyway. But these arguments do not hold for packed-refs: * The packed-refs file can be large and take significant time to rewrite. * Many references are stored in a single packed-refs file, so it could be that the other process was changing a different reference than the one that we are interested in. Therefore, it is much more likely for there to be spurious lock conflicts in connection to the packed-refs file, resulting in unnecessary command failures. So, if the first attempt to lock the packed-refs file fails, continue retrying for a configurable length of time before giving up. The default timeout is 1 second. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-14doc: convert AsciiDoc {?foo} to ifdef::foo[]Libravatar Jeff King1-2/+6
The former seems to just be syntactic sugar for the latter. And as it's sugar that AsciiDoctor doesn't understand, it would be nice to avoid it. Since there are only two spots, and the resulting source is not significantly harder to read, it's worth doing. Note that this does slightly affect the generated HTML (it has an extra newline), but the rendered result for both HTML and docbook should be the same (since the newline is not syntactically significant there). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-13Sync with 2.4.1Libravatar Junio C Hamano2-1/+42
* maint: Git 2.4.1
2015-05-13Git 2.4.1Libravatar Junio C Hamano2-1/+42
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-12doc: put example URLs and emails inside literal backticksLibravatar Jeff King3-5/+5
This makes sure that AsciiDoc does not turn them into links. Regular AsciiDoc does not catch these cases, but AsciiDoctor does treat them as links. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-12doc: drop backslash quoting of some curly bracesLibravatar Jeff King1-7/+7
Text like "{foo}" triggers an AsciiDoc attribute; we have to write "\{foo}" to suppress this. But when the "foo" is not a syntactically valid attribute, we can skip the quoting. This makes the source nicer to read, and looks better under Asciidoctor. With AsciiDoc itself, this patch produces no changes. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-12doc: convert \--option to --optionLibravatar Jeff King11-80/+80
Older versions of AsciiDoc would convert the "--" in "--option" into an emdash. According to 565e135 (Documentation: quote double-dash for AsciiDoc, 2011-06-29), this is fixed in AsciiDoc 8.3.0. According to bf17126, we don't support anything older than 8.4.1 anyway, so we no longer need to worry about quoting. Even though this does not change the output at all, there are a few good reasons to drop the quoting: 1. It makes the source prettier to read. 2. We don't quote consistently, which may be confusing when reading the source. 3. Asciidoctor does not like the quoting, and renders a literal backslash. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-12doc/add: reformat `--edit` optionLibravatar Jeff King1-1/+2
All of the other options in the list put short and long as two separate headings. We can also drop the backslashing of `--`. It isn't used elsewhere and is unnecessary for modern asciidoc (plus it confuses asciidoctor). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>