Re: [GIT PULL] Staging driver updates for 5.19-rc1

From: Linus Torvalds <torvalds@linux-foundation.org>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-staging@lists.linux.dev
Subject: Re: [GIT PULL] Staging driver updates for 5.19-rc1
Date: Fri, 3 Jun 2022 11:07:46 -0700	[thread overview]
Message-ID: <CAHk-=wjTkU15iuSVrue_tRhD7=9v2YatrnFNxg=wEpT9-Szd4w@mail.gmail.com> (raw)
In-Reply-To: <Ypng29bf0vGJ20fo@kroah.com>

On Fri, Jun 3, 2022 at 3:22 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> Note, you will have a merge conflict in the
> drivers/net/wireless/silabs/wfx/sta.c file, please just take the change
> that came in from the wifi tree.  We thought as I had pulled the same
> merge point from the wifi developers this type of conflict wouldn't have
> happened, but for some reason git flags it as something to pay attention
> to and couldn't resolve it itself.

That "some reason" is because the networking tree made other changes
to the file since (ie commit 2c33360bce6a: "wfx: use container_of() to
get vif").

So both branches had done the same change (the merge), but one branch
had then done other changes on top of that same change.

Broken SCM thinking then thinks that means that "oh, then we obviously
have to take the extra change" (eg darcs "patch algebra"), and make
that the basis of their resolution strategy. It's not actually a valid
model, because it just assumes that the additional patches were right.
Maybe there was a _reason_ that extra patch wasn't done in the other
branch? The extra patch might have been due to particular issues in
that branch, you can't just make the darcs assumption of reordering
patches and taking some union of them (which is an over-simplification
of the patch algebra rules).

Now, that's not to say that git can't get things wrong too when
resolving things. But at least it doesn't make some fundamental
mistake like that.

The git rules are basically that it will resolve changes that aren't
overlapping, using the traditional 3-way model (it then has that whole
"recursion and rename detection" thing, but that's more of a
higher-level metadata thing separate from the actual code merge).

So git doesn't assume any "semantics" to the changes. If it sees that
two branches changed the same code in different ways, git will go
"this is a conflict", and leave it to human (or scripted)
intervention.

Again, it's not that the git model is always right - you can obviously
have changes that do *not* overlap at all, but still have a very
fundamental semantic conflict, and git will happily merge those things
and think it is all good.

So the git model is basically practical and straightforward (also
"stupid", but in a good way - do the common truly obvious 3-way
merges, don't try to do anything clever when that fails). There's no
"theory" behind it that might turn out to be completely wrong.

Anyway, the conflict was trivial, but I thought I'd just explain both
the immediate "why did it conflict" _and_ the more abstract "why did
git make that choice".

                     Linus