linux-kernel - Re: regulator branch mess

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20251105150812.GB2968640@mit.edu>
Date: Wed, 5 Nov 2025 10:08:12 -0500
From: "Theodore Ts'o" <tytso@....edu>
To: Andy Shevchenko <andriy.shevchenko@...el.com>
Cc: Mark Brown <broonie@...nel.org>, Liam Girdwood <lgirdwood@...il.com>,
        linux-kernel@...r.kernel.org
Subject: Re: regulator branch mess

On Wed, Nov 05, 2025 at 07:24:50AM +0200, Andy Shevchenko wrote:
> Yep, less confusing. The problem of the confusion here is the merge commit
> text, that only describes the merge of the small series but also implies bump
> from v6.18-rc3 to v6.18-rc4. Other subsystems I follow usually do an explicit
> back-merges to the rcX whenever is needed. But as I told Mark, I'm fine if
> that was a deliberate (known) move. Now it's all clear.

So what I do is I have an "origin" branch which shows the base on
which my dev series is based.  I use a rewinding workflow where I do
regularly do rebases to add Fixes: and Reviewed-by: tags, et. al.
There will be times when an upstream bugfix in some other file system
(say, vfs and mm) is affecting my testing, so I'll do a fast-forward
of my origin branch to the next rcX, and then do a rebase of my dev
branch on the new dev branch.

If there's a bug that I find before I send a pull request to Linus,
I'll fold the fix into the buggy commit, which can also avoid
potential problems when people are bisecting Linus's tree.

Since one of the goals of my using a rewinding/rebasing workflow is to
keep the dev branch clear, I consider back merges to be noise that
future kernel developers would not appreciate being permanently
preserved in Linus's tree.

I know there are some people who believe that git history should be
immutable, and should never, ever be rewound.  It's a tradeoff, and
different maintainers will use different workflows.

Cheers,

						- Ted