Re: regulator branch mess

["Theodore Ts'o" <tytso@mit.edu>]

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