[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wgo40oeh3huHvb64KfeNEYXw_hQXLXqujbhYz18TMZ6ZA@mail.gmail.com>
Date: Mon, 3 May 2021 11:27:02 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: LKML <linux-kernel@...r.kernel.org>,
Bhaskar Chowdhury <unixbhaskar@...il.com>,
Cao jin <jojing64@...il.com>,
Colin Ian King <colin.king@...onical.com>,
Ingo Molnar <mingo@...nel.org>,
Qiujun Huang <hqjagain@...il.com>,
Wan Jiabing <wanjiabing@...o.com>, Xu Wang <vulab@...as.ac.cn>,
"Yordan Karadzhov (VMware)" <y.karadz@...il.com>
Subject: Re: [ GIT PULL] tracing: Updates for 5.13
On Mon, May 3, 2021 at 6:17 AM Steven Rostedt <rostedt@...dmis.org> wrote:
>
> Colin Ian King (1):
> ftrace: Fix spelling mistake "disabed" -> "disabled"
Well, that spelling fix didn't fix the other misspelled word right next to it.
> This is the first time I'm sending a pull request with a merge
> in it. I'm hoping my scripts did everything correctly. Might want
> to check it a bit more than usual.
The merge looks fine. It causes the diffstat to show incorrectly,
which is normal (and generally avoided by you doing a test merge so
that you get the diffstat from the merged state - but don't send the
merge itself to me, just use it to (a) look at what conflicts there
will be and (b) get that correct diffstat for the end result).
That said, if the only reason for the merge was one single trivial
commit, you could just have cherry-picked it instead, avoiding the
things like "oh, now it has two merge bases so 'diff' no longer has an
unambiguous result" etc.
But this is fine. If you start doing a lot of merges, I may really ask
you to then also do that test-merge for the pull request, but if it's
one of these "once in a blue moon" things then don't worry about it.
Linus
Powered by blists - more mailing lists