Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <CAJ-EccOQxDjSgUL0AsCywoKDbOUNWDyxCKHQc+s6+ZemUh9Uzw@mail.gmail.com>
 <CAHk-=wg3kHxMP67XmQyCg7J+KfFgAsQqj1goUa3dKR-A812ZbA@mail.gmail.com>
 <CAJ-EccPLAD5TGg=KQ-m54ymrVdd++Dg7A_UR+v535iOVRsDe4w@mail.gmail.com>
 <CAHk-=wi_BD0OVHgj09kKgiuwyrth3ora_ZgLznW_q-+z-BR=3w@mail.gmail.com>
 <CAJ-EccMu_AGfOYASyteGosdOc1SMHeVTLax5aoZSQf7_n0Xq2Q@mail.gmail.com> <CAHk-=whAYrg_N9ZZ38C5YqPQT4eyCj8JoJ4oax479DpOkdH07w@mail.gmail.com>
In-Reply-To: <CAHk-=whAYrg_N9ZZ38C5YqPQT4eyCj8JoJ4oax479DpOkdH07w@mail.gmail.com>
From:   Micah Morton <mortonm@chromium.org>
Date:   Tue, 27 Oct 2020 09:14:41 -0700
Message-ID: <CAJ-EccMyjD+DudaanLwQErKRwkA_h12ZMDL-5R3JMADaYK4+rg@mail.gmail.com>
Subject: Re: [GIT PULL] SafeSetID changes for v5.10
To:     Linus Torvalds <torvalds@linux-foundation.org>
Cc:     Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        linux-security-module <linux-security-module@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Sun, Oct 25, 2020 at 10:54 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Fri, Oct 23, 2020 at 12:15 PM Micah Morton <mortonm@chromium.org> wrote:
> >
> > Ok so before the rebase ("reparent"), the commits were based on top of
> > some commit that was months old at this point (can't quite remember
> > now, I think one of the -rc's for v5.8).
>
> Nobody cares if the old parent is old. In fact, that's usually a good
> sign that the code has had testing and is changing things that aren't
> in flux for other reasons.

Ok thanks for the explanation, I think this was the most important
piece I was missing, but makes sense now.

>
> It's often a good idea to make a test-merge and verify that things are
> ok, but that's for your _personal_ verification, and shouldn't be
> something that anybody else sees.
>
> And even with a test-merge, it doesn't matter if there is some simple
> conflict - we have those all the time, and conflicts aren't bad. In
> fact, they allow me to see "ok, things have changed here in parallel",
> and I'll be aware of it.
>
> The main reason to rebase is if things have changed _so_ much that you
> really need to re-do things, or if there is some major bug in _your_
> branch that simply needs to be fixed.

Yeah sounds good, I'll just get in the habit of doing a test merge and
note in the pull request whether there are any conflicts or not.

>
> >    So I had basically considered it
> > a no-op rebase. I probably should have explained this in the pull
> > request.
>
> If it's a no-op rebase, thern DON'T DO IT. Really. It just means that
> now you have lost all the testing.
>
> Thinking that it's a no-op doesn't really help. No bugs are
> _intentional_, I would seriously hope. Lack of testing is lack of
> testing, regardless of whether you think it would not matter.
>
> It also destroys the real history of the code, which is sad.
>
> Now, sometimes you may _want_ to destroy the real history of the code
> (as in "Oh, this history is too ugly to survive, and makes bisection
> impossible because some of the intermediate state was seriously
> buggy"). That is then one of those few valid reasons to rebase (see
> the "major bug in your branch" case above).
>
> But 99% of the time, rebasing is bad. If it was in linux-next and
> there were no horrible problems with it, and it got tested there, then
> just leave it alone and don't destroy the testing it did get.
>
> Anyway, I've pulled this now, but honestly, don't do this again. Stop
> rebasing without a big and immediate reason, and stop destroying
> whatever testing it got in linux-next.

Got it.

>
> And if you _do_ rebase, and you _do_ have a real and very serious
> reason, then mention that reason and explain it. But no "the rebase
> didn't make any difference" isn't a reason. Quite the reverse.
>
>                Linus
>
>                    Linus