linux-kernel - Re: [GIT PULL] zstd changes for v6.3-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 3 Mar 2023 10:05:33 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Nick Terrell <terrelln@...a.com>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Nick Terrell <nickrterrell@...il.com>
Subject: Re: [GIT PULL] zstd changes for v6.3-rc1

On Fri, Mar 3, 2023 at 9:59 AM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> You should not rebase your public trees.
>
> But you should not merge mainline either.

So lwn has several articles about this, the one I found quickly with google was

    https://lwn.net/Articles/791284/

and it's worth noting that the rule is "don't rebase" and "don't merge
from upstream", but as always, those are rules that then have to be
balanced against other rules and concerns.

Sometimes rebasing _is_ the right thing to do. Sometimes the public
history simply ended up being so full of garbage that the only right
thing to do is to just admit that and start again.

And sometimes merging from upstream _is_ the right thing to do. Maybe
there is something really important that made it upstream that is very
relevant.

But both situations need to be things that you really think about, and
have a reason for. And when you do a merge, that reason should very
much go into the merge message.

For rebases, there's no "rebase message", so those you basically have
to explain at pull time ("this was rebased last week to fix bad
problem XYZ").

              Linus