[Ksummit-2012-discuss] [ATTEND] stable kernel stuff and grumpy maintainers [bisection/rebase/-next]
swarren at wwwdotorg.org
Thu Jun 21 16:25:32 UTC 2012
On 06/21/2012 10:14 AM, 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.
But are other trees supposed to be pulling from them without co-ordination?
I guess there are two different cases:
1) Another Linux subsystem maintainer needs to pull in changes from
another subsystem to resolve dependencies. This definitely should
require co-ordination, if for nothing else than courtesy.
With an absolutely strict no-rebasing rule, just pulling in other
branches might be safe. However, in the absence of that, the owner of
the pulled branch has to be able to 100% guarantee that it won't be
rebased once it's included elsewhere. Currently, that guarantee is done
my manual agreement in specific cases.
2) "Random" people developing on top of a subsystem. This of course
needs to happen with no co-ordination; that's kinda the point of
distributed development and git. However, what's the difference between
requiring people to:
git rebase foo/branch
git rebase foo/branch previous-head-of-foo/branch
Since I tend to base my local work on linux-next anyway (due to my work
often touching multiple subsystems), I always use the second command
above anyway. git makes this work really well. That said, perhaps people
dislike that workflow?
More information about the Ksummit-2012-discuss