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

[Namjae Jeon]

On Fri, Apr 17, 2026 at 1:05 PM Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> 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.
Thank you for the clear and detailed explanation! I was confused about
how to handle those merge issues, but your guidance has made it very
clear for me. I will resubmit v2 PR soon.