[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.00.0904051251390.4023@localhost.localdomain>
Date: Sun, 5 Apr 2009 12:56:48 -0700 (PDT)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Ingo Molnar <mingo@...e.hu>
cc: linux-kernel@...r.kernel.org,
Pekka Enberg <penberg@...helsinki.fi>,
Steven Rostedt <rostedt@...dmis.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
Eduard - Gabriel Munteanu <eduard.munteanu@...ux360.ro>
Subject: Re: [GIT PULL] SLAB include file dependency fixes + kmemtrace
updates
On Sun, 5 Apr 2009, Ingo Molnar wrote:
>
> ( Please note that i rebased the tree exactly once, shortly after it
> got finished, to make it all bisectable and reviewable: the
> perfect insight shown in the tree now was IMHO not humanly
> possible to achieve in advance.
This is actually the rigth thing to do. Rebasing is not wrong, if it is
done judiciously (and not on already-exposed stuff).
Rebasing is bad if
- you do it so late in the game that all test experience is basically
worthless
- after you've pushed out and other people have seen and depend on that
branch (and you didn't warn them)
- you do it to other peoples git commits, so that their tree (that was
the source of the commit) now has the same commit duplicated as
something else.
I wrote a posting about rebasing to Dave Airlie on dri-devel, that might
be googleable. Hmm. Here:
http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html
so rebase isn't bad, it's often a great way to fix things as you go along.
It just goes with a few basic caveats.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists