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

From: Greg KH <gregkh@linuxfoundation.org>
To: Linus Torvalds <torvalds@linux-foundation.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: Sat, 4 Jun 2022 12:12:43 +0200	[thread overview]
Message-ID: <YpswG6Obmp4b3y66@kroah.com> (raw)
In-Reply-To: <CAHk-=wjTkU15iuSVrue_tRhD7=9v2YatrnFNxg=wEpT9-Szd4w@mail.gmail.com>

On Fri, Jun 03, 2022 at 11:07:46AM -0700, Linus Torvalds wrote:
> 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".

That makes more sense now, git is being "safe" by asking for the
developer to look and resolve it themselves.

thanks for the explanation.

greg k-h