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

[Palmer Dabbelt]

On Fri, 01 Sep 2023 08:21:35 PDT (-0700), Linus Torvalds wrote:
> 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").

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