linux-security-module.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Micah Morton <mortonm@chromium.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-security-module <linux-security-module@vger.kernel.org>
Subject: Re: [GIT PULL] SafeSetID changes for v5.10
Date: Sun, 25 Oct 2020 10:54:31 -0700	[thread overview]
Message-ID: <CAHk-=whAYrg_N9ZZ38C5YqPQT4eyCj8JoJ4oax479DpOkdH07w@mail.gmail.com> (raw)
In-Reply-To: <CAJ-EccMu_AGfOYASyteGosdOc1SMHeVTLax5aoZSQf7_n0Xq2Q@mail.gmail.com>

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.

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.

>    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.

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

  reply	other threads:[~2020-10-25 17:54 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-15 18:15 [GIT PULL] SafeSetID changes for v5.10 Micah Morton
2020-10-15 23:06 ` Linus Torvalds
2020-10-16  0:01   ` Micah Morton
2020-10-23 17:57     ` Linus Torvalds
2020-10-23 19:14       ` Micah Morton
2020-10-25 17:54         ` Linus Torvalds [this message]
2020-10-27 16:14           ` Micah Morton
2020-10-25 18:35 ` pr-tracker-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHk-=whAYrg_N9ZZ38C5YqPQT4eyCj8JoJ4oax479DpOkdH07w@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mortonm@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).