Message-ID: <CAHk-=wihf7K7JhOsm2R6SSRbHuxzpMG+q87nVyD-jZnd+7-0gg@mail.gmail.com>
Date: Wed, 2 Apr 2025 17:06:09 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Miklos Szeredi <miklos@...redi.hu>
Cc: linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] fuse update for 6.15

On Tue, 1 Apr 2025 at 04:02, Miklos Szeredi <miklos@...redi.hu> wrote:
>
> Commit 1dfe2a220e9c ("fuse: fix uring race condition for null
> dereference of fc") in this queue has already been merged into
> v6.14-final through Christian's tree (commit d9ecc77193ca).   For some
> reason this causes a merge conflict, the resolution of which is to
> just take the version from this pull (i.e. remove the atomic_set()).

Yup, those "made in both branches" kinds of conflicts are trivial to resolve.

In case you wonder about the "for some reason" part: I say that they
are "trivial to resolve", but they are trivial to resolve only when
it's clear that you should take the *other* changes that the other
branch does.

So put another way: both branches did X (that "fix race condition"
thing) but as different commits, so they had separate history.

But then only one branch did Y (the "remove unneeded atomic set in
uring creation") that is right next to X.

Now, when I look at it and understand the semantics of the patch, I go
"oh, ok, both sides did X, but you also did Y, so I'll take that X+Y
thing". Simple.

But it's simple only because I understand the semantics of the
patches, and I see that I should take the union of the work.

git won't do that, because while there are "patch queue" systems that
do in fact use that exact logic of "both did patch X, the other side
also did patch Y", git is not a patch queue system - and I think patch
queue systems are actually wrong for anything more complicated.

So git will look at the original shared state, and the state of both
sides at the *end*, and make the merge decisions on that basis
(resolving things with a three-way merge if both sides did changes -
that's the simplified case for the simple history situation, at
least).

And in that model, you don't have "both did X, and then one side did
Y". You have "one side did A, the other side did B, and they weren't
the same".

I also will claim that it's the safer thing to do, because who knows
*why* one side did Y and the other side didn't? Without understanding
the semantics of Y, it's very much not clear.

For example, maybe the other side didn't do Y because Y was a quick
hack bug-fix to get things working, and instead simply fixed it at
some deeper level elsewhere that made the quick hack pointless and
possibly even wrong.

So just automatically doing some patch algebra can cause problems.

Of course, the git model of merging can *also* cause problems.

For an example of something that the git merge model will get wrong is
if both sides do 'X', but one side notices that 'X' was horribly buggy
and reverts it, and the other side doesn't.

Now when you merge the two, git will see "one side made no changes at
all, the other side did X" and at that point will merge 'X' and
basically undo the revert.

That *may* be the right thing to do. Again, maybe the other side
didn't revert because the other side fixed the bug properly. But the
*safe* thing would probably have been to treat it as that X+Y vs X
thing, and ask for manual intervention by marking it as a conflict.

But git won't do that, because git will see X+Y as being no change at
all, and then the logic is "one side did nothing, the other side did
new development, when you merge the two you obviously take the new
development".

And that's ignoring the whole issue with three-way merging that git
then does for when there are changes on both sides: it's a traditional
and generally very good strategy, but it can certainly also end up
doing mis-merges when there are semantic conflicts that don't show up
as overlapping changes.

End result: there are no automated merge models that always get the
right answer. The git merge model does work well, but there is no
perfect.

One good thing about the git model is that it tends to be fairly
simple to explain *why* it does something. It's not rocket science.
Merge conflicts really are fairly simple: both sides changed the same
area in different ways.

Of course, things get complicated when code movement or complex
history is involved. Or when the two changes simply clash on a
fundamental level and weren't at all about that kind of "A+B" vs "just
A" situation.

         Linus

Powered by blists - more mailing lists