Re: [GIT PULL] CIFS/SMB3 fixes

[Linus Torvalds]

On Wed, May 8, 2019 at 11:32 AM Steve French <smfrench@xxxxxxxxx> wrote:
>
>    [..] Our
> build verification tests passed (and continue to be extended to
> include more tests).  See e.g. our 'buildbot' results at:
> http://smb3-test-rhel-75.southcentralus.cloudapp.azure.com/#/builders/2/builds/199

Still, is there any reason for that very late rebase?

Why are all the commits so recent?

And perhaps even more importantly, why is the base for that rebase is
some completely random and inappropriate commit in the middle of the
merge window?

That's *INSANE*. And it's against everything I've always told people to do:

    DO NOT BASE YOUR DEVELOPMENT WORK ON SOME RANDOM "KERNEL OF THE DAY"
    DURING THE MERGE WINDOW !!

who knows what horrendous bugs we've introduced at that random point
in the merge window, and you now based all your work on that unstable
random commit.

There is *no* excuse for this kind of crazy development. Even if you
use something else than git to develop (some patch-queue based
inferior system or whatever) and even if you then import it into git
later

     PICK A SANE AND STABLE IMPORT POINT

and if you *do* use git for development, but you have to rebase
because you've made some silly mistake and need to undo something

    PICK A SANE AND STABLE REBASE POINT

I don't know how much clearer I can be about this, and I do not
understand why this keeps on happening. We've been using git for just
about 15 years now, and I've said this for pretty much all that time.

Some random googling found this lwn article based on some random old
email of mine from ten years ago:

    https://lwn.net/Articles/328436/

and while it is about general rebasing and merging issues, it does
talk about how to "allow development to be based on a (hopefully)
relatively stable point where the issues are known". That is as
important for a rebase point as it is for a merge point.

Rebasing on top of random kernel versions should not be done. EVER.

And if you did it to avoid some merge conflict, DON'T. I'd much rather
get a pull request for something that is *STABLE* and *WELL-TESTED*,
than get a pull request that has been syntactically cleaned up, but is
based on something that might not work at all under certain
circumstances.

Even if *your* code were to be perfect, that doesn't matter if the
thing you based your code on is a quicksand of memory corruption and
general flakiness.

So don't do the whole "rebase the day before" in the first place, but
*DEFINITELY* don't do it when you then pick a random and bad point to
rebase things on top of!

                   Linus