ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: James Bottomley <James.Bottomley@hansenpartnership.com>
Cc: Greg KH <gregkh@linuxfoundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Konstantin Ryabitsev <konstantin@linuxfoundation.org>,
	dan.j.williams@intel.com, Doug Anderson <dianders@chromium.org>,
	"ksummit@lists.linux.dev" <ksummit@lists.linux.dev>
Subject: Re: Replacing Link trailers
Date: Thu, 16 Oct 2025 12:21:49 -0400	[thread overview]
Message-ID: <20251016121653-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <892a58917795bf5d29394bb5123dae2a6615ca08.camel@HansenPartnership.com>

On Thu, Oct 16, 2025 at 07:54:01AM -0400, James Bottomley wrote:
> On Thu, 2025-10-16 at 08:57 +0200, Greg KH wrote:
> > On Wed, Oct 15, 2025 at 12:17:27PM -0700, Linus Torvalds wrote:
> > > On Wed, 15 Oct 2025 at 12:15, Linus Torvalds
> > > <torvalds@linux-foundation.org> wrote:
> > > > 
> > > > (The above script is "tested" in that I verified that yes
> > > 
> > > .. premature 'hit send' situation. That should have said
> > > 
> > >  ..that yes] I verified that it superficially works, but didn't do
> > > anything exhaustive.
> > > 
> > > It was obviously meant as a "look, you can do things like this",
> > > not as a real fully fleshed out solution.
> > 
> > So, to summarize all of this, you are suggesting that maintainers:
> > 	- don't automatically include Link: tags when they don't
> > touch a
> > 	  patch and apply it directly from the email as `b4 dig`
> > will be
> > 	  able to find the patch.
> > 	- if a maintainer does change a patch, add the Link: tag so
> > that
> > 	  people can find the original patch when looking it up
> > later.
> > 
> > Is that correct?
> > 
> > If so, ugh, that just raised the workload of all of us maintainers as
> > now we have to remember to do that second step manually (or through
> > the new git hook, which will NOT work without a network connection so
> > no applying patches from planes or trains).
> 
> I agree with all the complexity.  So why don't we simply have git am
> add message-id to the commit header if it exists in the patch?  That
> way every b4 generated commit will have a message-id header.  No-one
> will ever see it unless they ask for the --pretty=raw (which is what
> tools can do, so they'll all just work) and it is completely mindless
> so everyone always knows what it points to if they want to dig it out.
> b4 dig can even use it as the starting point to find the email.
> 
> Bonus: everyone is forced to use it (because it's built in to git) and
> we always know exactly what it means: no debate about what the target
> of the link should be.
> 
> Regards,
> 
> James

Or a "log filter" flag to make git log
- hide message id tag in the commit log - for those that hate it
- convert it to lore links - for those that want it clickable



-- 
MST


  parent reply	other threads:[~2025-10-16 16:21 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-13 11:53 James Bottomley
2025-10-13 12:25 ` Mathieu Desnoyers
2025-10-13 12:48   ` James Bottomley
2025-10-13 12:50   ` Mark Brown
2025-10-13 14:52   ` Guenter Roeck
2025-10-13 17:36   ` Steven Rostedt
2025-10-14 19:12   ` Johannes Berg
2025-10-14 19:35     ` Steven Rostedt
2025-10-15 22:01       ` Johannes Berg
2025-10-15 22:22         ` Steven Rostedt
2025-10-16 10:16           ` Simona Vetter
2025-10-16 12:18             ` Hans de Goede
2025-10-16 18:39           ` David Woodhouse
2025-10-16  7:43         ` Geert Uytterhoeven
2025-10-14 20:23     ` Doug Anderson
2025-10-16  8:08     ` Dan Carpenter
2025-10-13 15:40 ` Doug Anderson
2025-10-13 16:31   ` James Bottomley
2025-10-13 17:39     ` Steven Rostedt
2025-10-13 17:50       ` Theodore Ts'o
2025-10-13 19:07         ` H. Peter Anvin
2025-10-13 19:20           ` Linus Torvalds
2025-10-13 19:35             ` James Bottomley
2025-10-13 19:37               ` H. Peter Anvin
2025-10-13 19:36             ` H. Peter Anvin
2025-10-13 20:34             ` Doug Anderson
2025-10-13 20:36               ` H. Peter Anvin
2025-10-13 20:58               ` Laurent Pinchart
2025-10-13 20:59               ` Vlastimil Babka
2025-10-13 21:46                 ` Doug Anderson
2025-10-14 14:23                   ` Sasha Levin
2025-10-14 11:09               ` Mark Brown
2025-10-13 19:35           ` H. Peter Anvin
2025-10-14 16:01   ` dan.j.williams
2025-10-14 17:46     ` Greg KH
2025-10-14 17:57       ` dan.j.williams
2025-10-15 17:09       ` dan.j.williams
2025-10-15 17:55         ` James Bottomley
2025-10-15 18:04           ` Luck, Tony
2025-10-15 18:37         ` Konstantin Ryabitsev
2025-10-15 19:13           ` dan.j.williams
2025-10-15 19:15           ` Linus Torvalds
2025-10-15 19:17             ` Linus Torvalds
2025-10-15 22:51               ` Doug Anderson
2025-10-16  4:26                 ` Chen-Yu Tsai
2025-10-16  6:57               ` Greg KH
2025-10-16 10:04                 ` Jani Nikula
2025-10-16 11:54                 ` James Bottomley
2025-10-16 12:18                   ` Greg KH
2025-10-16 12:29                     ` James Bottomley
2025-10-16 13:00                       ` Konstantin Ryabitsev
2025-10-16 13:47                         ` Steven Rostedt
2025-10-16 14:36                         ` Mark Brown
2025-10-16 14:58                         ` Rob Herring
2025-10-16 15:07                           ` James Bottomley
2025-10-16 15:36                             ` Geert Uytterhoeven
2025-10-16 15:52                               ` James Bottomley
2025-10-16 15:37                             ` Steven Rostedt
2025-10-16 19:29                           ` H. Peter Anvin
2025-10-16 19:32                             ` James Bottomley
2025-10-16 23:53                               ` H. Peter Anvin
2025-10-16 19:09                         ` James Bottomley
2025-10-17  2:27                           ` Doug Anderson
2025-10-17  8:44                             ` Vlastimil Babka
2025-10-17  9:21                               ` Geert Uytterhoeven
2025-10-17 10:09                                 ` Rafael J. Wysocki
2025-10-16 12:34                     ` Mathieu Desnoyers
2025-10-16 12:49                       ` Mark Brown
2025-10-16 12:49                       ` Geert Uytterhoeven
2025-10-16 12:54                         ` Mathieu Desnoyers
2025-10-16 13:07                           ` Geert Uytterhoeven
2025-10-16 12:51                       ` Jiri Kosina
2025-10-16 12:54                         ` James Bottomley
2025-10-16 13:51                           ` Steven Rostedt
2025-10-16 16:21                   ` Michael S. Tsirkin [this message]
2025-10-16 12:20                 ` Steven Rostedt
2025-10-15 21:29             ` Kees Cook
2025-10-15 21:40             ` Mark Brown

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=20251016121653-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=dan.j.williams@intel.com \
    --cc=dianders@chromium.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=konstantin@linuxfoundation.org \
    --cc=ksummit@lists.linux.dev \
    --cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox