* [GIT PULL] Global signal cleanup @ 2014-08-06 11:18 Richard Weinberger 2014-08-06 11:18 ` Richard Weinberger ` (2 more replies) 0 siblings, 3 replies; 14+ messages in thread From: Richard Weinberger @ 2014-08-06 11:18 UTC (permalink / raw) To: Linus Torvalds Cc: linux-kernel@vger.kernel.org, Linux-Arch, sfr@canb.auug.org.au [-- 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 --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* [GIT PULL] Global signal cleanup 2014-08-06 11:18 [GIT PULL] Global signal cleanup Richard Weinberger @ 2014-08-06 11:18 ` Richard Weinberger 2014-08-06 11:27 ` Stephen Rothwell 2014-08-07 20:44 ` Vineet Gupta 2 siblings, 0 replies; 14+ messages in thread From: Richard Weinberger @ 2014-08-06 11:18 UTC (permalink / raw) To: Linus Torvalds Cc: linux-kernel@vger.kernel.org, Linux-Arch, sfr@canb.auug.org.au [-- 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 --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [GIT PULL] Global signal cleanup 2014-08-06 11:18 [GIT PULL] Global signal cleanup Richard Weinberger 2014-08-06 11:18 ` Richard Weinberger @ 2014-08-06 11:27 ` Stephen Rothwell 2014-08-06 11:29 ` Richard Weinberger 2014-08-07 20:44 ` Vineet Gupta 2 siblings, 1 reply; 14+ messages in thread From: Stephen Rothwell @ 2014-08-06 11:27 UTC (permalink / raw) To: Richard Weinberger Cc: Linus Torvalds, linux-kernel@vger.kernel.org, Linux-Arch [-- 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 --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [GIT PULL] Global signal cleanup 2014-08-06 11:27 ` Stephen Rothwell @ 2014-08-06 11:29 ` Richard Weinberger 2014-08-07 0:28 ` Stephen Rothwell 0 siblings, 1 reply; 14+ messages in thread From: Richard Weinberger @ 2014-08-06 11:29 UTC (permalink / raw) To: Stephen Rothwell; +Cc: Linus Torvalds, linux-kernel@vger.kernel.org, Linux-Arch [-- 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 --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [GIT PULL] Global signal cleanup 2014-08-06 11:29 ` Richard Weinberger @ 2014-08-07 0:28 ` Stephen Rothwell 2014-08-07 7:35 ` Richard Weinberger 0 siblings, 1 reply; 14+ messages in thread From: Stephen Rothwell @ 2014-08-07 0:28 UTC (permalink / raw) To: Richard Weinberger Cc: Linus Torvalds, linux-kernel@vger.kernel.org, Linux-Arch [-- 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 --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [GIT PULL] Global signal cleanup 2014-08-07 0:28 ` Stephen Rothwell @ 2014-08-07 7:35 ` Richard Weinberger 2014-08-07 18:53 ` Linus Torvalds 0 siblings, 1 reply; 14+ messages in thread From: Richard Weinberger @ 2014-08-07 7:35 UTC (permalink / raw) To: Stephen Rothwell; +Cc: Linus Torvalds, linux-kernel@vger.kernel.org, Linux-Arch [-- 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 --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [GIT PULL] Global signal cleanup 2014-08-07 7:35 ` Richard Weinberger @ 2014-08-07 18:53 ` Linus Torvalds 2014-08-07 20:47 ` Richard Weinberger 2014-08-08 3:21 ` Stephen Rothwell 0 siblings, 2 replies; 14+ messages in thread From: Linus Torvalds @ 2014-08-07 18:53 UTC (permalink / raw) To: Richard Weinberger Cc: Stephen Rothwell, linux-kernel@vger.kernel.org, Linux-Arch 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [GIT PULL] Global signal cleanup 2014-08-07 18:53 ` Linus Torvalds @ 2014-08-07 20:47 ` Richard Weinberger 2014-08-07 20:47 ` Richard Weinberger 2014-08-07 22:05 ` Richard Weinberger 2014-08-08 3:21 ` Stephen Rothwell 1 sibling, 2 replies; 14+ messages in thread From: Richard Weinberger @ 2014-08-07 20:47 UTC (permalink / raw) To: Linus Torvalds; +Cc: Stephen Rothwell, linux-kernel@vger.kernel.org, Linux-Arch 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [GIT PULL] Global signal cleanup 2014-08-07 20:47 ` Richard Weinberger @ 2014-08-07 20:47 ` Richard Weinberger 2014-08-07 22:05 ` Richard Weinberger 1 sibling, 0 replies; 14+ messages in thread From: Richard Weinberger @ 2014-08-07 20:47 UTC (permalink / raw) To: Linus Torvalds; +Cc: Stephen Rothwell, linux-kernel@vger.kernel.org, Linux-Arch 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [GIT PULL] Global signal cleanup 2014-08-07 20:47 ` Richard Weinberger 2014-08-07 20:47 ` Richard Weinberger @ 2014-08-07 22:05 ` Richard Weinberger 1 sibling, 0 replies; 14+ messages in thread From: Richard Weinberger @ 2014-08-07 22:05 UTC (permalink / raw) To: Linus Torvalds; +Cc: Stephen Rothwell, linux-kernel@vger.kernel.org, Linux-Arch 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [GIT PULL] Global signal cleanup 2014-08-07 18:53 ` Linus Torvalds 2014-08-07 20:47 ` Richard Weinberger @ 2014-08-08 3:21 ` Stephen Rothwell 2014-08-08 3:21 ` Stephen Rothwell 1 sibling, 1 reply; 14+ messages in thread From: Stephen Rothwell @ 2014-08-08 3:21 UTC (permalink / raw) To: Linus Torvalds Cc: Richard Weinberger, linux-kernel@vger.kernel.org, Linux-Arch [-- 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 --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [GIT PULL] Global signal cleanup 2014-08-08 3:21 ` Stephen Rothwell @ 2014-08-08 3:21 ` Stephen Rothwell 0 siblings, 0 replies; 14+ messages in thread From: Stephen Rothwell @ 2014-08-08 3:21 UTC (permalink / raw) To: Linus Torvalds Cc: Richard Weinberger, linux-kernel@vger.kernel.org, Linux-Arch [-- 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 --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [GIT PULL] Global signal cleanup 2014-08-06 11:18 [GIT PULL] Global signal cleanup Richard Weinberger 2014-08-06 11:18 ` Richard Weinberger 2014-08-06 11:27 ` Stephen Rothwell @ 2014-08-07 20:44 ` Vineet Gupta 2014-08-09 9:17 ` Richard Weinberger 2 siblings, 1 reply; 14+ messages in thread From: Vineet Gupta @ 2014-08-07 20:44 UTC (permalink / raw) To: Richard Weinberger, Linus Torvalds Cc: linux-kernel@vger.kernel.org, Linux-Arch, sfr@canb.auug.org.au 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [GIT PULL] Global signal cleanup 2014-08-07 20:44 ` Vineet Gupta @ 2014-08-09 9:17 ` Richard Weinberger 0 siblings, 0 replies; 14+ messages in thread From: Richard Weinberger @ 2014-08-09 9:17 UTC (permalink / raw) To: Vineet Gupta, Linus Torvalds Cc: linux-kernel@vger.kernel.org, Linux-Arch, sfr@canb.auug.org.au 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2014-08-09 9:17 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-08-06 11:18 [GIT PULL] Global signal cleanup Richard Weinberger 2014-08-06 11:18 ` Richard Weinberger 2014-08-06 11:27 ` Stephen Rothwell 2014-08-06 11:29 ` Richard Weinberger 2014-08-07 0:28 ` Stephen Rothwell 2014-08-07 7:35 ` Richard Weinberger 2014-08-07 18:53 ` Linus Torvalds 2014-08-07 20:47 ` Richard Weinberger 2014-08-07 20:47 ` Richard Weinberger 2014-08-07 22:05 ` Richard Weinberger 2014-08-08 3:21 ` Stephen Rothwell 2014-08-08 3:21 ` Stephen Rothwell 2014-08-07 20:44 ` Vineet Gupta 2014-08-09 9:17 ` Richard Weinberger
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).