[Ksummit-2012-discuss] [ATTEND] stable kernel stuff and grumpy maintainers [bisection/rebase/-next]

James Bottomley James.Bottomley at HansenPartnership.com
Thu Jun 21 16:33:35 UTC 2012

On Thu, 2012-06-21 at 16:14 +0000, Luck, Tony wrote:
> > The other thing Linus always says on this issue is that it discards data
> > about where the changes were actually tested.  Mostly that shouldn't
> > matter but sometimes it might.
> In the case where the changes had a bug, does it really matter where
> those changes were tested? What will go upstream is something different
> (changeset + a bugfix tacked on the top). So I can't see how knowing that
> the buggy version was tested for N weeks at a particular starting SHA1
> helps at all.
> If the rebase just fixed a spelling error in a comment, or in the commit
> message ... and you rebase the patchset on top of some different point
> in the git history ... then I see how history of testing is lost.
> I do concede Stephen Rothwell's point that rebasing causes problems for
> other trees that pulled from a tree.

It's annoying, but fixable.  If you look at all my trees, they always
contain pairs of branches: <xxx> and <xxx>-base with no merges in
between them.  This makes rebasing them above changed trees very simple,

git checkout <xxx>
rebase --onto <new base> <xxx>-base
git branch -f <xxx>-base <new base>

Before anyone complains, the reason I arrange branches in pairs isn't so
I can rebase, it's so my automated tools around git trees (email and
patch diff generation) work.


More information about the Ksummit-2012-discuss mailing list