From: Sasha Levin <sashal@kernel.org>
To: Linus Torvalds <torvalds@linuxfoundation.org>
Cc: Junio C Hamano <junio@pobox.com>,
Paolo Bonzini <pbonzini@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
Konstantin Ryabitsev <konstantin@linuxfoundation.org>,
users@kernel.org, tools@linux.kernel.org
Subject: Re: In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers)
Date: Mon, 13 Oct 2025 19:22:09 -0400 [thread overview]
Message-ID: <aO2JoWLd0Mxc4oUV@laps> (raw)
In-Reply-To: <CAHk-=wh--VXgwQ3s8DLeag6cegsD9cPcvkmbVft0Gesy2aGPsA@mail.gmail.com>
On Mon, Oct 13, 2025 at 02:44:28PM -0700, Linus Torvalds wrote:
>For example, while I think that a "git rebase --keep-merges" workflow
>is a bit scary and opens you up to lots of possible things going
>wrong, having some way for "git rebase -i" to *add* merges
>interactively might be a nice option.
>
>I've personally had the situation where I created some series of
>patches and wanted to group them later. What I would do is then create
>a different branch, rebase the patches I wanted to keep in one series
>in that branch, and then go back, and rebase the original branch with
>the remaining commits.
[...]
>Having a linear series of patches delimited by merges to group them
>and document them would probably work really well, but it would need
>to fit in with all the other tools, and as mentioned, many tools
>really do just do "patch series".
[...]
>So rather than doing a separate branch, rebasing things there, and
>going back and rebasing away the things in my original branch, doing
>just 'git rebase -i" in the original branch and having some way to say
>"this is the start of this series", and a "this is the end of the
>series", and having git rebase create a set of linear series with
>merges that delineate them might be quite convenient.
I'm using such workflow for my backporting work: I often want to group the
patch I'm backporting along with it's dependencies into a single "atomic" unit
to make it easier to review those changes later.
It currently uses hackery like the one you've described. Something like this:
N=$1
saved=$(git rev-parse HEAD)
temp="tmp-triangle-$(date +%s)"
git branch $temp $saved
git reset --hard HEAD~$N
git merge --no-ff -m "${2:-Merge triangle of last $N commits}" $temp
git branch -D $temp
Which creates a structure such as:
$ git log -5 --oneline --graph 11faed99eb
* 11faed99eb030 FAILED: 64e0d839c589 ("mfd: intel_soc_pmic_chtdc_ti: Set use_single_read regmap_config flag")
|\
| * 3bc90aaf9933e mfd: intel_soc_pmic_chtdc_ti: Set use_single_read regmap_config flag
| * 08b4fd511c7f9 mfd: intel_soc_pmic_chtdc_ti: Drop unneeded assignment for cache_type
| * f6d0ec2c9ccb4 mfd: intel_soc_pmic_chtdc_ti: Fix invalid regmap-config max_register value
|/
* 2b2cbdcede387 (tag: v6.12.52, stable/linux-6.12.y) Linux 6.12.52
If you want to use it as part of your git-rebase workflow, just call the script during rebase:
pick c3c4268124d22 # kbuild: Use '--strip-unneeded-symbol' for removing module device table symbols
pick 4ee16af35eb65 # tracing: Fix tracing_mark_raw_write() to use buf and not ubuf
pick 88d5c7c180dfc # tracing: Stop fortify-string from warning in tracing_mark_raw_write()
x stable-make-triangle 2
pick ed5afe51ba32e # irqchip/aspeed-scu-ic: Fix an IS_ERR() vs NULL check
pick 89d38b0392fa4 # irqchip/sifive-plic: Avoid interrupt ID 0 handling during suspend/resume
pick 3897851fae349 # Revert "i2c: boardinfo: Annotate code used in init phase only"
pick 49a451202c681 # Linux 6.18-rc1
Which results in something like what you were looking for?
$ git log --oneline --graph -10
* 53cb9bf28b1b7 (HEAD) Linux 6.18-rc1
* d6f9a71712aff Revert "i2c: boardinfo: Annotate code used in init phase only"
* 8943a4934a860 irqchip/sifive-plic: Avoid interrupt ID 0 handling during suspend/resume
* 12257b8fccebf irqchip/aspeed-scu-ic: Fix an IS_ERR() vs NULL check
* decf0198935a6 Merge triangle of last 2 commits
|\
| * 88d5c7c180dfc tracing: Stop fortify-string from warning in tracing_mark_raw_write()
| * 4ee16af35eb65 tracing: Fix tracing_mark_raw_write() to use buf and not ubuf
|/
* c3c4268124d22 kbuild: Use '--strip-unneeded-symbol' for removing module device table symbols
* 0f43fbd0b759c s390/vmlinux.lds.S: Move .vmlinux.info to end of allocatable sections
--
Thanks,
Sasha
next prev parent reply other threads:[~2025-10-13 23:22 UTC|newest]
Thread overview: 81+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-11 5:59 In defense of Link (was Re: [b4] initial "b4 dig" to supplant Link: trailers) Paolo Bonzini
2025-10-11 6:13 ` Willy Tarreau
2025-10-11 6:33 ` Paolo Bonzini
2025-10-15 8:56 ` Geert Uytterhoeven
2025-10-11 6:39 ` Jiri Slaby
2025-10-11 10:33 ` Mark Brown
2025-10-12 23:27 ` Jason Gunthorpe
2025-10-13 8:18 ` Vlastimil Babka (SUSE)
2025-10-13 8:27 ` Paolo Bonzini
2025-10-13 8:42 ` Willy Tarreau
2025-10-13 8:48 ` Jiri Slaby
2025-10-13 8:56 ` Willy Tarreau
2025-10-13 11:21 ` Laurent Pinchart
2025-10-13 14:26 ` [workflows]Re: " Steven Rostedt
2025-10-13 14:39 ` Laurent Pinchart
2025-10-13 14:59 ` Steven Rostedt
2025-10-13 15:04 ` Laurent Pinchart
2025-10-13 15:44 ` Steven Rostedt
2025-10-13 11:03 ` Mark Brown
2025-10-13 11:49 ` James Bottomley
2025-10-13 12:15 ` Mark Brown
2025-10-13 12:29 ` Paolo Bonzini
2025-10-13 12:47 ` James Bottomley
2025-10-13 13:02 ` Jürgen Groß
2025-10-15 18:05 ` Jeff Johnson
2025-10-16 16:47 ` Linus Torvalds
2025-10-13 12:21 ` Michael S. Tsirkin
2025-10-13 17:00 ` Linus Torvalds
2025-10-13 18:14 ` Paolo Bonzini
2025-10-13 18:53 ` Linus Torvalds
2025-10-13 20:12 ` Junio C Hamano
2025-10-13 21:44 ` Linus Torvalds
2025-10-13 23:22 ` Sasha Levin [this message]
2025-10-14 1:29 ` Linus Torvalds
2025-10-14 3:39 ` Willy Tarreau
2025-10-16 14:52 ` Geert Uytterhoeven
2025-10-16 15:08 ` Jason Gunthorpe
2025-10-16 15:33 ` Geert Uytterhoeven
2025-10-13 22:31 ` Paolo Bonzini
2025-10-14 6:47 ` Jiri Slaby
2025-10-13 21:59 ` Theodore Ts'o
2025-10-13 23:09 ` Michael S. Tsirkin
2025-10-14 1:23 ` Linus Torvalds
2025-10-14 10:38 ` Michael S. Tsirkin
2025-10-14 16:56 ` Linus Torvalds
2025-10-14 18:05 ` Luck, Tony
2025-10-14 18:41 ` Linus Torvalds
2025-10-14 19:09 ` Paolo Bonzini
2025-10-14 21:10 ` Jason Gunthorpe
2025-10-15 7:37 ` Geert Uytterhoeven
2025-10-15 7:33 ` Geert Uytterhoeven
2025-10-15 9:38 ` Miguel Ojeda
2025-10-15 12:11 ` Mark Brown
2025-10-15 13:50 ` James Bottomley
2025-10-15 13:59 ` Jürgen Groß
2025-10-15 15:08 ` Mark Brown
2025-10-15 15:14 ` Peter Zijlstra
2025-10-15 15:18 ` [workflows]Re: " Steven Rostedt
2025-10-15 15:53 ` Peter Zijlstra
2025-10-15 15:59 ` Steven Rostedt
2025-10-15 16:06 ` Peter Zijlstra
2025-10-15 16:15 ` Steven Rostedt
2025-10-15 16:43 ` Mark Brown
2025-10-15 16:15 ` Vlastimil Babka (SUSE)
2025-10-15 16:44 ` Steven Rostedt
2025-10-15 16:58 ` Konstantin Ryabitsev
2025-10-16 9:28 ` Matthieu Baerts
2025-10-15 17:01 ` Miguel Ojeda
2025-10-15 18:40 ` Laurent Pinchart
2025-10-16 7:32 ` Peter Zijlstra
2025-10-16 8:20 ` Vlastimil Babka (SUSE)
2025-10-16 13:58 ` Steven Rostedt
2025-10-15 14:37 ` Miguel Ojeda
2025-10-15 14:50 ` [workflows]Re: " Steven Rostedt
2025-10-15 13:51 ` Martin K. Petersen
2025-10-15 14:16 ` Konstantin Ryabitsev
2025-10-15 14:42 ` Miguel Ojeda
2025-10-15 15:03 ` Jason Gunthorpe
2025-10-15 14:55 ` [workflows]Re: " Steven Rostedt
2025-10-15 17:34 ` Martin K. Petersen
2025-10-15 14:51 ` Geert Uytterhoeven
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=aO2JoWLd0Mxc4oUV@laps \
--to=sashal@kernel.org \
--cc=junio@pobox.com \
--cc=konstantin@linuxfoundation.org \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=tools@linux.kernel.org \
--cc=torvalds@linuxfoundation.org \
--cc=users@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.