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

From: Palmer Dabbelt
Date: Fri Sep 01 2023 - 11:52:42 EST

On Fri, 01 Sep 2023 08:21:35 PDT (-0700), Linus Torvalds wrote:
On Fri, 1 Sept 2023 at 07:41, Palmer Dabbelt <palmer@xxxxxxxxxxxx> 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").

Thanks, Nick had pointed that out too but looks like I missed it.

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:

Ya, I'm always interested to hear -- as I'm sure you can tell it's still a bit of a mystery on my end, but I'd rather learn when I get lost than just keep being lost ;)

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.

OK, that explains why I get such different results between the pre and post merge output -- my workflow involves commiting a merge and then pushing it up to the test builders, so I guess I should just be double-checking the pre-merge rather than trying to figure things out after the fact from just looking at the merge.

Linus