mirror of
https://github.com/git/git.git
synced 2025-12-12 20:36:24 +01:00
63d33eb7f6
Having an empty line before each delimited sections is not required by asciidoc, but it is a safety measure that prevents generating malformed asciidoc when generating translated documentation. When a delimited section appears just after a paragraph, the asciidoc processor checks that the length of the delimited section header is different from the length of the paragraph. If it is not, the asciidoc processor will generate a title. In the original English documentation, this is not a problem because the authors always check the output of the asciidoc processor and fix the length of the delimited section header if it turns out to be the same as the paragraph length. However, this is not the case for translations, where the authors have no way to check the length of the delimited section header or the output of the asciidoc processor. This can lead to a section title that is not intended. Indeed, this test also checks that titles are correctly formed, that is, the length of the underline is equal to the length of the title (otherwise it would not be a title but a section header). Finally, this test checks that the delimited section are terminated within the same file. Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
52 lines
1.9 KiB
Plaintext
52 lines
1.9 KiB
Plaintext
Long-running process protocol
|
|
=============================
|
|
|
|
This protocol is used when Git needs to communicate with an external
|
|
process throughout the entire life of a single Git command. All
|
|
communication is in pkt-line format (see linkgit:gitprotocol-common[5])
|
|
over standard input and standard output.
|
|
|
|
Handshake
|
|
---------
|
|
|
|
Git starts by sending a welcome message (for example,
|
|
"git-filter-client"), a list of supported protocol version numbers, and
|
|
a flush packet. Git expects to read the welcome message with "server"
|
|
instead of "client" (for example, "git-filter-server"), exactly one
|
|
protocol version number from the previously sent list, and a flush
|
|
packet. All further communication will be based on the selected version.
|
|
The remaining protocol description below documents "version=2". Please
|
|
note that "version=42" in the example below does not exist and is only
|
|
there to illustrate how the protocol would look like with more than one
|
|
version.
|
|
|
|
After the version negotiation Git sends a list of all capabilities that
|
|
it supports and a flush packet. Git expects to read a list of desired
|
|
capabilities, which must be a subset of the supported capabilities list,
|
|
and a flush packet as response:
|
|
|
|
------------------------
|
|
packet: git> git-filter-client
|
|
packet: git> version=2
|
|
packet: git> version=42
|
|
packet: git> 0000
|
|
packet: git< git-filter-server
|
|
packet: git< version=2
|
|
packet: git< 0000
|
|
packet: git> capability=clean
|
|
packet: git> capability=smudge
|
|
packet: git> capability=not-yet-invented
|
|
packet: git> 0000
|
|
packet: git< capability=clean
|
|
packet: git< capability=smudge
|
|
packet: git< 0000
|
|
------------------------
|
|
|
|
Shutdown
|
|
--------
|
|
|
|
Git will close
|
|
the command pipe on exit. The filter is expected to detect EOF
|
|
and exit gracefully on its own. Git will wait until the filter
|
|
process has stopped.
|