All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jean-Noël AVILA" <jn.avila@free.fr>
To: git@vger.kernel.org, Michael Lyons <git@michael.lyo.nz>
Subject: Re: [PATCH] doc: git-blame: convert blame to new doc format
Date: Wed, 07 Jan 2026 19:44:51 +0100	[thread overview]
Message-ID: <2395053.ElGaqSPkdT@piment-oiseau> (raw)
In-Reply-To: <9123496.T7Z3S40VBb@debian-mbp>

On Tuesday, 6 January 2026 22:16:02 CET Michael Lyons wrote:
> > 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.


Definitely backticks here, because this is a complex synopsis span.


> 
> > > -	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.

You can push two commits in this series.

> 
> > 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?

Usually, the reworked series is pushed with v2 as reply to the first mail of 
the first submission, using for instance:

git send-email '--in-reply-to=<20260105230220.519303-1-git@michael.lyo.nz>' 
v2-*.patch

JN



  reply	other threads:[~2026-01-07 18:45 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
2026-01-07 18:44     ` Jean-Noël AVILA [this message]
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=2395053.ElGaqSPkdT@piment-oiseau \
    --to=jn.avila@free.fr \
    --cc=git@michael.lyo.nz \
    --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.