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@xxxxxxxxxxxxxxxxxxx> 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
