From: Michael Lyons <git@michael.lyo.nz>
To: "Jean-Noël AVILA" <avila.jn@gmail.com>, git@vger.kernel.org
Subject: Re: [PATCH] doc: git-blame: convert blame to new doc format
Date: Tue, 06 Jan 2026 16:16:02 -0500 [thread overview]
Message-ID: <9123496.T7Z3S40VBb@debian-mbp> (raw)
In-Reply-To: <7894506.EvYhyI6sBW@piment-oiseau>
On Tuesday, January 6, 2026 1:57:27 PM Eastern Standard Time you wrote:
> Thanks for helping out.
Glad to!
> > --L <start>,<end>::
> > --L :<funcname>::
> > - Annotate only the line range given by '<start>,<end>',
> > - or by the function name regex '<funcname>'.
> > +`-L <start>,<end>`::
> > +`-L :<funcname>`::
> > + Annotate only the line range given by _<start>,<end>_,
>
> It would be better to use backticks, so that the comma is formatted as a
> keyword: `<start>,<end>`
Okay. I changed them back and forth a couple times before the first submission.
I have a question about this further down...
> >
> > --S <revs-file>::
> > - Use revisions from revs-file instead of calling linkgit:git-rev-
> > +`-S <revs-file>`::
> > + Use revisions from _revs-file_ instead of calling linkgit:git-rev-
>
> Placeholders keep their brackets: _<rev-file>_ in prose.
Smart.
> > ---reverse <rev>..<rev>::
> > +`--reverse <rev>..<rev>`::
> Here, I would differentiate the names of the two placeholders,
> <start>..<end> as used below.
>
> > Walk history forward instead of backward. Instead of showing
> > the revision in which a line appeared, this shows the last
> > revision in which a line has existed. This requires a range of
> >
> > - revision like START..END where the path to blame exists in
> > - START. `git blame --reverse START` is taken as `git blame
> > + revision like _START..END_ where the path to blame exists in
> > + _START_. `git blame --reverse START` is taken as `git blame
> >
> > --reverse START..HEAD` for convenience.
>
> Here, let's transition to the <placeholder> format: <start>..<end> and so
> on.
This is the continuation of my question on `<start>,<end>`: Do these also go
to backticks or keep the underscores? My impulse is backticks, but let me
know: `<start>..<end>` or _<start>..<end>_?
The start/end change from rev/rev makes sense.
> > ---progress::
> > ---no-progress::
> > +`--progress`::
> >
> > +`--no-progress`::
> > Progress status is reported on the standard error stream
> > by default when it is attached to a terminal. This flag
> > enables progress reporting even if not attached to a
> > terminal. Can't use `--progress` together with `--porcelain`
> > or `--incremental`.
>
> Here maybe swap the first two sentences, remove the "This flags" and convert
> to imperative mood. The first sentence is a bit redundant.
>
> As a general rule, I tend to reorder/reword the paragraph to describe the
> effect in the first sentence of the description with an imperative mood.
New commit will reword a couple things here. Fingers crossed. :)
> > - marked with a '*'. In the porcelain modes, we print 'ignored' and
> > - 'unblamable' on a newline respectively.
> > + marked with a `*`. In the porcelain modes, we print _ignored_ and
> > + _unblamable_ on a newline respectively.
>
> If the words are printed "verbatim", then the format is backticked:
> `ignored` and `unblamable`.
Another one where I had backticks originally and switched them. I'm not super-
familiar with the porcelain parts.
> This diff is quite large. If there are no other reasons to split the patch
> according to some semantic reason, then please split file by file.
Okay. Next try will just be blame-options for now.
>
> That's very good for a first try. Now, I hope that you will be ok to review
> my patches :-)
That's very kind. I'll probably need a couple more rounds before my changes
pass inspection, let alone be declared competent to review yours. :)
For the purposes of re-submission, should I be doing something with scissors
on this thread, or make a new thread?
Thanks again for the help!
ML
next prev parent reply other threads:[~2026-01-06 21:16 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-05 23:02 [PATCH] doc: git-blame: convert blame to new doc format Michael Lyons
2026-01-06 18:57 ` Jean-Noël AVILA
2026-01-06 21:16 ` Michael Lyons [this message]
2026-01-07 18:44 ` Jean-Noël AVILA
2026-01-08 15:30 ` [PATCH v2 0/2] " Michael Lyons
2026-01-08 15:30 ` [PATCH v2 1/2] doc: blame-options: convert " Michael Lyons
2026-01-08 15:30 ` [PATCH v2 2/2] doc: git-blame: " Michael Lyons
2026-01-08 18:24 ` [PATCH v2 0/2] doc: git-blame: convert blame " Jean-Noël AVILA
2026-01-11 18:24 ` 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=9123496.T7Z3S40VBb@debian-mbp \
--to=git@michael.lyo.nz \
--cc=avila.jn@gmail.com \
--cc=git@vger.kernel.org \
/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.