Messages in this thread | | | From | Linus Torvalds <> | Date | Fri, 1 Sep 2023 08:21:35 -0700 | Subject | Re: [GIT PULL] RISC-V Patches for the 6.6 Merge Window, Part 1 |
| |
On Fri, 1 Sept 2023 at 07:41, Palmer Dabbelt <palmer@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
| |