Re: [GIT PULL] ntfs updates for 7.1-rc1

From: Linus Torvalds

Date: Fri Apr 17 2026 - 00:05:10 EST


On Thu, 16 Apr 2026 at 20:24, Namjae Jeon <linkinjeon@xxxxxxxxxx> wrote:
>
> I apologize for the oversight. I clearly misunderstood the proper way
> to handle these semantic conflicts and broke the bisectability of my
> own tree. I will rebase the patches on top of the latest upstream,
> ensure that each commit builds correctly on its own, and resubmit the
> pull request.

No, please don't make things worse by rebasing.

Just *remove* the patches that broke the build and tried to deal with
the merge ahead of time. It needs to build for *you*, not for me.

And it should not be rebased. That just means that all the testing got
thrown out the window.

Your job is to make sure that your tree is as stable as it can be. Not
*my* tree. Your. Don't rebase on top of the quicksand that is the
current merge window. That only means that your tree will be based on
possibly horribly buggy state, and now you made your tree actively
worse.

So what I really want maintainers to do is to care about *their*
trees. Those should be as rock solid and well-tested as possible. Your
job as maintainer is to care about your code, and my job as an
integrator is to then make sure your code works together with other
peoples changes.

And if I then screw up merging, that's on _me_, and I will not blame
you for mistakes I do.

[ And as always - nothing is ever entirely black-and-white.
Submaintainers work together too, often very intentionally, using
tools like shared stable branches etc. So that "make your own tree as
stable as can be" is a simplified first approximation, but it's a good
starting point ]

Now, you should care about the merged state only in the sense that
when Mark Brown tells you that there was a merge conflict, you may
need to help him resolve the conflict (although about 99.9% of the
time, I think Mark will just resolve it and say "this is now solved as
far as linux-next is concerned").

And then you should just keep it in mind, and let me know about what
happened in linux-next. Not try to _fix_ it, because the fixes will
involve solving things that are only relevant when merged, but just
let me know.

Of course, anything that linux-next finds that is actually a problem
in *your* tree needs to be fixed by you before asking me to pull -
again with the whole "you need to make *your* tree as stable and well
tested as possible. The above "let me know" is not about those kinds
of issues, but about merge-related issues that get reported from
linux-next.

Linus