Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20210319082939.77495e55@canb.auug.org.au> <YFTJdL1yDId+iae4@unreal>
 <65e47dcc-702b-98e0-2750-d5b11a7c0ae1@pengutronix.de>
In-Reply-To: <65e47dcc-702b-98e0-2750-d5b11a7c0ae1@pengutronix.de>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Sat, 20 Mar 2021 12:42:06 -0700
Message-ID: <CAHk-=wgmL3qJhjnoG1z9kH-N0RokWOHATRjPyLWGx=U7Ar-1qA@mail.gmail.com>
Subject: Re: linux-next: manual merge of the net tree with Linus' tree
To:     Marc Kleine-Budde <mkl@pengutronix.de>
Cc:     Leon Romanovsky <leon@kernel.org>,
        Stephen Rothwell <sfr@canb.auug.org.au>,
        David Miller <davem@davemloft.net>,
        Networking <netdev@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Linux Next Mailing List <linux-next@vger.kernel.org>,
        Stephane Grosjean <s.grosjean@peak-system.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Sat, Mar 20, 2021 at 12:28 PM Marc Kleine-Budde <mkl@pengutronix.de> wrote:
>
> Good idea. I'll send a pull request to David and Jakub.

I don't think the revert is necessary. The conflict is so trivial that
it doesn't really matter.

Conflicts like this that are local and obvious aren't really
problematic. Any maintainer pulling git trees will have seen them and
is used to them (admittedly probably me and Stephen more than most,
but still).

The conflicts that can be pretty painful and might be worth worrying
about ahead of merge time - or at least let the maintainer/me know
about loudly when you ask them/me to pull - are the ones that might
not even show up as a file conflict. The conflict might be purely
semantic rather than some simple "changed lines next to each other"
kind of thing.

Often even those are trivial, but they might fly under the radar. Many
of them cause build issues (think "changed arguments to or renamed a
function" on one side, "added new use of function" on the other side),
but not all do, And even if they do, they might do so only under
certain configurations and architectures, of course.

And occasionally there are conflicts that are just so *big* that they
are painful to work through (things like renaming variables and moving
code on one side, and then non-trivial changes on the other side).
They can look particularly scary when you see the conflict diff, but
on the whole it's unusual that it's a real problem. I reasonably often
ask people to verify my merge "just in case", but it's seldom actually
a big issue. I don't remember the last time I actually went back to a
maintainer and said "ok, this looks too nasty, please actively help me
out".

In fact, the most common conflict problem is not that the conflict is
_hard_ - it's that some coding patterns are just _annoying_ when they
cause conflicts.

Things like big whitespace cleanups across whole subdirectories get
_really_ old as you're working on the fifth file that has a conflict
due to the same silly syntactic change.

But something like this that just removes the
MODULE_SUPPORTED_DEVICE() thing that basically never gets touched
anyway, and we happened to be unlucky in *one* file? Not a worry at
all.

                   Linus