Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <6809750d3e746fb0732995bb9a0c1fa846bbd486.camel@hammerspace.com>
 <CAHk-=wjvNb9GVdbWz+xxY274kuw=xkYBoBYHHHO7tscr1V0YAQ@mail.gmail.com> <448e0f2b96b7fa85f1dd520b39a24747ea9487ed.camel@hammerspace.com>
In-Reply-To: <448e0f2b96b7fa85f1dd520b39a24747ea9487ed.camel@hammerspace.com>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Fri, 9 Jul 2021 10:09:08 -0700
Message-ID: <CAHk-=wjLAQPisWbcoc+YcUdtLp87TMc29bETJrS4f6pjoAAy5Q@mail.gmail.com>
Subject: Re: [GIT PULL] Please pull NFS client changes for 5.14
To:     Trond Myklebust <trondmy@hammerspace.com>
Cc:     "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Fri, Jul 9, 2021 at 9:55 AM Trond Myklebust <trondmy@hammerspace.com> wrote:
>
> Thanks! It didn't result in any overall code changes or even changes to
> the result of the merges. However if you're OK with the occasional
> duplicate patch then I'll make sure to avoid this in the future.

The occasional duplicate patch is actually completely normal.

Particularly when it is something like an important fix that gets
pushed to mainline late in the -rc series: people often want them in
their development trees as well for testing, and so you end up with
the same fix both in mainline and in the "for next merge window"
branch.

In fact, that "important fix that goes to both branches" can be a very
good thing, exactly because you want to test that -next branch, and
you want to do it without having to worry about old bugs that might
trigger or hide new issues.

And then I very much want to pull that _tested_ development branch,
not some "ok, I removed that fix from the branch before asking Linus
to pull, because it's already in his tree".

See?

And yes, sometimes they happen by mistake, and the duplication is not
intentional, and it's not some "good thing". It happens just because
the same patch was sent two different ways.

That's fine too.

It's a problem if they happen a _lot_ - partly because they do make it
much more likely to cause pointless merge conflicts (and mistakes can
happen during that stage), but even more because it shows that
something is going wrong in the patch management, and people are
stepping on each other's feet.

So then the duplicate patches is not necessarily a _technical_
problem, but it's indicative that something is wrong with patch flow.

But even then removing the duplicate patches is generally less
important than trying to fix the maintenance issue.

So on the whole, a couple of duplicate patches isn't a big deal, and
not worth rebasing.

Aim to keep rebasing mainly for "oh, keeping that will cause actual
problems" (and sometimes the "actual problems" can be about things
like truly horribly mangled commit messages and wrong attribution
etc).

So rebasing isn't necessarily always "wrong", but it just needs to
have a fairly compelling reason.

              Linus