| Message ID | pull.1766.v3.git.1723389612.gitgitgadget@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | doc: introducing synopsis para | expand |
"Jean-Noël Avila via GitGitGadget" <gitgitgadget@gmail.com> writes: > Jean-Noël Avila (3): > doc: introduce a synopsis custom paragraph attribute > doc: update the guidelines to reflect the current formatting rules > doc: apply synopsis simplification on git-clone and git-init This topic has become quiet. I still find s:["someything you really want to say"] notation a bit annoying to my eyes, but its may be the best compromise we can come up with. So unless we have a strong objection, or (even better) an objection with an alternative that is less yucky, perhaps it is time to declare that this is the variant of AsciiDoc/Asciidoctor that we'd adopt for our documentation. Comments? Thanks.
Le lundi 19 août 2024, 22:08:19 CEST Junio C Hamano a écrit : > "Jean-Noël Avila via GitGitGadget" <gitgitgadget@gmail.com> writes: > > > Jean-Noël Avila (3): > > doc: introduce a synopsis custom paragraph attribute > > doc: update the guidelines to reflect the current formatting rules > > doc: apply synopsis simplification on git-clone and git-init > > This topic has become quiet. I still find s:["someything you really > want to say"] notation a bit annoying to my eyes, but its may be the > best compromise we can come up with. > > So unless we have a strong objection, or (even better) an objection > with an alternative that is less yucky, perhaps it is time to > declare that this is the variant of AsciiDoc/Asciidoctor that we'd > adopt for our documentation. Comments? > > Thanks. > I understand that you are reluctant to include a change that, as the maintainer, you do not feel comfortable keeping alive. The whole discussion thread tells me that other developers are not ready to go down the "full markup" path. Understandably, this makes it more difficult for everyone to propose changes and review them, as there's no tool to track such formatting errors and we have to rely on careful manual cross-checking. I would like to thank you for pushing so that the markup can be simplified as much as can be. It can be simplified further one step further: it is possible both in asciidoc/asciidoctor to override the formatting of inline verbatim texts, so that everything that is backquoted is processed as a synopsis string. This way, strings like `<commit>` `diff.statGraphWidth=<width>` ` --dirstat-by-file[=<param>,...]` are automatically rendered with the expected styles. However, contrary to the s macro, this is quite disruptive as it forces the new processing on all existing manpages. Another drawback is that it is no longer genuine asciidoc, but it seems more in line with the critics. I'm refining the regexp at the moment to check for side-effects. Is this proposition more appropriate?
Jean-Noël AVILA <jn.avila@free.fr> writes: > ... It can be simplified further one step further: it is possible > both in asciidoc/asciidoctor to override the formatting of inline verbatim > texts, so that everything that is backquoted is processed as a synopsis > string. > This way, strings like > > `<commit>` > `diff.statGraphWidth=<width>` > ` --dirstat-by-file[=<param>,...]` > > are automatically rendered with the expected styles. > > However, contrary to the s macro, this is quite disruptive as it forces the > new processing on all existing manpages. Another drawback is that it is no > longer genuine asciidoc, but it seems more in line with the critics. I'm > refining the regexp at the moment to check for side-effects. > > Is this proposition more appropriate? Thanks for thinking these things through. The fact that such a "magic" processing will hide the gory details from those whose primary interest is to describe the commands and their options cuts both ways. It is a very welcome thing for developers around here, I would assume. At the same time, I can understand that purists would find it unacceptably ugly, as `backticks` is now much more than a mark-up that means "this text is typeset in monospace". Inside it, <text inside angle brackets>, [optional text], and (choices), all signal that they have special meaning by being typeset differently. I do not personally mind that, and I would even dream about a future in which other projects notice what you did to AsciiDoctor, love it, adopt it, and eventually it feeds back to improve AsciiDoctor proper. It is very likely that is because I haven't seen any "side effects" yet ;-) Thanks.
Following several issues with the way the formatting of synopsis is done in the manpages that were recently reworked, this patch series introduces the processing of a new custom paragraph attribute 'synopsis'. Additionally, as s macro is introduce to apply the same rules freely in the text. This extension is added to asciidoc and asciidoctor and lets write the synopsis of the commands without any typeset. The git-init and git-clone manpages are converted to this new system. Changes since V1: * switch to sed for asciidoc filter and refine the regex for support under macOS Changes since V2: * introduce the s macro to freely apply synopsis styling wherever needed, without formatting hassle. Jean-Noël Avila (3): doc: introduce a synopsis custom paragraph attribute doc: update the guidelines to reflect the current formatting rules doc: apply synopsis simplification on git-clone and git-init Documentation/CodingGuidelines | 54 +++++++++--------- Documentation/asciidoc.conf | 21 ++++++- Documentation/asciidoctor-extensions.rb | 33 +++++++++++ Documentation/git-clone.txt | 76 ++++++++++++------------- Documentation/git-init.txt | 33 +++++------ Documentation/urls.txt | 26 ++++----- t/t0450-txt-doc-vs-help.sh | 11 ++-- 7 files changed, 150 insertions(+), 104 deletions(-) base-commit: ad57f148c6b5f8735b62238dda8f571c582e0e54 Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1766%2Fjnavila%2Fdoc_synopsis_para-v3 Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1766/jnavila/doc_synopsis_para-v3 Pull-Request: https://github.com/gitgitgadget/git/pull/1766 Range-diff vs v2: 1: aba144f4ff3 ! 1: 0d7c1dd8f26 doc: introduce a synopsis custom paragraph attribute @@ Commit message created and the backends of asciidoc and asciidoctor take in charge to correctly add the required typesetting. + additionally, a 's' macro ('s' standing for synopsis) is introduced to + allow writers to freely apply automatic styling whereever required. + Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> ## Documentation/asciidoc.conf ## -@@ Documentation/asciidoc.conf: git-relative-html-prefix= +@@ + + [macros] + (?su)[\\]?(?P<name>linkgit):(?P<target>\S*?)\[(?P<attrlist>.*?)\]= +- ++(?su)[\\]?(?P<name>s):(?P<target>\S*?)\["(?P<attrlist>.*?)"\]= + [attributes] + asterisk=* + plus=+ +@@ Documentation/asciidoc.conf: ifdef::backend-docbook[] + {0#<citerefentry>} + {0#<refentrytitle>{target}</refentrytitle><manvolnum>{0}</manvolnum>} + {0#</citerefentry>} ++ ++[s-inlinemacro] ++{eval:re.sub(r'(<[-a-zA-Z0-9.]+>)', r'<emphasis>\1</emphasis>', re.sub(r'([\[ |()>]|^|\]|>)(\.?[-a-zA-Z0-9:+=~@,\/]+\.?)',r'\1<literal>\2</literal>', '{attrlist}'))} + endif::backend-docbook[] + + ifdef::backend-docbook[] +@@ Documentation/asciidoc.conf: ifdef::backend-xhtml11[] + git-relative-html-prefix= [linkgit-inlinemacro] <a href="{git-relative-html-prefix}{target}.html">{target}{0?({0})}</a> - endif::backend-xhtml11[] ++ ++[s-inlinemacro] ++{eval:re.sub(r'(<[-a-zA-Z0-9.]+>)', r'<em>\1</em>', re.sub(r'([\[ |()>]|^|\]|>)(\.?[-=a-zA-Z0-9:+,@]+\.?)',r'\1<code>\2</code>', '{attrlist}'))} ++ ++endif::backend-xhtml11[] + +ifdef::backend-docbook[] +ifdef::doctype-manpage[] +[paradef-default] -+synopsis-style=template="verseparagraph",filter="sed -E 's!([\[ |()>]|^|\])([-=a-zA-Z0-9:+.]+)!\\1<literal>\\2</literal>!g;s!<[-a-zA-Z0-9.]+>!<emphasis>\\0</emphasis>!g'" ++synopsis-style=template="verseparagraph",filter="sed -E 's!([\[ |()>]|^|\])(\.?[-=a-zA-Z0-9:+@]+\.?+)!\\1<literal>\\2</literal>!g;s!<[-a-zA-Z0-9.]+>!<emphasis>\\0</emphasis>!g'" +endif::doctype-manpage[] +endif::backend-docbook[] + +ifdef::backend-xhtml11[] +[paradef-default] -+synopsis-style=template="verseparagraph",filter="sed -E 's!([\[ |()>]|^|\])([-=a-zA-Z0-9:+.]+)!\\1<code>\\2</code>!g;s!<[-a-zA-Z0-9.]+>!<em>\\0</em>!g'" -+endif::backend-xhtml11[] ++synopsis-style=template="verseparagraph",filter="sed -E 's!([\[ |()>]|^|\])(\.?[-=a-zA-Z0-9:+@]+\.?)!\\1<code>\\2</code>!g;s!<[-a-zA-Z0-9.]+>!<em>\\0</em>!g'" + endif::backend-xhtml11[] ## Documentation/asciidoctor-extensions.rb ## +@@ Documentation/asciidoctor-extensions.rb: module Git + end + end + ++ class SynopsisMacroProcessor < Asciidoctor::Extensions::InlineMacroProcessor ++ use_dsl ++ ++ named :s ++ match(/s:\["(.+?)"\]/) ++ ++ def process(parent, target, attrs) ++ l = target.gsub(/([\[\] |()]|^|>)(\.?[-a-zA-Z0-9:+=~@,\/]+\.?)/, '\1{empty}`\2`{empty}') ++ .gsub(/(<[-a-zA-Z0-9.]+>)/, '__\\1__') ++ .gsub(']', ']{empty}') ++ ++ create_inline parent, :quoted, l, attributes: { 'subs' => :normal } ++ end ++ end ++ + class DocumentPostProcessor < Asciidoctor::Extensions::Postprocessor + def process document, output + if document.basebackend? 'docbook' @@ Documentation/asciidoctor-extensions.rb: module Git output end @@ Documentation/asciidoctor-extensions.rb: module Git + + def process parent, reader, attrs + outlines = reader.lines.map do |l| -+ l.gsub(/([\[\] |()>]|^)([-a-zA-Z0-9:+=.]+)/, '\\1{empty}`\\2`{empty}') ++ l.gsub(/([\[\] |()>]|^)([-a-zA-Z0-9:+=]+)/, '\1{empty}`\2`{empty}') + .gsub(/(<[-a-zA-Z0-9.]+>)/, '__\\1__') + .gsub(']', ']{empty}') + end @@ Documentation/asciidoctor-extensions.rb: module Git Asciidoctor::Extensions.register do inline_macro Git::Documentation::LinkGitProcessor, :linkgit ++ inline_macro Git::Documentation::SynopsisMacroProcessor + block Git::Documentation::SynopsisBlock postprocessor Git::Documentation::DocumentPostProcessor end 2: b6387bef40d ! 2: 92f3121cf4e doc: update the guidelines to reflect the current formatting rules @@ Commit message ## Documentation/CodingGuidelines ## @@ Documentation/CodingGuidelines: Markup: + _<key-id>_ + + When literal and placeholders are mixed, each markup is applied for +- each sub-entity. If they are stuck, a special markup, called +- unconstrained formatting is required. +- Unconstrained formating for placeholders is __<like-this>__ +- Unconstrained formatting for literal formatting is ++like this++ +- `--jobs` _<n>_ +- ++--sort=++__<key>__ +- __<directory>__++/.git++ +- ++remote.++__<name>__++.mirror++ +- +- caveat: ++ unconstrained format is not verbatim and may expand +- content. Use Asciidoc escapes inside them. ++ each sub-entity. If the formatting is becoming too hairy, you can use the ++ s:["foo"] formatting macro and let it format the groups for you. ++ `--jobs` _<n>_ or s:["--jobs <n>"] ++ s:["--sort=<key> ++ s:["<directory>/.git"] ++ s:["remote.<name>.mirror"] ++ s:["ssh://[<user>@]<host>[:<port>]/<path-to-git-repo>"] ++ ++Note that the double-quotes are required by the macro. Synopsis Syntax 3: 2a61e0945de ! 3: 02406b91894 doc: apply synopsis simplification on git-clone and git-init @@ Documentation/git-clone.txt: git-clone - Clone a repository into a new directory DESCRIPTION ----------- +@@ Documentation/git-clone.txt: prevent the unintentional copying of files by dereferencing the symbolic + links. + + + *NOTE*: this operation can race with concurrent modification to the +-source repository, similar to running `cp -r src dst` while modifying +-`src`. ++source repository, similar to running s:["cp -r <src> <dst>"] while modifying ++_<src>_. + + `--no-hardlinks`:: + Force the cloning process from a repository on a local +@@ Documentation/git-clone.txt: If you want to break the dependency of a repository cloned with `--shared` on + its source repository, you can simply run `git repack -a` to copy all + objects from the source repository into a pack in the cloned repository. + +-`--reference`[`-if-able`] _<repository>_:: ++s:["--reference[-if-able] <repository>"]:: + If the reference _<repository>_ is on the local machine, + automatically setup `.git/objects/info/alternates` to + obtain objects from the reference _<repository>_. Using +@@ Documentation/git-clone.txt: objects from the source repository into a pack in the cloned repository. + is specified. This flag forces progress status even if the + standard error stream is not directed to a terminal. + +-++--server-option=++__<option>__:: ++s:["--server-option=<option>"]:: + Transmit the given string to the server when communicating using + protocol version 2. The given string must not contain a NUL or LF + character. The server's handling of server options, including + unknown ones, is server-specific. +- When multiple ++--server-option=++__<option>__ are given, they are all ++ When multiple s:["--server-option=<option>"] are given, they are all + sent to the other side in the order listed on the command line. + + `-n`:: + `--no-checkout`:: +- No checkout of HEAD is performed after the clone is complete. ++ No checkout of `HEAD` is performed after the clone is complete. + + `--`[`no-`]`reject-shallow`:: + Fail if the source repository is a shallow repository. +@@ Documentation/git-clone.txt: objects from the source repository into a pack in the cloned repository. + `--bare`:: + Make a 'bare' Git repository. That is, instead of + creating _<directory>_ and placing the administrative +- files in _<directory>_`/.git`, make the _<directory>_ ++ files in s:["<directory>/.git"], make the _<directory>_ + itself the `$GIT_DIR`. This obviously implies the `--no-checkout` + because there is nowhere to check out the working tree. + Also the branch heads at the remote are copied directly +@@ Documentation/git-clone.txt: objects from the source repository into a pack in the cloned repository. + linkgit:git-sparse-checkout[1] command can be used to grow the + working directory as needed. + +-++--filter=++__<filter-spec>__:: ++s:["--filter=<filter-spec>"]:: + Use the partial clone feature and request that the server sends + a subset of reachable objects according to a given object filter. + When using `--filter`, the supplied _<filter-spec>_ is used for + the partial clone filter. For example, `--filter=blob:none` will + filter out all blobs (file contents) until needed by Git. Also, +- ++--filter=blob:limit=++__<size>__ will filter out all blobs of size ++ s:["--filter=blob:limit=<size>"] will filter out all blobs of size + at least _<size>_. For more details on filter specifications, see + the `--filter` option in linkgit:git-rev-list[1]. + +@@ Documentation/git-clone.txt: objects from the source repository into a pack in the cloned repository. + + `-b` _<name>_:: + `--branch` _<name>_:: +- Instead of pointing the newly created HEAD to the branch pointed +- to by the cloned repository's HEAD, point to _<name>_ branch ++ Instead of pointing the newly created `HEAD` to the branch pointed ++ to by the cloned repository's `HEAD`, point to _<name>_ branch + instead. In a non-bare repository, this is the branch that will + be checked out. +- `--branch` can also take tags and detaches the HEAD at that commit ++ `--branch` can also take tags and detaches the `HEAD` at that commit + in the resulting repository. + + `-u` _<upload-pack>_:: +@@ Documentation/git-clone.txt: objects from the source repository into a pack in the cloned repository. + via ssh, this specifies a non-default path for the command + run on the other end. + +-++--template=++__<template-directory>__:: ++s:["--template=<template-directory>"]:: + Specify the directory from which templates will be used; + (See the "TEMPLATE DIRECTORY" section of linkgit:git-init[1].) + +-`-c` __<key>__++=++__<value>__:: +-`--config` __<key>__++=++__<value>__:: ++`-c` s:["<key>=<value>"]:: ++`--config` s:["<key>=<value>"]:: + Set a configuration variable in the newly-created repository; + this takes effect immediately after the repository is + initialized, but before the remote history is fetched or any +@@ Documentation/git-clone.txt: objects from the source repository into a pack in the cloned repository. + Due to limitations of the current implementation, some configuration + variables do not take effect until after the initial fetch and checkout. + Configuration variables known to not take effect are: +-++remote.++__<name>__++.mirror++ and ++remote.++__<name>__++.tagOpt++. Use the ++s:["remote.<name>.mirror"] and s:["remote.<name>.tagOpt"]. Use the + corresponding `--mirror` and `--no-tags` options instead. + +-`--depth` _<depth>_:: ++s:["--depth <depth>"]:: + Create a 'shallow' clone with a history truncated to the + specified number of commits. Implies `--single-branch` unless + `--no-single-branch` is given to fetch the histories near the + tips of all branches. If you want to clone submodules shallowly, + also pass `--shallow-submodules`. + +-++--shallow-since=++__<date>__:: ++s:["--shallow-since=<date>"]:: + Create a shallow clone with a history after the specified time. + +-++--shallow-exclude=++__<revision>__:: ++s:["--shallow-exclude=<revision>"]:: + Create a shallow clone with a history, excluding commits + reachable from a specified remote branch or tag. This option + can be specified multiple times. + +-`--`[`no-`]`single-branch`:: ++s:["--[no-]single-branch"]:: + Clone only the history leading to the tip of a single branch, + either specified by the `--branch` option or the primary + branch remote's `HEAD` points at. +@@ Documentation/git-clone.txt: corresponding `--mirror` and `--no-tags` options instead. + + `--no-tags`:: + Don't clone any tags, and set +- `remote.<remote>.tagOpt=--no-tags` in the config, ensuring ++ s:["remote.<remote>.tagOpt=--no-tags"] in the config, ensuring + that future `git pull` and `git fetch` operations won't follow + any tags. Subsequent explicit tag fetches will still work, + (see linkgit:git-fetch[1]). +@@ Documentation/git-clone.txt: maintain a branch with no references other than a single cloned + branch. This is useful e.g. to maintain minimal clones of the default + branch of some repository for search indexing. + +-`--recurse-submodules`[`=`{empty}__<pathspec>__]:: ++s:["--recurse-submodules[=<pathspec>]"]:: + After the clone is created, initialize and clone submodules + within based on the provided _<pathspec>_. If no _=<pathspec>_ is + provided, all submodules are initialized and cloned. +@@ Documentation/git-clone.txt: branch of some repository for search indexing. + + + Submodules are initialized and cloned using their default settings. This is + equivalent to running +-`git submodule update --init --recursive <pathspec>` immediately after ++s:["git submodule update --init --recursive <pathspec>"] immediately after + the clone is finished. This option is ignored if the cloned repository does + not have a worktree/checkout (i.e. if any of `--no-checkout`/`-n`, `--bare`, + or `--mirror` is given) + +-`--`[`no-`]`shallow-submodules`:: ++s:["--[no-]shallow-submodules"]:: + All submodules which are cloned will be shallow with a depth of 1. + +-`--`[`no-`]`remote-submodules`:: ++s:["--[no-]remote-submodules"]:: + All submodules which are cloned will use the status of the submodule's + remote-tracking branch to update the submodule, rather than the + superproject's recorded SHA-1. Equivalent to passing `--remote` to + `git submodule update`. + +-`--separate-git-dir=`{empty}__<git-dir>__:: ++s:["--separate-git-dir=<git-dir>"]:: + Instead of placing the cloned repository where it is supposed + to be, place the cloned repository at the specified directory, + then make a filesystem-agnostic Git symbolic link to there. + The result is Git repository can be separated from working + tree. + +-`--ref-format=`{empty}__<ref-format>__:: ++s:["--ref-format=<ref-format>"]:: + + Specify the given ref storage format for the repository. The valid values are: + + +@@ Documentation/git-clone.txt: _<directory>_:: + for `host.xz:foo/.git`). Cloning into an existing directory + is only allowed if the directory is empty. + +-`--bundle-uri=`{empty}__<uri>__:: ++s:["--bundle-uri=<uri>"]:: + Before fetching from the remote, fetch a bundle from the given + _<uri>_ and unbundle the data into the local repository. The refs + in the bundle will be stored under the hidden `refs/bundle/*` ## Documentation/git-init.txt ## @@ Documentation/git-init.txt: git-init - Create an empty Git repository or reinitialize an existing one @@ Documentation/git-init.txt: git-init - Create an empty Git repository or reiniti DESCRIPTION +@@ Documentation/git-init.txt: directory with subdirectories for `objects`, `refs/heads`, + commits will be created (see the `--initial-branch` option below + for its name). + +-If the `$GIT_DIR` environment variable is set then it specifies a path ++If the `GIT_DIR` environment variable is set then it specifies a path + to use instead of `./.git` for the base of the repository. + + If the object storage directory is specified via the +-`$GIT_OBJECT_DIRECTORY` environment variable then the sha1 directories ++`GIT_OBJECT_DIRECTORY` environment variable then the sha1 directories + are created underneath; otherwise, the default `$GIT_DIR/objects` + directory is used. + +@@ Documentation/git-init.txt: Only print error and warning messages; all other output will be suppressed. + Create a bare repository. If `GIT_DIR` environment is not set, it is set to the + current working directory. + +-++--object-format=++__<format>__:: +- ++s:["--object-format=<format>"]:: + Specify the given object _<format>_ (hash algorithm) for the repository. The valid + values are `sha1` and (if enabled) `sha256`. `sha1` is the default. + + + include::object-format-disclaimer.txt[] + +-++--ref-format=++__<format>__:: +- ++s:["--ref-format=<format>"]:: + Specify the given ref storage _<format>_ for the repository. The valid values are: + + + include::ref-storage-format.txt[] + +-++--template=++__<template-directory>__:: +- ++s:["--template=<template-directory>"]:: + Specify the directory from which templates will be used. (See the "TEMPLATE + DIRECTORY" section below.) + +-++--separate-git-dir=++__<git-dir>__:: +- ++s:["--separate-git-dir=<git-dir>"]:: + Instead of initializing the repository as a directory to either `$GIT_DIR` or + `./.git/`, create a text file there containing the path to the actual + repository. This file acts as a filesystem-agnostic Git symbolic link to the +@@ Documentation/git-init.txt: repository. + If this is a reinitialization, the repository will be moved to the specified path. + + `-b` _<branch-name>_:: +-++--initial-branch=++__<branch-name>__:: +- ++s:["--initial-branch=<branch-name>"]:: + Use _<branch-name>_ for the initial branch in the newly created + repository. If not specified, fall back to the default name (currently + `master`, but this is subject to change in the future; the name can be + customized via the `init.defaultBranch` configuration variable). + +-++--shared++[++=++(`false`|`true`|`umask`|`group`|`all`|`world`|`everybody`|_<perm>_)]:: ++s:["--shared[=(false|true|umask|group|all|world|everybody|<perm>)]"]:: + + Specify that the Git repository is to be shared amongst several users. This + allows users belonging to the same group to push into that + + ## Documentation/urls.txt ## +@@ Documentation/urls.txt: Git supports ssh, git, http, and https protocols (in addition, ftp + and ftps can be used for fetching, but this is inefficient and + deprecated; do not use them). + +-The native transport (i.e. git:// URL) does no authentication and ++The native transport (i.e. `git://` URL) does no authentication and + should be used with caution on unsecured networks. + + The following syntaxes may be used with them: + +-- ++ssh://++{startsb}__<user>__++@++{endsb}__<host>__{startsb}++:++__<port>__{endsb}++/++__<path-to-git-repo>__ +-- ++git://++__<host>__{startsb}:__<port>__{endsb}++/++__<path-to-git-repo>__ +-- ++http++{startsb}++s++{endsb}++://++__<host>__{startsb}++:++__<port>__{endsb}++/++__<path-to-git-repo>__ +-- ++ftp++{startsb}++s++{endsb}++://++__<host>__{startsb}++:++__<port>__{endsb}++/++__<path-to-git-repo>__ ++- s:["ssh://[<user>@]<host>[:<port>]/<path-to-git-repo>"] ++- s:["git://<host>[:<port>]/<path-to-git-repo>"] ++- s:["http[s]://<host>[:<port>]/<path-to-git-repo>"] ++- s:["ftp[s]://<host>[:<port>]/<path-to-git-repo>"] + + An alternative scp-like syntax may also be used with the ssh protocol: + +-- {startsb}__<user>__++@++{endsb}__<host>__++:/++__<path-to-git-repo>__ ++- s:["[<user>@]<host>:/<path-to-git-repo>"] + + This syntax is only recognized if there are no slashes before the + first colon. This helps differentiate a local path that contains a +@@ Documentation/urls.txt: colon. For example the local path `foo:bar` could be specified as an + absolute path or `./foo:bar` to avoid being misinterpreted as an ssh + url. + +-The ssh and git protocols additionally support ++~++__<username>__ expansion: ++The ssh and git protocols additionally support s:["~<username>"] expansion: + +-- ++ssh://++{startsb}__<user>__++@++{endsb}__<host>__{startsb}++:++__<port>__{endsb}++/~++__<user>__++/++__<path-to-git-repo>__ +-- ++git://++__<host>__{startsb}++:++__<port>__{endsb}++/~++__<user>__++/++__<path-to-git-repo>__ +-- {startsb}__<user>__++@++{endsb}__<host>__++:~++__<user>__++/++__<path-to-git-repo>__ ++- s:["ssh://[<user>@]<host>[:<port>]/~<user>/<path-to-git-repo>"] ++- s:["git://<host>[:<port>]/~<user>/<path-to-git-repo>"] ++- s:["[<user>@]<host>:~<user>/<path-to-git-repo>"] + + For local repositories, also supported by Git natively, the following + syntaxes may be used: + + - `/path/to/repo.git/` +-- ++file:///path/to/repo.git/++ ++- `file:///path/to/repo.git/` + + ifndef::git-clone[] + These two syntaxes are mostly equivalent, except when cloning, when +@@ Documentation/urls.txt: endif::git-clone[] + accept a suitable bundle file. See linkgit:git-bundle[1]. + + When Git doesn't know how to handle a certain transport protocol, it +-attempts to use the `remote-`{empty}__<transport>__ remote helper, if one ++attempts to use the s:["remote-<transport>"] remote helper, if one + exists. To explicitly request a remote helper, the following syntax + may be used: + +-- _<transport>_::__<address>__ ++- s:["<transport>::<address>"] + + where _<address>_ may be a path, a server and path, or an arbitrary + URL-like string recognized by the specific remote helper being