lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 07 Aug 2014 22:47:04 +0200
From:	Richard Weinberger <>
To:	Linus Torvalds <>
CC:	Stephen Rothwell <>,
	"" <>,
	Linux-Arch <>
Subject: Re: [GIT PULL] Global signal cleanup

Am 07.08.2014 20:53, schrieb Linus Torvalds:
> On Wed, Aug 6, 2014 at 9:35 PM, Richard Weinberger <> 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 or any
> other public site, and nobody saw you do it.
>      You can rebase to your hearts content, although you should still
> use sane logic (ie don't rebase on top of random "merge window kernel
> of the day" for example: choose a good starting point, like a previous
> release, or something else that makes sense)
>    "git rebase" is a great tool for a developers own _private_ data.
> It's a great way to split patches up in smaller pieces, or to combine
> half-way work, or to re-order patches to be more logical. And as long
> as you're doing development on your own, there are no downsides as
> with the whole next confusion.
>  (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".
>  (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.
>      In other words, your branch was a "Work-in-Progress", and you
> preferably let people know it was that.
>      Again, rebasing just before pushing to me is *not* good. See the
> "really screwed up" thing. If it was WIP code, it doesn't suddenly
> become release-quality just because you rebase it.
> There may be other reasons, but those are the three main ones. In
> general, "rebase just before asking somebody to pull" is just a bad
> idea. It either fixed some big problem (in which case it should have
> gotten more time before being pushed), or it fixes something truly
> trivial (in which case the downsides of sudden rebases outweigh the
> upsides).

Thanks for the clarification.

Here is what happened:

Branch signal_v4 is in linux-next, it never got rebased.
While preparing the pull request I noticed that some of the patches gained new acks
from various architectures.
So I took the *local* copy of signal_v4 added these acks using git rebase and rebased them to v3.16.
Then I've pushed that branch to signal-cleanup and sent you the request.
signal-cleanup did not exist before that.
My fault was rebasing my work from v3.16-rc6 to v3.16 before pushing it.
It won't happen again. But I never did a push -f or something like that.

If you feel better you can still pull from:
git:// signal_v4

It is the as-is branch from linux-next.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists