On Sun, Oct 25, 2020 at 10:54 AM Linus Torvalds
<torva...@linux-foundation.org> wrote:
>
> On Fri, Oct 23, 2020 at 12:15 PM Micah Morton <mort...@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
