[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFz5YTwNHH9M3UuJ70_S8R6bbmPOqb8CA2soeGPaJ+i5ZQ@mail.gmail.com>
Date: Tue, 15 Mar 2016 22:04:10 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Jacek Anaszewski <j.anaszewski@...sung.com>
Cc: Stephen Rothwell <sfr@...b.auug.org.au>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux LED Subsystem <linux-leds@...r.kernel.org>,
amitoj1606@...il.com, ao2@....it, drivshin@...worx.com,
Geert Uytterhoeven <geert+renesas@...der.be>,
hkallweit1@...il.com, stefan.wahren@...e.com,
Wei Yongjun <yongjun_wei@...ndmicro.com.cn>
Subject: Re: [GIT PULL] LED subsystem updates for 4.6
On Tue, Mar 15, 2016 at 12:51 AM, Jacek Anaszewski
<j.anaszewski@...sung.com> wrote:
>
> I just wanted to make sure that no unexpected problem has occurred
> after rebasing onto 4.5 release. Is it in some way more advantageous to
> base a pull request on rc7, than on a final release?
I'd rather see the pull request based on whatever it has been tested
on, and just keep it that way.
Any rebasing will inevitably mean that you are basically throwing all
previous testing out the window (or at least make it dubious).
Rebasing also makes it much harder to see the history (for example,
compare it against previous linux-next trees), so the rule really
should be that you should never rebase unless you have a major reason
to do so.
So for example, if you actually find a problem, and you notice that
that problem comes not from your own changes, but from the base you
picked - *then* you'd want to rebase to a more stable base. But a
rebase "just because" is not a good idea.
I'll pull it, since it looks fairly harmless, but basically please
don't do that again.
Linus
Powered by blists - more mailing lists