Message-ID: <CAK7LNARxmDwu4QmV3bRBtptu-jUaHum=hHaia11-vmOd2ZkeKw@mail.gmail.com>
Date:   Fri, 20 Sep 2019 12:38:40 +0900
From:   Masahiro Yamada <yamada.masahiro@...ionext.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Will Deacon <will@...nel.org>,
        Matthias Maennich <maennich@...gle.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Jessica Yu <jeyu@...nel.org>
Subject: Re: [GIT PULL] Kbuild updates for v5.4-rc1

Hi Linus,

On Wed, Sep 18, 2019 at 3:48 AM Jessica Yu <jeyu@...nel.org> wrote:
>
> +++ Will Deacon [17/09/19 19:16 +0100]:
> >Hi Jessica,
> >
> >On Tue, Sep 17, 2019 at 08:01:36PM +0200, Jessica Yu wrote:
> >> Yikes, I did not catch Stephen Rothwell's email about pausing the
> >> linux-next releases from Sept 5 until Sept 30
> >> (https://lore.kernel.org/linux-next/20190904233443.3f73c46b@canb.auug.org.au/).
> >>
> >> The modules-next namespace patches have been in since last Tuesday,
> >> and my original plan was for them to catch at least a week of
> >> linux-next time before sending the pull request. :-/ But that did not
> >> happen due to the above.
> >>
> >> So Linus, in light of the above realization, I'd say at this time - I
> >> will still formally send a pull request with the merge conflicts
> >> resolved with either solution #2 or #3, but merge at your own
> >> discretion, it's fine to delay to the following release if you're
> >> uncomfortable.
> >
> >FWIW, when I've run into unexpected merge conflicts with other trees in the
> >past, I've found that it's usually sufficient just to include the resolution
> >as an inline diff in the pull request, rather than try to munge the tree
> >with merges or rebases.  Linus is pretty good at figuring it out, and with a
> >resolution to compare with, the damage is limited. The downside of the merge
> >is that it's fiddly to extract the changes and see what's actually being
> >pulled.
> >
> >Also, it's not like the kbuild stuff has been in -next for ages, so this
> >would've been a late and messy conflict regardless.
>
> Hi Will!
>
> Thanks a lot for the advice :-) The inline diff sounds like a good
> idea. This is I believe only the second tree conflict I've encountered
> so far so the tips are much appreciated.
>
> Jessica


How should we handle this?

If you pull this against the latest of your tree,
you will end up with manual merge for the following files:

scripts/link-vmlinux.sh
drivers/gpu/drm/amd/display/dc/calcs/Makefile
drivers/gpu/drm/amd/display/dc/dml/Makefile
drivers/gpu/drm/amd/display/dc/dsc/Makefile


They are solved in linux-next,
but I also double-checked it just in case.

I think the next-20190917 is correct,
but I noticed two things:


[1] linux-next modified the hashbang of scripts/link-vmlinux.sh
    (/bin/sh -> /bin/bash), but this change is unneeded

[2] I fixed up drivers/gpu/drm/amd/display/dc/dcn21/Makefile too.
    This is a non-obvious conflict, and not available in linux-next.
    I caught it in my build testing.


I solved the merge conflicts by myself,
and I attached the diff file.  (merge-diff.txt)


If you do not want to cope with those merge conflicts at all,
I will drop the three commits (8959e39272   54b8ae66ae  69a94abb82),
and I will re-send a pull request, which you will be able to pull cleanly.
I will rebase the offending 3 commits on top of your tree later.


Which do you prefer?
Please let me know your thought.

Thanks.


--
Best Regards
Masahiro Yamada

View attachment "merge-diff.txt" of type "text/plain" (9782 bytes)

Powered by blists - more mailing lists