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").
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