b4: prerequisite patch-ids generated in wrong order
Hello,
In this[1] recently submitted series, I specificially listed:
message-id: <[email protected]>
in the dependencies (via b4 prep --edit-deps), and during b4 send (I think), this turns into prerequisite-message-id` in the trailers of the cover letter.
But also it seems to have taken that message-id, grabbed the 3 patch-ids and also added prerequisite-patch-id to the trailers. That was bit unexpected, but clever.
However, I think those patch-ids are not in the right order. Because when try to b4 shazam my series, it fails[2] because it is tries to apply the prerequisite patches in the wrong order (PATCH 2/3, PATCH 3/3, then PATCH 1/3) which fails, as might be expected.
I'm not sure where all those prerequisite-patch-id are generated, but there's something fishy going on there.
Also, a dumb Q: why isn't the prerequisite message-id enough? Why does it also try to generate all the prerequisite-patch-id fields?
Kevin
[2]
$ b4 shazam 20240805-lpm-v6-10-constraints-pmdomain-v1-0-d186b68ded4c@baylibre.com Grabbing thread from lore.kernel.org/all/20240805-lpm-v6-10-constraints-pmdomain-v1-0-d186b68ded4c@baylibre.com/t.mbox.gz Checking for newer revisions Grabbing search results from lore.kernel.org Analyzing 4 messages in the thread Looking for additional code-review trailers on lore.kernel.org Analyzing 0 code-review messages Checking attestation on all messages, may take a moment... --- ✓ [PATCH 1/3] pmdomain: ti_sci: add per-device latency constraint management ✓ [PATCH 2/3] pmdomain: ti_sci: add wakeup constraint management ✓ [PATCH 3/3] pmdomain: ti_sci: handle wake IRQs for IO daisy chain wakeups --- ✓ Signed: openpgp/[email protected] --- NOTE: install dkimpy for DKIM signature verification --- Total patches: 3 --- Base: using specified base-commit ad7eb1b6b92ee0c959a0a6ae846ddadd7a79ea64 Deps: looking for dependencies matching 3 patch-ids Grabbing search results from lore.kernel.org Deps: Applying prerequisite patch: [PATCH v8 2/3] firmware: ti_sci: Add support for querying the firmware caps Deps: Applying prerequisite patch: [PATCH v8 3/3] firmware: ti_sci: Add system suspend and resume call Deps: Applying prerequisite patch: [PATCH v8 1/3] firmware: ti_sci: Introduce Power Management Ops Applying: firmware: ti_sci: Add support for querying the firmware caps Patch failed at 0001 firmware: ti_sci: Add support for querying the firmware caps error: patch failed: drivers/firmware/ti_sci.c:3113 error: drivers/firmware/ti_sci.c: patch does not apply hint: Use 'git am --show-current-patch=diff' to see the failed patch hint: When you have resolved this problem, run "git am --continue". hint: If you prefer to skip this patch, run "git am --skip" instead. hint: To restore the original branch and stop patching, run "git am --abort". hint: Disable this message with "git config advice.mergeConflict false"
Quoted 5 lines · Kevin Hilman
Hello,
In this[1] recently submitted series, I specificially listed:
message-id: <[email protected]>
bugbot assign to me
Hello:
This conversation is now tracked by Kernel.org Bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=219163
There is no need to do anything else, just keep talking.
Signature · 2 lines
Deet-doot-dot, I am a bot. Kernel.org Bugzilla (bugspray 0.1-dev)
Konstantin Ryabitsev writes in commit cb14d1fdbd054988773234624906ff39d8a6311e:
ez: fix prereq expanding for series specified by message-id
When we retrieve a thread from lore, the messages in it can be in an arbitrary order. Make a LoreSeries() out of them first to make sure that we always output prerequisite-patch-ids in the correct sequence.
(via https://git.kernel.org/pub/scm/utils/b4/b4.git/commit/?id=cb14d1fdbd05)
Signature · 2 lines
Deet-doot-dot, I am a bot. Kernel.org Bugzilla (bugspray 0.1-dev)
Quoted 2 lines · Kevin Hilman
Also, a dumb Q: why isn't the prerequisite message-id enough? Why does it also try to generate all the prerequisite-patch-id fields?
This is because the only "official" mechanism of specifying prerequisites is via prerequisite-patch-id trailers (see git-format-patch(1)).
I also expect this mechanism is much easier for CI systems, because looking up a dependency via the patch-id is the simplest and quickest way to retrieve a patch, which can then be safely cached locally without having to re-query lore again.
-K