From: "Jean-Noël AVILA" <jn.avila@free.fr>
To: "Jean-Noël Avila via GitGitGadget" <gitgitgadget@gmail.com>,
"Patrick Steinhardt" <ps@pks.im>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] doc: git-restore: migrate to new style format
Date: Tue, 07 Jan 2025 22:48:21 +0100 [thread overview]
Message-ID: <6011894.MhkbZ0Pkbq@cayenne> (raw)
In-Reply-To: <Z3t8sjsCeiPmHffA@pks.im>
On Monday, 6 January 2025 07:48:27 CET Patrick Steinhardt wrote:
> On Sat, Jan 04, 2025 at 01:16:40PM +0000, Jean-Noël Avila via GitGitGadget
wrote:
> > From: =?UTF-8?q?Jean-No=C3=ABl=20Avila?= <jn.avila@free.fr>
> >
> > The git-restore manpage was converted to the new documentation
> > format:
>
> Commit messages should typically use imperative style, as if asking the
> code to change. For example:
>
> Convert the git-restore(1) man page to our new documentation format.
> This includes the following conversions:
>
> - Switch the synopsis to a 'synopsis' block, which will
> automatically format placeholders in italics and keywords in
> monospace.
>
> - Use `_<placeholder>_` instead of `<placeholder>` in the
> description.
>
> - Use backticks for keywords and more complex option descriptions.
> The new rendering engine will apply synopsis rules to these spans.
>
Will do.
> > diff --git a/Documentation/git-restore.txt b/Documentation/git-restore.txt
> > index 975825b44aa..541a39b5d28 100644
> > --- a/Documentation/git-restore.txt
> > +++ b/Documentation/git-restore.txt
> > @@ -41,79 +41,79 @@ OPTIONS
> > If not specified, the contents are restored from `HEAD` if `--staged` is
> > given, otherwise from the index.
> > +
> > -As a special case, you may use `"A...B"` as a shortcut for the
> > -merge base of `A` and `B` if there is exactly one merge base. You can
> > -leave out at most one of `A` and `B`, in which case it defaults to
`HEAD`.
> > +As a special case, you may use `"<refA>...<refB>"` as a shortcut for the
> > +merge base of _<refA>_ and _<refB>_ if there is exactly one merge base.
You can
> > +leave out at most one of _<refA>__ and _<refB>_, in which case it
defaults to `HEAD`.
>
> This change is a bit surprising to me though. Why was this renamed from
> A and B to refA and refB, respectively? It should be possible for these
> to be object IDs and not refs.
Sorry for mixing things up revs with refs. The "A" and "B" are just
placeholders for revisions, and their names need to be more informative.
So, it should be <rev-A> and <rev-B> all along.
>
> > @@ -122,30 +122,29 @@ in linkgit:git-checkout[1] for details.
> > not be updated. Just like linkgit:git-checkout[1], this will
detach
> > `HEAD` of the submodule.
> >
> > ---overlay::
> > ---no-overlay::
> > - In overlay mode, the command never removes files when
> > - restoring. In no-overlay mode, tracked files that do not
> > - appear in the `--source` tree are removed, to make them match
> > - `<tree>` exactly. The default is no-overlay mode.
> > -
> > ---pathspec-from-file=<file>::
> > - Pathspec is passed in `<file>` instead of commandline args. If
> > - `<file>` is exactly `-` then standard input is used. Pathspec
> > - elements are separated by LF or CR/LF. Pathspec elements can be
> > +`--overlay`::
> > +`--no-overlay`::
> > + In overlay mode, never remove files when restoring. In no-overlay
mode,
> > + remove tracked files that do not appear in the `--source` tree, to
make
> > + them match _<tree>_ exactly. The default is no-overlay mode.
> > +
> > +`--pathspec-from-file=<file>`::
> > + Pathspec is passed in _<file>_ instead of commandline args. If
> > + _<file>_ is exactly `-` then standard input is used. Pathspec
> > + elements are separated by _LF_ or _CR_/_LF_. Pathspec elements can
be
>
> The reflowing of these paragraphs makes it a bit hard to see what
> exactly is changing.
>
For the first set of options, there is a conversion to imperative mood, and I
triggered a reflow.
For the second one, it just appears that all lines are slightly changed by
the new formatting.
More generally, I kept reflowing the paragraphs to maintain the width, because
this was done everywhere before, but I would strongly prefer having each
sentence on separate line, regardless of its length. For asciidoc texts, this
policy has some advantages:
* keep a lexical entity as a single line, and get rid messed up diffs due to
reflowing.
* unfortunate automatic reflows can create errors, for instance when a part of
text is sent to the beginning of line and is interpreted as a list item.
JN
next prev parent reply other threads:[~2025-01-07 21:48 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-04 13:16 [PATCH] doc: git-restore: migrate to new style format Jean-Noël Avila via GitGitGadget
2025-01-06 6:48 ` Patrick Steinhardt
2025-01-07 21:48 ` Jean-Noël AVILA [this message]
2025-01-10 10:09 ` [PATCH v2] doc: convert git-restore " Jean-Noël Avila via GitGitGadget
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=6011894.MhkbZ0Pkbq@cayenne \
--to=jn.avila@free.fr \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=ps@pks.im \
/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).