* [PATCH] sound: max98090: Remove executable bit
@ 2013-03-19 21:58 Joe Perches
[not found] ` <20130320095758.GD28775@opensource.wolfsonmicro.com>
0 siblings, 1 reply; 11+ messages in thread
From: Joe Perches @ 2013-03-19 21:58 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown
Cc: Jaroslav Kysela, Takashi Iwai, alsa-devel, linux-kernel
Source files shouldn't have the executable bit set.
Signed-off-by: Joe Perches <joe@perches.com>
---
include/sound/max98090.h | 0
sound/soc/codecs/max98090.c | 0
sound/soc/codecs/max98090.h | 0
3 files changed, 0 insertions(+), 0 deletions(-)
diff --git a/include/sound/max98090.h b/include/sound/max98090.h
old mode 100755
new mode 100644
diff --git a/sound/soc/codecs/max98090.c b/sound/soc/codecs/max98090.c
old mode 100755
new mode 100644
diff --git a/sound/soc/codecs/max98090.h b/sound/soc/codecs/max98090.h
old mode 100755
new mode 100644
^ permalink raw reply [flat|nested] 11+ messages in thread[parent not found: <20130320095758.GD28775@opensource.wolfsonmicro.com>]
* Re: [PATCH] sound: max98090: Remove executable bit [not found] ` <20130320095758.GD28775@opensource.wolfsonmicro.com> @ 2013-03-20 15:22 ` Joe Perches [not found] ` <20130320163627.GS28775@opensource.wolfsonmicro.com> 0 siblings, 1 reply; 11+ messages in thread From: Joe Perches @ 2013-03-20 15:22 UTC (permalink / raw) To: Mark Brown Cc: Liam Girdwood, Jaroslav Kysela, Takashi Iwai, alsa-devel, linux-kernel On Wed, 2013-03-20 at 10:57 +0100, Mark Brown wrote: > On Tue, Mar 19, 2013 at 02:58:43PM -0700, Joe Perches wrote: > > Source files shouldn't have the executable bit set. > > I've applied this but I'm fed up to the back teeth of having to hand > edit trivial patches from you because you ignore the subject line styles > of subsystems and make up your own. Your style rules just don't matter to me and you can ignore the patches and fix it yourself. Or better, create a tool for others to use that follow your silly style rules. ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <20130320163627.GS28775@opensource.wolfsonmicro.com>]
* Re: [PATCH] sound: max98090: Remove executable bit [not found] ` <20130320163627.GS28775@opensource.wolfsonmicro.com> @ 2013-03-20 22:54 ` Joe Perches [not found] ` <20130321162503.GC14768@opensource.wolfsonmicro.com> 0 siblings, 1 reply; 11+ messages in thread From: Joe Perches @ 2013-03-20 22:54 UTC (permalink / raw) To: Mark Brown Cc: Liam Girdwood, Jaroslav Kysela, Takashi Iwai, alsa-devel, linux-kernel On Wed, 2013-03-20 at 17:36 +0100, Mark Brown wrote: > On Wed, Mar 20, 2013 at 08:22:16AM -0700, Joe Perches wrote: > > On Wed, 2013-03-20 at 10:57 +0100, Mark Brown wrote: > > > > I've applied this but I'm fed up to the back teeth of having to hand > > > edit trivial patches from you because you ignore the subject line styles > > > of subsystems and make up your own. > > > Your style rules just don't matter to me and > > you can ignore the patches and fix it yourself. > > > Or better, create a tool for others to use that > > follow your silly style rules. > > This is just like any other coding style thing - you should be creating > patches that look like other patches for the affected, if there's things > like obvious visual differences in what you're doing you're doing it > wrong. We've had this conversation before and I proposed to you a simple solution. https://lkml.org/lkml/2010/11/16/245 and I still more or less agree with Florian https://lkml.org/lkml/2010/11/16/314 I'm not doing it wrong. You have another demand others don't. I simply don't find it necessary to cater to you. If you want it to be agreed that there is a specific form for subject headers that varies by maintainer tree, change SubmittingPatches Paragraph 11. > Automation doesn't work for things like this, there's a good solid > reason why there's generally a human involved in patch; the other people > who submit lots of cleanups generally manage to figure this out > usefully, you might want to discuss techniques with them. I suggest you use a git pre-commit hook to your tree and use sed/perl to add a specific prefix if it doesn't exist. http://codeinthehole.com/writing/tips-for-using-a-git-pre-commit-hook/ ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <20130321162503.GC14768@opensource.wolfsonmicro.com>]
* Re: [PATCH] sound: max98090: Remove executable bit [not found] ` <20130321162503.GC14768@opensource.wolfsonmicro.com> @ 2013-03-21 17:16 ` Joe Perches 2013-03-21 17:44 ` Mark Brown 0 siblings, 1 reply; 11+ messages in thread From: Joe Perches @ 2013-03-21 17:16 UTC (permalink / raw) To: Mark Brown Cc: Liam Girdwood, Jaroslav Kysela, Takashi Iwai, alsa-devel, linux-kernel On Thu, 2013-03-21 at 17:25 +0100, Mark Brown wrote: > > I suggest you use a git pre-commit hook to your > > tree and use sed/perl to add a specific prefix > > if it doesn't exist. > > http://codeinthehole.com/writing/tips-for-using-a-git-pre-commit-hook/ > > I don't think you're quite understanding the issues with automation > here. Or indeed the desired end result. What issue is that? Maybe this would work for you... $ cat .git/hooks/applypatch-msg #!/bin/sh . git-sh-setup perl -p -i -e 's/^(?:ASoC:\s*)?(.*)$/ASoC: $1/g if 1 .. 1' {$1+"$@"} test -x "$GIT_DIR/hooks/commit-msg" && exec "$GIT_DIR/hooks/commit-msg" ${1+"$@"} : $ ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] sound: max98090: Remove executable bit 2013-03-21 17:16 ` Joe Perches @ 2013-03-21 17:44 ` Mark Brown 2013-03-21 17:53 ` Joe Perches 0 siblings, 1 reply; 11+ messages in thread From: Mark Brown @ 2013-03-21 17:44 UTC (permalink / raw) To: Joe Perches Cc: Liam Girdwood, Jaroslav Kysela, Takashi Iwai, alsa-devel, linux-kernel [-- Attachment #1: Type: text/plain, Size: 806 bytes --] On Thu, Mar 21, 2013 at 10:16:15AM -0700, Joe Perches wrote: > On Thu, 2013-03-21 at 17:25 +0100, Mark Brown wrote: > > I don't think you're quite understanding the issues with automation > > here. Or indeed the desired end result. > What issue is that? That one needs a bit more taste and thought to work out what's appropraite than can be guaranteed easily with a script, things like working out drive level prefixes for example. > Maybe this would work for you... > $ cat .git/hooks/applypatch-msg > #!/bin/sh > . git-sh-setup > perl -p -i -e 's/^(?:ASoC:\s*)?(.*)$/ASoC: $1/g if 1 .. 1' {$1+"$@"} > test -x "$GIT_DIR/hooks/commit-msg" && > exec "$GIT_DIR/hooks/commit-msg" ${1+"$@"} > : > $ No, that's going to leave essentially every commit that needs fixing up still needing manual fixup. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] sound: max98090: Remove executable bit 2013-03-21 17:44 ` Mark Brown @ 2013-03-21 17:53 ` Joe Perches 2013-03-21 18:44 ` Mark Brown 0 siblings, 1 reply; 11+ messages in thread From: Joe Perches @ 2013-03-21 17:53 UTC (permalink / raw) To: Mark Brown Cc: Liam Girdwood, Jaroslav Kysela, Takashi Iwai, alsa-devel, linux-kernel On Thu, 2013-03-21 at 18:44 +0100, Mark Brown wrote: > On Thu, Mar 21, 2013 at 10:16:15AM -0700, Joe Perches wrote: > > On Thu, 2013-03-21 at 17:25 +0100, Mark Brown wrote: > > > > I don't think you're quite understanding the issues with automation > > > here. Or indeed the desired end result. > > > What issue is that? > > That one needs a bit more taste and thought to work out what's > appropraite than can be guaranteed easily with a script, things like > working out drive level prefixes for example. [perfectly useful git applypatch-msg hook script removed] > No, that's going to leave essentially every commit that needs fixing up > still needing manual fixup. Then I'm sure that's your job as a maintainer to modify whatever patches you get to suit your taste. I think what I did is perfectly tasty. ttfn, o+o, ttyl, tafn, etc... ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] sound: max98090: Remove executable bit 2013-03-21 17:53 ` Joe Perches @ 2013-03-21 18:44 ` Mark Brown 2013-03-21 19:16 ` Joe Perches 0 siblings, 1 reply; 11+ messages in thread From: Mark Brown @ 2013-03-21 18:44 UTC (permalink / raw) To: Joe Perches Cc: Liam Girdwood, Jaroslav Kysela, Takashi Iwai, alsa-devel, linux-kernel [-- Attachment #1: Type: text/plain, Size: 1120 bytes --] On Thu, Mar 21, 2013 at 10:53:13AM -0700, Joe Perches wrote: > On Thu, 2013-03-21 at 18:44 +0100, Mark Brown wrote: > > That one needs a bit more taste and thought to work out what's > > appropraite than can be guaranteed easily with a script, things like > > working out drive level prefixes for example. > [perfectly useful git applypatch-msg hook script removed] No, it really isn't. Have you tried looking at the output? It's not going to do the right thing for the subject line here for example, never mind any other cases. > > No, that's going to leave essentially every commit that needs fixing up > > still needing manual fixup. > Then I'm sure that's your job as a maintainer > to modify whatever patches you get to suit your > taste. One of the things I'd really expect that a frequent submitter of trivial patches would be doing is to make an effort to improve the quality of what is being sent. If it's at the point where you're sending a lot of patches and it's more effort to apply them than to review them there's a problem. This is something that generally causes no problems for submitters... [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] sound: max98090: Remove executable bit 2013-03-21 18:44 ` Mark Brown @ 2013-03-21 19:16 ` Joe Perches 2013-03-21 20:37 ` Mark Brown 0 siblings, 1 reply; 11+ messages in thread From: Joe Perches @ 2013-03-21 19:16 UTC (permalink / raw) To: Mark Brown Cc: Liam Girdwood, Jaroslav Kysela, Takashi Iwai, alsa-devel, linux-kernel On Thu, 2013-03-21 at 19:44 +0100, Mark Brown wrote: > On Thu, Mar 21, 2013 at 10:53:13AM -0700, Joe Perches wrote: > > On Thu, 2013-03-21 at 18:44 +0100, Mark Brown wrote: > > > > That one needs a bit more taste and thought to work out what's > > > appropraite than can be guaranteed easily with a script, things like > > > working out drive level prefixes for example. > > > [perfectly useful git applypatch-msg hook script removed] > > No, it really isn't. Have you tried looking at the output? It's not > going to do the right thing for the subject line here for example, never > mind any other cases. Define "the right thing" for this instance. The commit isn't in -next so I have no idea what you actually applied. (nor do I really care btw) Did you try it? It commits: ASoC: sound: max98080: Remove executable bit If you're really anal about it and you want sound: for sound/soc removed, perl -p -i -e 's/^(?:ASoC:\s*)?(?:sound:\s*)?(.*)$/ASoC: $1/g if 1 .. 1' ${1+"$@"} This is a "your taste" issue only, and do keep in mind mountains vs molehills. cheers, Joe ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] sound: max98090: Remove executable bit 2013-03-21 19:16 ` Joe Perches @ 2013-03-21 20:37 ` Mark Brown 2013-03-21 20:40 ` Joe Perches 0 siblings, 1 reply; 11+ messages in thread From: Mark Brown @ 2013-03-21 20:37 UTC (permalink / raw) To: Joe Perches Cc: Liam Girdwood, Jaroslav Kysela, Takashi Iwai, alsa-devel, linux-kernel [-- Attachment #1: Type: text/plain, Size: 1689 bytes --] On Thu, Mar 21, 2013 at 12:16:45PM -0700, Joe Perches wrote: > The commit isn't in -next so I have no idea what > you actually applied. (nor do I really care btw) The fact that you don't care is kind of the problem here, aside from the extra effort involved the active resistance to change isn't good especially given that you are keen on things like get_maintainers and so on. > Did you try it? > It commits: > ASoC: sound: max98080: Remove executable bit Which clearly neither makes sense (think about what that means...) nor is consistent with other commits to either the driver or the subsystem. > If you're really anal about it and you want > sound: for sound/soc removed, Yes, of course. > perl -p -i -e 's/^(?:ASoC:\s*)?(?:sound:\s*)?(.*)$/ASoC: $1/g if 1 .. 1' ${1+"$@"} So that'll work for this particular error but then will fail if someone mistakenly uses any other prefix and won't do anything about the driver specific prefix. In any case this is not useful as even if you concoct something that fixes every possible error it still doesn't help with the incoming patch queue since searches don't match, the rewrite would need to be done on incoming mail and that's not a good idea. > This is a "your taste" issue only, and do keep in mind > mountains vs molehills. The reason I'm complaining here is that you routinely send very trivial patches which don't apply cleanly - sometimes they don't apply at all since you send them against inappropriate trees as well as requiring hand editing. This isn't a good pattern, it should be changed - people who submit many patches ought to be examples of how to work smoothly. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] sound: max98090: Remove executable bit 2013-03-21 20:37 ` Mark Brown @ 2013-03-21 20:40 ` Joe Perches 2013-03-21 21:26 ` Mark Brown 0 siblings, 1 reply; 11+ messages in thread From: Joe Perches @ 2013-03-21 20:40 UTC (permalink / raw) To: Mark Brown Cc: Liam Girdwood, Jaroslav Kysela, Takashi Iwai, alsa-devel, linux-kernel On Thu, 2013-03-21 at 21:37 +0100, Mark Brown wrote: > you routinely send very trivial > patches which don't apply cleanly That's demonstrably false. > people > who submit many patches ought to be examples of how to work smoothly. I'm done with this conversation. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] sound: max98090: Remove executable bit 2013-03-21 20:40 ` Joe Perches @ 2013-03-21 21:26 ` Mark Brown 0 siblings, 0 replies; 11+ messages in thread From: Mark Brown @ 2013-03-21 21:26 UTC (permalink / raw) To: Joe Perches Cc: Liam Girdwood, Jaroslav Kysela, Takashi Iwai, alsa-devel, linux-kernel [-- Attachment #1: Type: text/plain, Size: 634 bytes --] On Thu, Mar 21, 2013 at 01:40:22PM -0700, Joe Perches wrote: > On Thu, 2013-03-21 at 21:37 +0100, Mark Brown wrote: > > you routinely send very trivial > > patches which don't apply cleanly > That's demonstrably false. It's sadly not, at least for the things I get to see - as far as I have been able to tell you submit against either Linus' tree or the last release (I think the former) rather than the relevant development trees or even -next which means that if anyone else has looked at the same area of code there will be conflicts. > I'm done with this conversation. Oh, well. Hopefully you'll take on board the feedback. [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2013-03-21 21:26 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-03-19 21:58 [PATCH] sound: max98090: Remove executable bit Joe Perches
[not found] ` <20130320095758.GD28775@opensource.wolfsonmicro.com>
2013-03-20 15:22 ` Joe Perches
[not found] ` <20130320163627.GS28775@opensource.wolfsonmicro.com>
2013-03-20 22:54 ` Joe Perches
[not found] ` <20130321162503.GC14768@opensource.wolfsonmicro.com>
2013-03-21 17:16 ` Joe Perches
2013-03-21 17:44 ` Mark Brown
2013-03-21 17:53 ` Joe Perches
2013-03-21 18:44 ` Mark Brown
2013-03-21 19:16 ` Joe Perches
2013-03-21 20:37 ` Mark Brown
2013-03-21 20:40 ` Joe Perches
2013-03-21 21:26 ` Mark Brown
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox