All of lore.kernel.org
 help / color / mirror / Atom feed
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-notes.txt: migrate to new documentation format
Date: Tue, 07 Jan 2025 22:22:57 +0100	[thread overview]
Message-ID: <3330199.aeNJFYEL58@cayenne> (raw)
In-Reply-To: <Z3t_GvqfZL9y-_9p@pks.im>

On Monday, 6 January 2025 08:00:01 CET Patrick Steinhardt wrote:
> On Fri, Jan 03, 2025 at 05:10:16PM +0000, Jean-Noël Avila via GitGitGadget 
wrote:
> > From: =?UTF-8?q?Jean-No=C3=ABl=20Avila?= <jn.avila@free.fr>
> > 
> > The git-notes manpage files were converted to the new documentation
> > format:
> > 
> > - switching 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.
> 
> I think it might be a bit easier to send related changes like this and
> your changes to git-restore(1) in a single patch series going forward.
> It allows the reviewer to bundle related reviews together, which
> requires less context switching. It also allows them to more easily
> refer to similar review feedbacks sent for preceding patches.
> 

For simple manpages, I'll do this from now on.

> Other than that I've got the same comments here regarding the style of
> the commit message as with your git-restore(1) patch. Ah, I also noticed
> that the subject should probably be amended because we don't typically
> specify multiple subsystems with colons. For example:
> 
>     Documentation: migrate git-restore(1) to new style format
> 

Will do.

> > diff --git a/Documentation/config/notes.txt b/Documentation/config/notes.txt
> > index 43db8e808d7..70859f5c574 100644
> > --- a/Documentation/config/notes.txt
> > +++ b/Documentation/config/notes.txt
> > @@ -26,27 +26,27 @@ globs.
> >  A warning will be issued for refs that do not exist,
> >  but a glob that does not match any refs is silently ignored.
> >  +
> > -This setting can be disabled by the `--no-notes` option to the 'git
> > -log' family of commands, or by the `--notes=<ref>` option accepted by
> > +This setting can be disabled by the `--no-notes` option to the `git
> > +log` family of commands, or by the `--notes=<ref>` option accepted by
> >  those commands.
> 
> Should this rather use "to the linkgit:git-log[1] family of commands,
> ..."?
> 

Nice catch, although not really the primary aim of this patch. Will fix.

> > diff --git a/Documentation/git-notes.txt b/Documentation/git-notes.txt
> > index 84022f99d76..02a3495986a 100644
> > --- a/Documentation/git-notes.txt
> > +++ b/Documentation/git-notes.txt
> > @@ -33,34 +33,34 @@ ENVIRONMENT sections below.  If this ref does not 
exist, it will be
> >  quietly created when it is first needed to store a note.
> >  
> >  A typical use of notes is to supplement a commit message without
> > -changing the commit itself. Notes can be shown by 'git log' along with
> > +changing the commit itself. Notes can be shown by `git log` along with
> >  the original commit message. To distinguish these notes from the
> >  message stored in the commit object, the notes are indented like the
> > -message, after an unindented line saying "Notes (<refname>):" (or
> > -"Notes:" for `refs/notes/commits`).
> > +message, after an unindented line saying "`Notes (<refname>):`" (or
> > +"`Notes:`" for `refs/notes/commits`).
> 
> Curious. I'm not familiar with the modern best practices around where to
> apply what kind of quoting, so why is it "`foo`" here and not `"foo"` or
> `foo:`?
> 

Good question. I usually tend to remove double quotes and replace them by back 
quotes when the words are keywords. Here this is a string citation, but I 
would still prefer to apply the synopsis formatting. Maybe, something lighter 
such as "Notes (_<refname>_):", which would just format the placeholder, would 
better fit.

JN




  parent reply	other threads:[~2025-01-07 21:23 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-03 17:10 [PATCH] doc: git-notes.txt: migrate to new documentation format Jean-Noël Avila via GitGitGadget
2025-01-06  7:00 ` Patrick Steinhardt
2025-01-06 15:32   ` Junio C Hamano
2025-01-07 21:22   ` Jean-Noël AVILA [this message]
2025-01-10 10:08 ` [PATCH v2] doc: convert git-notes " 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=3330199.aeNJFYEL58@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.