Messages in this thread | | | Date | Fri, 8 Aug 2014 13:21:35 +1000 | From | Stephen Rothwell <> | Subject | Re: [GIT PULL] Global signal cleanup |
| |
Hi all,
On Thu, 7 Aug 2014 08:53:56 -1000 Linus Torvalds <torvalds@linux-foundation.org> wrote: > > On Wed, Aug 6, 2014 at 9:35 PM, Richard Weinberger <richard@nod.at> wrote: > > > > It would be nice to see these rules written down somewhere. > > The rules have been pretty clear: "don't rebase public trees". > > That's always been the basic rule. There are _exceptions_ when > rebasing is the right thing to do, and they all boil down to "lesser > of two evils", but the evils really have to be pretty big. > > Possible reasons to rebase: > > (a) It's not public yet. You haven't pushed to kernel.org or any > other public site, and nobody saw you do it.
So this would not be in linux-next, so I don't care :-)
> (b) You *really* screwed up, and the downsides of rebasing are > smaller than the downsides of exposing it. > > As in "oops, that half-way commit doesn't even compile or work at > all, so leaving it in that state will screw up anybody trying to find > other bugs with 'git bisect'" > > At the same time, if you do this just before pushing to me, maybe > you should take a step back and say "oops, my tree was completely > broken, maybe I shouldn't push this to Linus just after fixing it".
And this is fine but shouldn't happen just before sending a pull request (as Linus said). But may also require informing anyone who depends on your tree (especially if that other tree is also in linux-next ... otherwise I could easily end up with both versions).
> (c) You want to clean things up, and you're not even remotely ready > to push things upstream, and while people have *seen* your work, > nobody relies on it or uses it.
And this should not be in linux-next yet, so again I don't care and shouldn't see it.
-- Cheers, Stephen Rothwell sfr@canb.auug.org.au [unhandled content-type:application/pgp-signature] | |