[GIT PULL] RISC-V Patches for the 6.6 Merge Window, Part 1

[Linus Torvalds]

On Fri, 1 Sept 2023 at 07:41, Palmer Dabbelt <palmer at rivosinc.com> wrote:
>
> for the other the result I ended up with was
>
> extern pgd_t early_pg_dir[PTRS_PER_PGD];
> static pgd_t tmp_pg_dir[PTRS_PER_PGD] __page_aligned_bss;
> static p4d_t tmp_p4d[PTRS_PER_P4D] __page_aligned_bss;
> static pud_t tmp_pud[PTRS_PER_PUD] __page_aligned_bss;

That's wrong, you should have removed the 'early_pg_dir' declaration
that is now in <asm/pgtable.h>, as done by commit d2402048bc8a
("riscv: mm: fix 2 instances of -Wmissing-variable-declarations").

> though that's not showing up in the git diff, so I may have something odd going
> on here.

So what's going on is that you resolved the merge conflict by taking
everything from one side (not correct, as above), and then git no
longer considers it a conflict after-the-fact.

Side n ote in case you care about the actual git logic:

The git rules for merge conflicts are different when doing the merge
and when showing the result after doing a merge.

When doing the merge, git will do the expensive history calculations
to figure out the merge base and do a 3-way merge of the base and the
two sides.

So at merge time, git looks back in the history from the two merge
heads, and does the three-way diff based on the history leading up to
the two points.

But after the merge, "git show" will basically do the reverse: it
won't look back in the history, but look at the *result* of the merge.
You are, after all, asking it to show the merge itself.

So then it will again do a three-way diff, but not of the merge base,
but of the merge _result_ and the two sides.

And if the merge result is the same as one of the sides, there's no
conflict remaining, and so no three-way diff.

So that's how conflicts sometimes "disappear" after the merge.

                       Linus