From: "Jean-Noël Avila via GitGitGadget" <gitgitgadget@gmail.com>
To: git@vger.kernel.org
Cc: "Jean-Noël Avila" <jn.avila@free.fr>
Subject: [PATCH v3 0/3] doc: introducing synopsis para
Date: Sun, 11 Aug 2024 15:20:09 +0000 [thread overview]
Message-ID: <pull.1766.v3.git.1723389612.gitgitgadget@gmail.com> (raw)
In-Reply-To: <pull.1766.v2.git.1721855179.gitgitgadget@gmail.com>
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
--
gitgitgadget
next prev parent reply other threads:[~2024-08-11 15:20 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-23 22:44 [PATCH 0/3] doc: introducing synopsis para Jean-Noël Avila via GitGitGadget
2024-07-23 22:44 ` [PATCH 1/3] doc: introduce a synopsis custom paragraph attribute Jean-Noël Avila via GitGitGadget
2024-07-23 23:36 ` Junio C Hamano
2024-07-23 22:44 ` [PATCH 2/3] doc: update the guidelines to reflect the current formatting rules Jean-Noël Avila via GitGitGadget
2024-07-23 23:37 ` Junio C Hamano
2024-07-23 22:44 ` [PATCH 3/3] doc: apply synopsis simplification on git-clone and git-init Jean-Noël Avila via GitGitGadget
2024-07-23 23:04 ` [PATCH 0/3] doc: introducing synopsis para Jean-Noël AVILA
2024-07-24 21:06 ` [PATCH v2 " Jean-Noël Avila via GitGitGadget
2024-07-24 21:06 ` [PATCH v2 1/3] doc: introduce a synopsis custom paragraph attribute Jean-Noël Avila via GitGitGadget
2024-07-24 21:06 ` [PATCH v2 2/3] doc: update the guidelines to reflect the current formatting rules Jean-Noël Avila via GitGitGadget
2024-07-24 21:06 ` [PATCH v2 3/3] doc: apply synopsis simplification on git-clone and git-init Jean-Noël Avila via GitGitGadget
2024-07-24 23:15 ` [PATCH v2 0/3] doc: introducing synopsis para Junio C Hamano
2024-07-25 12:15 ` Jean-Noël AVILA
2024-07-25 15:32 ` Junio C Hamano
2024-08-11 15:20 ` Jean-Noël Avila via GitGitGadget [this message]
2024-08-11 15:20 ` [PATCH v3 1/3] doc: introduce a synopsis custom paragraph attribute Jean-Noël Avila via GitGitGadget
2024-08-11 15:20 ` [PATCH v3 2/3] doc: update the guidelines to reflect the current formatting rules Jean-Noël Avila via GitGitGadget
2024-08-11 23:56 ` Eric Sunshine
2024-08-12 6:18 ` Jean-Noël Avila
2024-08-11 15:20 ` [PATCH v3 3/3] doc: apply synopsis simplification on git-clone and git-init Jean-Noël Avila via GitGitGadget
2024-08-19 20:08 ` [PATCH v3 0/3] doc: introducing synopsis para Junio C Hamano
2024-08-21 21:05 ` Jean-Noël AVILA
2024-08-30 17:48 ` Junio C Hamano
2024-09-05 21:52 ` [PATCH v4 " Jean-Noël Avila via GitGitGadget
2024-09-05 21:52 ` [PATCH v4 1/3] doc: introduce a synopsis typesetting Jean-Noël Avila via GitGitGadget
2024-09-05 21:52 ` [PATCH v4 2/3] doc: update the guidelines to reflect the current formatting rules Jean-Noël Avila via GitGitGadget
2024-09-05 21:52 ` [PATCH v4 3/3] doc: apply synopsis simplification on git-clone and git-init Jean-Noël Avila via GitGitGadget
2024-09-13 18:15 ` [PATCH v4 0/3] doc: introducing synopsis para Junio C Hamano
2024-09-20 23:14 ` Josh Steadmon
2024-09-21 1:38 ` Junio C Hamano
2024-09-21 6:19 ` Junio C Hamano
2024-09-21 6:23 ` Junio C Hamano
2024-09-21 6:54 ` Chris Torek
2024-09-23 16:38 ` Junio C Hamano
[not found] ` <CAPig+cQgw8xf5bQaUEW=qvKQpnxrkiTrMsqa+VW9d_GX0au1sA@mail.gmail.com>
2024-09-24 22:03 ` Josh Steadmon
2024-09-24 23:34 ` Junio C Hamano
2024-09-24 7:08 ` [PATCH v5 " Jean-Noël Avila via GitGitGadget
2024-09-24 7:08 ` [PATCH v5 1/3] doc: introduce a synopsis typesetting Jean-Noël Avila via GitGitGadget
2024-09-24 7:08 ` [PATCH v5 2/3] doc: update the guidelines to reflect the current formatting rules Jean-Noël Avila via GitGitGadget
2024-09-24 7:08 ` [PATCH v5 3/3] doc: apply synopsis simplification on git-clone and git-init Jean-Noël Avila via GitGitGadget
2024-09-24 17:16 ` [PATCH v5 0/3] doc: introducing synopsis para Junio C Hamano
2024-09-24 19:30 ` Torsten Bögershausen
2024-09-24 20:33 ` Junio C Hamano
2024-10-02 21:41 ` Josh Steadmon
2024-10-02 22:43 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=pull.1766.v3.git.1723389612.gitgitgadget@gmail.com \
--to=gitgitgadget@gmail.com \
--cc=git@vger.kernel.org \
--cc=jn.avila@free.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).