From: Mark Brown <broonie@kernel.org>
To: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Greg KH <gregkh@linuxfoundation.org>,
Jens Axboe <axboe@kernel.dk>,
Caleb Sander Mateos <csander@purestorage.com>,
io-uring <io-uring@vger.kernel.org>,
workflows@vger.kernel.org
Subject: Re: Link trailers revisited (was Re: [GIT PULL] io_uring fix for 6.17-rc5)
Date: Mon, 8 Sep 2025 12:59:41 +0100 [thread overview]
Message-ID: <684c2197-7cd4-4330-9a43-109c40fda9cf@sirena.org.uk> (raw)
In-Reply-To: <20250906-macho-reindeer-of-certainty-ff2cbb@lemur>
[-- Attachment #1: Type: text/plain, Size: 2321 bytes --]
On Sat, Sep 06, 2025 at 02:50:49PM -0400, Konstantin Ryabitsev wrote:
> On Sat, Sep 06, 2025 at 08:31:59AM -0700, Linus Torvalds wrote:
> > An emailed patch series is *not* a git pull. If you want actual real
> > git history, just use git. Using a patch series and shazam for that
> > would be *bad*. It's actively worse than just using git, with zero
> > upside.
> The primary consumer of this are the CI systems, though, like those that plug
> into patchwork. In order to be able to run a bunch of tests they need to be
> able to apply the patches to a tree, so, in a sense, they do need to recreate
> git as much as possible, including the branch point.
Well, for CI we often don't exactly care that the patch is applied in
the context that the sender sent it, we care more that the patch is
applied for testing in the same context where it's going to be applied
when merged. The base information is useful and we might want to use
it, but we might also not. My flow is to apply things, test and then
push to the actual tree if the testing is happy so I'm testing the
actual commits that will be pushed if everything goes well.
> > No, the upside of a patch series is that it's *not* fixed in stone yet
> > - not in history, not in acks, not in actual code. So do *not*
> > encourage people to think of it as some second-rate "git history"
> > model. It's not, and it would be *BAD* at it.
> b4 will tell you if a series applies cleanly to the current tree, but I don't
> think we make use of this with `shazam -M` -- we always try to parent it
> against the indicated base commit. Is the recommendation then to always try to
> use the latest tree and bail out if it doesn't apply?
If we're going to automatically pick up the base commit that needs an
option to limit what the commits that might be selected are, people
don't always send something directly usable. For example with a series
that should be split between trees (eg, a driver plus DT updates to add
the device to some boards) you might reasonably base off linux-next,
that'll get a current tree for everywhere the individual patches should
be applied. For example my scripting when it's paying attention to base
commits will ignore anything that's not in the history of the branch the
tree is targeted at unless I explicitly tell it otherwise.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2025-09-08 11:59 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-05 11:18 [GIT PULL] io_uring fix for 6.17-rc5 Jens Axboe
2025-09-05 17:24 ` Linus Torvalds
2025-09-05 17:45 ` Konstantin Ryabitsev
2025-09-05 18:06 ` Linus Torvalds
2025-09-05 19:33 ` Link trailers revisited (was Re: [GIT PULL] io_uring fix for 6.17-rc5) Konstantin Ryabitsev
2025-09-05 20:09 ` Linus Torvalds
2025-09-05 20:47 ` Sasha Levin
2025-09-06 11:27 ` Greg KH
2025-09-06 11:27 ` Greg KH
2025-09-06 11:30 ` Greg KH
2025-09-06 13:51 ` Konstantin Ryabitsev
2025-09-06 15:31 ` Linus Torvalds
2025-09-06 18:50 ` Konstantin Ryabitsev
2025-09-06 19:19 ` Linus Torvalds
2025-09-08 9:11 ` Jani Nikula
2025-09-08 11:59 ` Mark Brown [this message]
2025-09-08 20:11 ` dan.j.williams
2025-09-09 11:29 ` Mark Brown
2025-09-09 13:17 ` Rafael J. Wysocki
2025-09-09 14:18 ` Jakub Kicinski
2025-09-09 14:35 ` Jens Axboe
2025-09-09 14:42 ` Konstantin Ryabitsev
2025-09-09 14:48 ` Vlastimil Babka
2025-09-09 14:50 ` Jens Axboe
2025-09-09 15:30 ` Rafael J. Wysocki
2025-09-09 16:40 ` Linus Torvalds
2025-09-09 17:08 ` Mark Brown
2025-09-09 17:50 ` Linus Torvalds
2025-09-09 17:58 ` Linus Torvalds
2025-09-09 18:31 ` Konstantin Ryabitsev
2025-09-09 19:36 ` dan.j.williams
2025-09-10 1:12 ` dan.j.williams
2025-09-10 12:19 ` Mark Brown
2025-09-09 17:25 ` dan.j.williams
2025-09-09 17:56 ` Alexei Starovoitov
2025-09-09 18:01 ` Linus Torvalds
2025-09-09 18:13 ` Alexei Starovoitov
2025-09-09 18:06 ` Vlastimil Babka
2025-09-09 18:14 ` Linus Torvalds
2025-09-09 18:22 ` Vlastimil Babka
2025-09-09 21:05 ` Mark Brown
2025-09-10 1:33 ` Konstantin Ryabitsev
2025-09-09 14:44 ` Greg KH
2025-09-09 15:14 ` Danilo Krummrich
2025-09-09 16:32 ` [RFC] b4 dig: Add AI-powered email relationship discovery command Sasha Levin
2025-09-09 17:22 ` Laurent Pinchart
2025-09-09 17:26 ` Jens Axboe
2025-09-09 18:54 ` Sasha Levin
2025-09-10 10:13 ` Laurent Pinchart
2025-09-10 10:55 ` Sasha Levin
2025-09-10 11:29 ` Laurent Pinchart
2025-09-10 13:38 ` Konstantin Ryabitsev
2025-09-10 14:03 ` Andrew Dona-Couch
2025-09-11 14:48 ` Nicolas Frattaroli
2025-09-11 15:05 ` Sasha Levin
2025-09-11 19:13 ` Nicolas Frattaroli
2025-09-11 19:57 ` Sasha Levin
2025-09-15 11:26 ` Mark Brown
2025-09-15 11:48 ` Sasha Levin
2025-09-15 12:03 ` Mark Brown
2025-09-11 23:24 ` Konstantin Ryabitsev
2025-09-07 22:04 ` [GIT PULL] io_uring fix for 6.17-rc5 Jonathan Corbet
2025-09-05 19:04 ` Jens Axboe
2025-09-05 19:07 ` Jens Axboe
2025-09-05 19:13 ` Caleb Sander Mateos
2025-09-05 19:16 ` Jens Axboe
2025-09-05 19:15 ` Linus Torvalds
2025-09-05 19:23 ` Jens Axboe
2025-09-05 19:21 ` Linus Torvalds
2025-09-05 19:30 ` Jens Axboe
2025-09-05 20:54 ` Linus Torvalds
2025-09-06 0:01 ` Jens Axboe
2025-09-07 18:47 ` Jonathan Corbet
2025-09-08 22:15 ` Alexei Starovoitov
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=684c2197-7cd4-4330-9a43-109c40fda9cf@sirena.org.uk \
--to=broonie@kernel.org \
--cc=axboe@kernel.dk \
--cc=csander@purestorage.com \
--cc=gregkh@linuxfoundation.org \
--cc=io-uring@vger.kernel.org \
--cc=konstantin@linuxfoundation.org \
--cc=torvalds@linux-foundation.org \
--cc=workflows@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox