[GIT PULL] Global signal cleanup

[GIT PULL] Global signal cleanup

[Richard Weinberger]

[-- Attachment #1: Type: text/plain, Size: 5493 bytes --]

Linus,

the following changes since commit 19583ca584d6f574384e17fe7613dfaeadcdc4a6:

  Linux 3.16 (2014-08-03 15:25:02 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rw/misc.git signal-cleanup

for you to fetch changes up to 059ade650ae57cfd371af690fdba887af04aded8:

  powerpc: Use sigsp() (2014-08-06 13:04:32 +0200)

----------------------------------------------------------------
This patch series moves all remaining archs to the get_signal(), signal_setup_done()
and sigsp() functions. Currently these archs use open coded
variants of the said functions. Further, unused parameters get removed
from get_signal_to_deliver(), tracehook_signal_handler() and signal_delivered().
At the end of the day we save around 500 lines of code.
----------------------------------------------------------------
Richard Weinberger (43):
      arc: Use get_signal() signal_setup_done()
      arm64: Use get_signal() signal_setup_done()
      avr32: Use get_signal() signal_setup_done()
      blackfin: Use get_signal() signal_setup_done()
      c6x: Use get_signal() signal_setup_done()
      cris: Use get_signal() signal_setup_done()
      frv: Use get_signal() signal_setup_done()
      hexagon: Use get_signal() signal_setup_done()
      ia64: Use get_signal() signal_setup_done()
      m32r: Use get_signal() signal_setup_done()
      m68k: Use get_signal() signal_setup_done()
      microblaze: Use get_signal() signal_setup_done()
      mips: Use get_signal() signal_setup_done()
      mn10300: Use get_signal() signal_setup_done()
      parisc: Use get_signal() signal_setup_done()
      powerpc: Use get_signal() signal_setup_done()
      s390: Use get_signal() signal_setup_done()
      score: Use get_signal() signal_setup_done()
      sh: Use get_signal() signal_setup_done()
      tile: Use get_signal() signal_setup_done()
      um: Use get_signal() signal_setup_done()
      unicore32: Use get_signal() signal_setup_done()
      xtensa: Use get_signal() signal_setup_done()
      tracehook_signal_handler: Remove sig, info, ka and regs
      Clean up signal_delivered()
      Rip out get_signal_to_deliver()
      sas_ss_flags: Remove nested ternary if
      arc: Use sigsp()
      arm64: Use sigsp()
      avr32: Use sigsp()
      blackfin: Use sigsp()
      c6x: Use sigsp()
      cris: Use sigsp()
      frv: Use sigsp()
      hexagon: Use sigsp()
      m32r: Use sigsp()
      m68k: Use sigsp()
      metag: Use sigsp()
      microblaze: Use sigsp()
      mips: Use sigsp()
      mn10300: Use sigsp()
      openrisc: Use sigsp()
      powerpc: Use sigsp()

 arch/arc/kernel/signal.c            |  47 ++++++---------
 arch/arm64/include/asm/signal32.h   |  11 ++--
 arch/arm64/kernel/signal.c          |  58 +++++++------------
 arch/arm64/kernel/signal32.c        |  24 +++-----
 arch/avr32/kernel/signal.c          |  50 +++++++---------
 arch/blackfin/kernel/signal.c       |  51 ++++++----------
 arch/c6x/kernel/signal.c            |  53 +++++++----------
 arch/cris/arch-v10/kernel/signal.c  |  89 +++++++++++-----------------
 arch/cris/arch-v32/kernel/signal.c  |  89 +++++++++++-----------------
 arch/frv/kernel/signal.c            | 112 ++++++++++++++----------------------
 arch/hexagon/kernel/signal.c        |  57 +++++++-----------
 arch/ia64/kernel/signal.c           |  46 +++++++--------
 arch/m32r/kernel/signal.c           |  57 +++++++-----------
 arch/m68k/kernel/signal.c           |  75 +++++++++---------------
 arch/metag/kernel/signal.c          |  10 +---
 arch/microblaze/kernel/signal.c     |  55 ++++++------------
 arch/mips/include/asm/abi.h         |  10 ++--
 arch/mips/kernel/signal-common.h    |   2 +-
 arch/mips/kernel/signal.c           |  72 +++++++++--------------
 arch/mips/kernel/signal32.c         |  39 +++++--------
 arch/mips/kernel/signal_n32.c       |  20 +++----
 arch/mn10300/kernel/signal.c        | 102 ++++++++++++--------------------
 arch/openrisc/kernel/signal.c       |  20 +------
 arch/parisc/kernel/signal.c         |  58 ++++++++-----------
 arch/powerpc/kernel/signal.c        |  41 +++++--------
 arch/powerpc/kernel/signal.h        |  14 ++---
 arch/powerpc/kernel/signal_32.c     |  36 ++++++------
 arch/powerpc/kernel/signal_64.c     |  28 +++++----
 arch/s390/kernel/compat_signal.c    |  79 +++++++++++--------------
 arch/s390/kernel/entry.h            |   4 +-
 arch/s390/kernel/signal.c           |  78 +++++++++++--------------
 arch/score/kernel/signal.c          |  43 ++++++--------
 arch/sh/kernel/signal_32.c          |  79 +++++++++++--------------
 arch/sh/kernel/signal_64.c          |  82 +++++++++++---------------
 arch/tile/include/asm/compat.h      |   3 +-
 arch/tile/kernel/compat_signal.c    |  29 +++++-----
 arch/tile/kernel/signal.c           |  54 ++++++++---------
 arch/um/include/shared/frame_kern.h |  12 ++--
 arch/um/kernel/signal.c             |  27 ++++-----
 arch/unicore32/kernel/signal.c      |  48 +++++++---------
 arch/x86/um/signal.c                |  45 +++++++--------
 arch/xtensa/kernel/signal.c         |  43 ++++++--------
 include/linux/sched.h               |   6 +-
 include/linux/signal.h              |  15 +----
 include/linux/tracehook.h           |   8 +--
 kernel/signal.c                     |  46 +++++++--------
 46 files changed, 789 insertions(+), 1238 deletions(-)

Thanks,
//richard


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

[GIT PULL] Global signal cleanup

[Richard Weinberger]

[-- Attachment #1: Type: text/plain, Size: 5493 bytes --]

Linus,

the following changes since commit 19583ca584d6f574384e17fe7613dfaeadcdc4a6:

  Linux 3.16 (2014-08-03 15:25:02 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rw/misc.git signal-cleanup

for you to fetch changes up to 059ade650ae57cfd371af690fdba887af04aded8:

  powerpc: Use sigsp() (2014-08-06 13:04:32 +0200)

----------------------------------------------------------------
This patch series moves all remaining archs to the get_signal(), signal_setup_done()
and sigsp() functions. Currently these archs use open coded
variants of the said functions. Further, unused parameters get removed
from get_signal_to_deliver(), tracehook_signal_handler() and signal_delivered().
At the end of the day we save around 500 lines of code.
----------------------------------------------------------------
Richard Weinberger (43):
      arc: Use get_signal() signal_setup_done()
      arm64: Use get_signal() signal_setup_done()
      avr32: Use get_signal() signal_setup_done()
      blackfin: Use get_signal() signal_setup_done()
      c6x: Use get_signal() signal_setup_done()
      cris: Use get_signal() signal_setup_done()
      frv: Use get_signal() signal_setup_done()
      hexagon: Use get_signal() signal_setup_done()
      ia64: Use get_signal() signal_setup_done()
      m32r: Use get_signal() signal_setup_done()
      m68k: Use get_signal() signal_setup_done()
      microblaze: Use get_signal() signal_setup_done()
      mips: Use get_signal() signal_setup_done()
      mn10300: Use get_signal() signal_setup_done()
      parisc: Use get_signal() signal_setup_done()
      powerpc: Use get_signal() signal_setup_done()
      s390: Use get_signal() signal_setup_done()
      score: Use get_signal() signal_setup_done()
      sh: Use get_signal() signal_setup_done()
      tile: Use get_signal() signal_setup_done()
      um: Use get_signal() signal_setup_done()
      unicore32: Use get_signal() signal_setup_done()
      xtensa: Use get_signal() signal_setup_done()
      tracehook_signal_handler: Remove sig, info, ka and regs
      Clean up signal_delivered()
      Rip out get_signal_to_deliver()
      sas_ss_flags: Remove nested ternary if
      arc: Use sigsp()
      arm64: Use sigsp()
      avr32: Use sigsp()
      blackfin: Use sigsp()
      c6x: Use sigsp()
      cris: Use sigsp()
      frv: Use sigsp()
      hexagon: Use sigsp()
      m32r: Use sigsp()
      m68k: Use sigsp()
      metag: Use sigsp()
      microblaze: Use sigsp()
      mips: Use sigsp()
      mn10300: Use sigsp()
      openrisc: Use sigsp()
      powerpc: Use sigsp()

 arch/arc/kernel/signal.c            |  47 ++++++---------
 arch/arm64/include/asm/signal32.h   |  11 ++--
 arch/arm64/kernel/signal.c          |  58 +++++++------------
 arch/arm64/kernel/signal32.c        |  24 +++-----
 arch/avr32/kernel/signal.c          |  50 +++++++---------
 arch/blackfin/kernel/signal.c       |  51 ++++++----------
 arch/c6x/kernel/signal.c            |  53 +++++++----------
 arch/cris/arch-v10/kernel/signal.c  |  89 +++++++++++-----------------
 arch/cris/arch-v32/kernel/signal.c  |  89 +++++++++++-----------------
 arch/frv/kernel/signal.c            | 112 ++++++++++++++----------------------
 arch/hexagon/kernel/signal.c        |  57 +++++++-----------
 arch/ia64/kernel/signal.c           |  46 +++++++--------
 arch/m32r/kernel/signal.c           |  57 +++++++-----------
 arch/m68k/kernel/signal.c           |  75 +++++++++---------------
 arch/metag/kernel/signal.c          |  10 +---
 arch/microblaze/kernel/signal.c     |  55 ++++++------------
 arch/mips/include/asm/abi.h         |  10 ++--
 arch/mips/kernel/signal-common.h    |   2 +-
 arch/mips/kernel/signal.c           |  72 +++++++++--------------
 arch/mips/kernel/signal32.c         |  39 +++++--------
 arch/mips/kernel/signal_n32.c       |  20 +++----
 arch/mn10300/kernel/signal.c        | 102 ++++++++++++--------------------
 arch/openrisc/kernel/signal.c       |  20 +------
 arch/parisc/kernel/signal.c         |  58 ++++++++-----------
 arch/powerpc/kernel/signal.c        |  41 +++++--------
 arch/powerpc/kernel/signal.h        |  14 ++---
 arch/powerpc/kernel/signal_32.c     |  36 ++++++------
 arch/powerpc/kernel/signal_64.c     |  28 +++++----
 arch/s390/kernel/compat_signal.c    |  79 +++++++++++--------------
 arch/s390/kernel/entry.h            |   4 +-
 arch/s390/kernel/signal.c           |  78 +++++++++++--------------
 arch/score/kernel/signal.c          |  43 ++++++--------
 arch/sh/kernel/signal_32.c          |  79 +++++++++++--------------
 arch/sh/kernel/signal_64.c          |  82 +++++++++++---------------
 arch/tile/include/asm/compat.h      |   3 +-
 arch/tile/kernel/compat_signal.c    |  29 +++++-----
 arch/tile/kernel/signal.c           |  54 ++++++++---------
 arch/um/include/shared/frame_kern.h |  12 ++--
 arch/um/kernel/signal.c             |  27 ++++-----
 arch/unicore32/kernel/signal.c      |  48 +++++++---------
 arch/x86/um/signal.c                |  45 +++++++--------
 arch/xtensa/kernel/signal.c         |  43 ++++++--------
 include/linux/sched.h               |   6 +-
 include/linux/signal.h              |  15 +----
 include/linux/tracehook.h           |   8 +--
 kernel/signal.c                     |  46 +++++++--------
 46 files changed, 789 insertions(+), 1238 deletions(-)

Thanks,
//richard


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: [GIT PULL] Global signal cleanup

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 493 bytes --]

Hi,

On Wed, 06 Aug 2014 13:18:54 +0200 Richard Weinberger <richard@nod.at> wrote:
>
> the following changes since commit 19583ca584d6f574384e17fe7613dfaeadcdc4a6:
> 
>   Linux 3.16 (2014-08-03 15:25:02 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/rw/misc.git signal-cleanup

This has all been rebased onto v3.16 but none of the patches changed.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [GIT PULL] Global signal cleanup

[Richard Weinberger]

[-- Attachment #1: Type: text/plain, Size: 586 bytes --]

Am 06.08.2014 13:27, schrieb Stephen Rothwell:
> Hi,
> 
> On Wed, 06 Aug 2014 13:18:54 +0200 Richard Weinberger <richard@nod.at> wrote:
>>
>> the following changes since commit 19583ca584d6f574384e17fe7613dfaeadcdc4a6:
>>
>>   Linux 3.16 (2014-08-03 15:25:02 -0700)
>>
>> are available in the git repository at:
>>
>>   git://git.kernel.org/pub/scm/linux/kernel/git/rw/misc.git signal-cleanup
> 
> This has all been rebased onto v3.16 but none of the patches changed.

This was my indention. Also I've added some acks.
Did I screw something up?

Thanks,
//richard


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: [GIT PULL] Global signal cleanup

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1606 bytes --]

Hi Richard,

On Wed, 06 Aug 2014 13:29:10 +0200 Richard Weinberger <richard@nod.at> wrote:
>
> Am 06.08.2014 13:27, schrieb Stephen Rothwell:
> > 
> > On Wed, 06 Aug 2014 13:18:54 +0200 Richard Weinberger <richard@nod.at> wrote:
> >>
> >> the following changes since commit 19583ca584d6f574384e17fe7613dfaeadcdc4a6:
> >>
> >>   Linux 3.16 (2014-08-03 15:25:02 -0700)
> >>
> >> are available in the git repository at:
> >>
> >>   git://git.kernel.org/pub/scm/linux/kernel/git/rw/misc.git signal-cleanup
> > 
> > This has all been rebased onto v3.16 but none of the patches changed.
> 
> This was my indention. Also I've added some acks.
> Did I screw something up?

We discourage people from rebasing their trees just before asking Linus
to pull them unless they have a good reason.  Adding Acks is not
necessarily a good reason.  It may be a different thing if you rewrite
your tree (without changing it base) and, given that none of your
actual patches changed, that would have worked for you.

In your case, since you haven't updated the branch (signal_v4) that I
fetch for linux-next, its doubly bad as, after Linus' pulls your tree,
I will have two copies of all those patches in my tree - which could
easily lead to conflicts that I really don't need to have.

Also, note that the fact that the actual patches did not change at all
means that either you missed some change that coudl have justified the
rebase, or the rebase was unnecessary (since the things you are
patching did not change).
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [GIT PULL] Global signal cleanup

[Richard Weinberger]

[-- Attachment #1: Type: text/plain, Size: 1747 bytes --]

Am 07.08.2014 02:28, schrieb Stephen Rothwell:
> Hi Richard,
> 
> On Wed, 06 Aug 2014 13:29:10 +0200 Richard Weinberger <richard@nod.at> wrote:
>>
>> Am 06.08.2014 13:27, schrieb Stephen Rothwell:
>>>
>>> On Wed, 06 Aug 2014 13:18:54 +0200 Richard Weinberger <richard@nod.at> wrote:
>>>>
>>>> the following changes since commit 19583ca584d6f574384e17fe7613dfaeadcdc4a6:
>>>>
>>>>   Linux 3.16 (2014-08-03 15:25:02 -0700)
>>>>
>>>> are available in the git repository at:
>>>>
>>>>   git://git.kernel.org/pub/scm/linux/kernel/git/rw/misc.git signal-cleanup
>>>
>>> This has all been rebased onto v3.16 but none of the patches changed.
>>
>> This was my indention. Also I've added some acks.
>> Did I screw something up?
> 
> We discourage people from rebasing their trees just before asking Linus
> to pull them unless they have a good reason.  Adding Acks is not
> necessarily a good reason.  It may be a different thing if you rewrite
> your tree (without changing it base) and, given that none of your
> actual patches changed, that would have worked for you.
> 
> In your case, since you haven't updated the branch (signal_v4) that I
> fetch for linux-next, its doubly bad as, after Linus' pulls your tree,
> I will have two copies of all those patches in my tree - which could
> easily lead to conflicts that I really don't need to have.
> 
> Also, note that the fact that the actual patches did not change at all
> means that either you missed some change that coudl have justified the
> rebase, or the rebase was unnecessary (since the things you are
> patching did not change).
> 

Thanks for the kind explanation.
It would be nice to see these rules written down somewhere.

Thanks,
//richard


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [GIT PULL] Global signal cleanup

[Linus Torvalds]

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.

     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).

              Linus

Re: [GIT PULL] Global signal cleanup

[Richard Weinberger]

Am 07.08.2014 20:53, schrieb Linus Torvalds:
> 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.
> 
>      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://git.kernel.org/pub/scm/linux/kernel/git/rw/misc.git signal_v4

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

Thanks,
//richard

Re: [GIT PULL] Global signal cleanup

[Richard Weinberger]

Am 07.08.2014 20:53, schrieb Linus Torvalds:
> 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.
> 
>      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://git.kernel.org/pub/scm/linux/kernel/git/rw/misc.git signal_v4

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

Thanks,
//richard

Re: [GIT PULL] Global signal cleanup

[Richard Weinberger]

Am 07.08.2014 22:47, schrieb Richard Weinberger:
> 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://git.kernel.org/pub/scm/linux/kernel/git/rw/misc.git signal_v4
> 
> It is the as-is branch from linux-next.

Btw: This is how you can verify that I did not alter any code between the branch in linux-next
and the one in the pull request:

$ git branch prove_signal_v4 v3.16
$ git branch prove_signal-cleanup v3.16
$ git checkout prove_signal_v4
$ git pull git://git.kernel.org/pub/scm/linux/kernel/git/rw/misc.git signal_v4
$ git checkout prove_signal-cleanup
$ git pull git://git.kernel.org/pub/scm/linux/kernel/git/rw/misc.git signal-cleanup
$ git diff prove_signal_v4..prove_signal-cleanup | wc -l
0

Again, sorry for any inconvenience caused.

Thanks,
//richard

Re: [GIT PULL] Global signal cleanup

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1868 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [GIT PULL] Global signal cleanup

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1868 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [GIT PULL] Global signal cleanup

[Vineet Gupta]

Hi Richard,

On Wednesday 06 August 2014 04:18 AM, Richard Weinberger wrote:
>       arc: Use get_signal() signal_setup_done()

I'd added this patch into arc tree for 3.17 (in linux-next for a while) and AFAIKR
I'd also left you a note to same effect. However it seems you are routing
everything thru ur tree, so I'll drop it from mine - OK ?

-Vineet

Re: [GIT PULL] Global signal cleanup

[Richard Weinberger]

Vineet,

Am 07.08.2014 22:44, schrieb Vineet Gupta:
> Hi Richard,
> 
> On Wednesday 06 August 2014 04:18 AM, Richard Weinberger wrote:
>>       arc: Use get_signal() signal_setup_done()
> 
> I'd added this patch into arc tree for 3.17 (in linux-next for a while) and AFAIKR
> I'd also left you a note to same effect. However it seems you are routing
> everything thru ur tree, so I'll drop it from mine - OK ?

Yes, please drop it from your tree.
Technically git merge will not cry about the double commit but
let's keep the history clean.

Thanks,
//richard