[Ksummit-2012-discuss] [ATTEND] stable kernel stuff and grumpy maintainers [bisection/rebase/-next]
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