On Mon, Jun 2, 2014 at 12:33 PM, h...@infradead.org <h...@infradead.org> wrote:
>
> Linus has been very unappy about rebasing close to or in the merge
> window, and other subsystems generally revert patches that late in the
> cycle as well. I'd prefer to stick to that model, but if you and Linus
> prefer the rebase now I can do it as well of course.
I would indeed prefer to avoid rebases, _unless_ the tree is a real
mess without it.
Now, what constitues "real mess" can vary. It can be just really ugly
history, and part of that can be "it doesn't build or work at all
partway through". If it causes major build or boot failures the code
is *not* worth merging as-is, because that ends up being really
painful for bisection etc. But for it to matter for bisection, it has
to be a _major_ failure that actually matters to real people. So I'm
not talking about odd "make randomconfig" failures, but painful build
failures that actually hit reasonable configurations, and boot
failures that hit relevant hardware configurations.
Even in the absense of major build/working problems, "real mess" can
be about just horrible history with tons of stupid merges that just
makes it much harder to figure out what was going on.
So it's a judgment thing in the end, not a black-and-white "never
rebase". I don't know how core that revert is.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
