From: Jessica Yu <jeyu@kernel.org>
To: Will Deacon <will@kernel.org>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Matthias Maennich <maennich@google.com>,
gregkh@linuxfoundation.org,
Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] Kbuild updates for v5.4-rc1
Date: Tue, 17 Sep 2019 20:48:44 +0200 [thread overview]
Message-ID: <20190917184844.GA15149@linux-8ccs> (raw)
In-Reply-To: <20190917181636.7sngz5lrldx34rth@willie-the-truck>
+++ 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
next prev parent reply other threads:[~2019-09-17 18:48 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-15 13:27 [GIT PULL] Kbuild updates for v5.4-rc1 Masahiro Yamada
2019-09-17 15:09 ` Jessica Yu
2019-09-17 17:26 ` Masahiro Yamada
2019-09-17 18:01 ` Jessica Yu
2019-09-17 18:16 ` Will Deacon
2019-09-17 18:48 ` Jessica Yu [this message]
2019-09-20 3:38 ` Masahiro Yamada
[not found] ` <CAHk-=wggsTOU44tvdHAXBP-mmH+UJMXbJAdZYTOYD0PzPJntkg@mail.gmail.com>
2019-09-20 15:40 ` Linus Torvalds
2019-09-20 16:35 ` pr-tracker-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190917184844.GA15149@linux-8ccs \
--to=jeyu@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maennich@google.com \
--cc=torvalds@linux-foundation.org \
--cc=will@kernel.org \
--cc=yamada.masahiro@socionext.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.