{"thread":{"id":"9523","subject":"Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl","startedAt":"2007-08-14T17:00:24Z","lastAt":"2007-08-18T01:51:12Z","messageCount":38,"participants":["Joe Perches","Rene Herman","Linus Torvalds","Al Viro","Junio C Hamano","Richard Knutsson","Stefan Richter","Satyam Sharma","Kyle Moffett","Ray Lee","Krzysztof Halasa","Salikh Zakirov"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"50712","messageId":"1187110824.32555.76.camel@localhost","threadId":"9523","inReplyTo":"46C1CFFE.4000001@gmail.com","subject":"Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl","fromName":"Joe Perches","fromEmail":"joe@perches.com","sentAt":"2007-08-14T17:00:24Z","receivedAt":"2007-08-14T17:00:24Z","isPatch":true,"sender":{"key":"joe@perches.com","avatar":"https://avatars.githubusercontent.com/u/13122723?v=4"},"body":"On Tue, 2007-08-14 at 17:53 +0200, Rene Herman wrote:\n> It isn't about MODULE_FOO() tags, it is about tagging /source/ files \n> to help with putting CCs on patch submissals.\n> If we want to link source file foo.c and the \n> MAINTAINERS information, we have 3 options:\n> 1. MAINTAINERS --> foo.c\n> 2. foo.c --> MAINTAINERS\n> 3. foo.c <--> some 3rd file <--> MAINTAINERS\n\nI added git@vger.kernel.org and Junio Hamano\n\nAnother possibility is improving git to allow\nsome sort of \"declaration of interest\" in bits\nof projects.\n\nThat would allow options like:\n\no git-format-patch to include CCs\no git-commit and git-branch to notify or\n take some other action\n\netc...\n\nIt's generic, applies to multiple projects, etc.\n\nI don't care which mechanism is used, I just want\nto be able to CC appropriate people and lists on\nchanges to their areas of interest without wasting\ntime searching all over the place per file changed.\n\nThe LK MAINTAINERS file is weakly specified, but\nI'm not a git-geek, nor do I want to be one, so\nMAINTAINERS was the file I could easiest change\nwith minimal impact to LK sources.\n\nThe get_maintainer script is trivial,\nI'm not wedded to it at all.\n"},{"id":"50713","messageId":"46C1EE6F.2080807@gmail.com","threadId":"9523","inReplyTo":"1187110824.32555.76.camel@localhost","subject":"Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl","fromName":"Rene Herman","fromEmail":"rene.herman@gmail.com","sentAt":"2007-08-14T18:03:27Z","receivedAt":"2007-08-14T18:03:27Z","isPatch":true,"sender":{"key":"rene.herman@gmail.com","avatar":null},"body":"On 08/14/2007 07:00 PM, Joe Perches wrote:\n\n> On Tue, 2007-08-14 at 17:53 +0200, Rene Herman wrote:\n\n>> It isn't about MODULE_FOO() tags, it is about tagging /source/ files \n>> to help with putting CCs on patch submissals.\n>> If we want to link source file foo.c and the \n>> MAINTAINERS information, we have 3 options:\n>> 1. MAINTAINERS --> foo.c\n>> 2. foo.c --> MAINTAINERS\n>> 3. foo.c <--> some 3rd file <--> MAINTAINERS\n> \n> I added git@vger.kernel.org and Junio Hamano\n\nWell, yes, I agree -- going through GIT seems to be the only really workable \nsolution.\n\nThat is, instead of (case 2, you snipped it) having a backlink to the \nMAINTAINERS file in a header inside the source GIT would maintain this \nbacklink -- and at that point, you can basically forego the MAINTAINERS file \ncompletely other than as something GIT can generate and just regard all of \nit meta-information (you may want to generate MAINTAINERS for releases but \nmaking GIT the source is the idea).\n\n\"git info --maintainer drivers/ide/ide-cd.c\" or some such would say \"Alan \nCox \".\n\nThere are more possibilities for this kind of meta information. git info \n--author, git info --license, git info --whatever. Given that it's intended \nfor developers, needing GIT should not get in the way but there's always the \ngenerated MAINTAINERS file in releases as well.\n\nIt would ofcourse automatically stay up to date through deleting and moving \nof files. You'd probably want to devise a way to enable a submitter to also \nautomatically provide meta-information upon addition of files. This can be \ndone in the same way as a \"Signed-off-by\". Just tags in a submit email.\n\nThis should probably turn out to be the way things work yes. The paths in \nthe MAINTAINERS file grow stale, source headers might also and sticking \nheaders on every source file isn't nice anyway -- it's meta-information and \nthe SCM can maintain it.\n\nRene.\n"},{"id":"50714","messageId":"1187116082.32555.122.camel@localhost","threadId":"9523","inReplyTo":"46C1EE6F.2080807@gmail.com","subject":"Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl","fromName":"Joe Perches","fromEmail":"joe@perches.com","sentAt":"2007-08-14T18:28:02Z","receivedAt":"2007-08-14T18:28:02Z","isPatch":true,"sender":{"key":"joe@perches.com","avatar":"https://avatars.githubusercontent.com/u/13122723?v=4"},"body":"On Tue, 2007-08-14 at 20:03 +0200, Rene Herman wrote:\n> \"git info --maintainer drivers/ide/ide-cd.c\" or some such would say \"Alan \n> Cox \".\n\nPerhaps maintainer(s), approver(s), listener(s)?\n\nI think something like this should be a git-goal.\nWhat do the git-wranglers think?\n\nUntil a time in the future when a system like that exists,\nI suggest keeping MAINTAINERS up-to-date with\n\nF:\tpattern\n\nIt'll be useful as git-set-maintainer seeds at least.\n\n> sticking headers on every source file isn't nice anyway --\n> it's meta-information and the SCM can maintain it.\n\nIt's like looking at $CVS$ keywords. Unsightly.\n\ncheers, Joe\n"},{"id":"50715","messageId":"46C1F55E.1020908@gmail.com","threadId":"9523","inReplyTo":"1187116082.32555.122.camel@localhost","subject":"Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl","fromName":"Rene Herman","fromEmail":"rene.herman@gmail.com","sentAt":"2007-08-14T18:33:02Z","receivedAt":"2007-08-14T18:33:02Z","isPatch":true,"sender":{"key":"rene.herman@gmail.com","avatar":null},"body":"On 08/14/2007 08:28 PM, Joe Perches wrote:\n\n> On Tue, 2007-08-14 at 20:03 +0200, Rene Herman wrote:\n>> \"git info --maintainer drivers/ide/ide-cd.c\" or some such would say \"Alan \n>> Cox \".\n> \n> Perhaps maintainer(s), approver(s), listener(s)?\n> \n> I think something like this should be a git-goal.\n> What do the git-wranglers think?\n\nI agree. If this thing has source management, let's use it.\n\n> Until a time in the future when a system like that exists,\n> I suggest keeping MAINTAINERS up-to-date with\n> \n> F:\tpattern\n> \n> It'll be useful as git-set-maintainer seeds at least.\n\nYes. Seeing as how it's already been useful in updating the information it \nwould be a shame to throw what you already did away. Don't underestimate how \nfast git-wranglers can implement stuff if they agree though... :-)\n\n>> sticking headers on every source file isn't nice anyway --\n>> it's meta-information and the SCM can maintain it.\n> \n> It's like looking at $CVS$ keywords. Unsightly.\n\nAgain agree.\n\nRene.\n"},{"id":"50717","messageId":"alpine.LFD.0.999.0708141131140.30176@woody.linux-foundation.org","threadId":"9523","inReplyTo":"1187116082.32555.122.camel@localhost","subject":"Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-08-14T18:40:09Z","receivedAt":"2007-08-14T18:40:09Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 14 Aug 2007, Joe Perches wrote:\n\n> On Tue, 2007-08-14 at 20:03 +0200, Rene Herman wrote:\n> > \"git info --maintainer drivers/ide/ide-cd.c\" or some such would say \"Alan \n> > Cox \".\n> \n> Perhaps maintainer(s), approver(s), listener(s)?\n> \n> I think something like this should be a git-goal.\n> What do the git-wranglers think?\n\nThe thing is, if you have git, you can basically already do this.\n\nDo a script like this:\n\n\t#!/bin/sh\n\tgit log --since=6.months.ago -- \"$@\" |\n\t\tgrep -i '^ [-a-z]*by:.*@' |\n\t\tsort | uniq -c |\n\t\tsort -r -n | head\n\nand it gives you a rather good picture of who is involved with a \nparticular subdirectory or file.\n\nA much *better* picture than some manually maintained thing, in fact, \nbecause it tells you who really does the work, and which way patches go...\n\n(Maybe you want to add a\n\n\tgrep -v '\\(Linus Torvalds\\)\\|\\(Andrew Morton\\)'\n\nto avoid seeing the normal chain too much, but hey, we probably want to \nknow too. Anyway - the script can certainly be tweaked, the point is \nreally just that the git tree _already_ contains the relevant \ninformation).\n\n\t\tLinus\n"},{"id":"50719","messageId":"1187117688.32555.149.camel@localhost","threadId":"9523","inReplyTo":"alpine.LFD.0.999.0708141131140.30176@woody.linux-foundation.org","subject":"Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl","fromName":"Joe Perches","fromEmail":"joe@perches.com","sentAt":"2007-08-14T18:54:48Z","receivedAt":"2007-08-14T18:54:48Z","isPatch":true,"sender":{"key":"joe@perches.com","avatar":"https://avatars.githubusercontent.com/u/13122723?v=4"},"body":"On Tue, 2007-08-14 at 11:40 -0700, Linus Torvalds wrote:\n> Anyway - the script can certainly be tweaked, the point is \n> really just that the git tree _already_ contains the relevant \n> information).\n\nI believe it's not specific enough.\nThings like email lists would never show up.\n"},{"id":"50720","messageId":"20070814193333.GI21089@ftp.linux.org.uk","threadId":"9523","inReplyTo":"alpine.LFD.0.999.0708141131140.30176@woody.linux-foundation.org","subject":"Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl","fromName":"Al Viro","fromEmail":"viro@ftp.linux.org.uk","sentAt":"2007-08-14T19:33:33Z","receivedAt":"2007-08-14T19:33:33Z","isPatch":true,"sender":{"key":"viro@ftp.linux.org.uk","avatar":null},"body":"On Tue, Aug 14, 2007 at 11:40:09AM -0700, Linus Torvalds wrote:\n\n> A much *better* picture than some manually maintained thing, in fact, \n> because it tells you who really does the work, and which way patches go...\n> \n> (Maybe you want to add a\n> \n> \tgrep -v '\\(Linus Torvalds\\)\\|\\(Andrew Morton\\)'\n> \n> to avoid seeing the normal chain too much, but hey, we probably want to \n> know too. Anyway - the script can certainly be tweaked, the point is \n> really just that the git tree _already_ contains the relevant \n> information).\n\nFWIW, I suspect that we are looking at that from the wrong POV. If\nthat's about \"who ought to be Cc'd on the issues dealing with \", why does it have to be tied to \"who is maintainer for\n\"?\n\nI'm not suggesting something like fs.ext2@kernel.org with something\nlike majordomo allowing to add yourself to those, but something less\nextreme in that direction might be worth thinking about... Hell,\neven simple\n$ finger fs/minix/dir.c@cc.kernel.org\nwith majordomo-like interface for adding yourself to such lists\nmight solve most of those problems...\n"},{"id":"50724","messageId":"1187121435.32555.166.camel@localhost","threadId":"9523","inReplyTo":"20070814193333.GI21089@ftp.linux.org.uk","subject":"Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl","fromName":"Joe Perches","fromEmail":"joe@perches.com","sentAt":"2007-08-14T19:57:15Z","receivedAt":"2007-08-14T19:57:15Z","isPatch":true,"sender":{"key":"joe@perches.com","avatar":"https://avatars.githubusercontent.com/u/13122723?v=4"},"body":"On Tue, 2007-08-14 at 20:33 +0100, Al Viro wrote:\n> FWIW, I suspect that we are looking at that from the wrong POV. If\n> that's about \"who ought to be Cc'd on the issues dealing with of pathnames>\", why does it have to be tied to \"who is maintainer for\n> \"?\n\nRight, it doesn't have to.\nI think a notification list would be just fine.\n\n> I'm not suggesting something like fs.ext2@kernel.org with something\n> like majordomo allowing to add yourself to those, but something less\n> extreme in that direction might be worth thinking about...\n> Hell, even simple\n> $ finger fs/minix/dir.c@cc.kernel.org\n> with majordomo-like interface for adding yourself to such lists\n> might solve most of those problems...\n\nMight solve all of my wants for this problem.\n\ncheers, Joe\n"},{"id":"50744","messageId":"46C2548D.80605@gmail.com","threadId":"9523","inReplyTo":"20070814193333.GI21089@ftp.linux.org.uk","subject":"Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl","fromName":"Rene Herman","fromEmail":"rene.herman@gmail.com","sentAt":"2007-08-15T01:19:09Z","receivedAt":"2007-08-15T01:19:09Z","isPatch":true,"sender":{"key":"rene.herman@gmail.com","avatar":null},"body":"On 08/14/2007 09:33 PM, Al Viro wrote:\n\n> FWIW, I suspect that we are looking at that from the wrong POV. If\n> that's about \"who ought to be Cc'd on the issues dealing with of pathnames>\", why does it have to be tied to \"who is maintainer for\n> \"?\n> \n> I'm not suggesting something like fs.ext2@kernel.org with something\n> like majordomo allowing to add yourself to those, but something less\n> extreme in that direction might be worth thinking about... Hell,\n> even simple\n> $ finger fs/minix/dir.c@cc.kernel.org\n> with majordomo-like interface for adding yourself to such lists\n> might solve most of those problems...\n\nIt mostly is just about that it seems. However, this would not also allow \nthe other information currently in the MAINTAINERS file to be queried in \nsimilar ways.\n\nGit could grow a generic file meta data implementation through the use of \ntags, sort of like tags on multimedia files although while with multimedia \nfiles the tags are in fact stored as a file header, here you'd keep them \njust in git. Any project using git would be free to define its own set of \ninfo tags and you'd supply them to git simply as a list of\n\n=\n\npairs:\n\n$ git info --add drivers/ide/ide-cd.c <\", linux-ide@vger.kernel.org\nEOF\n\nOr as a more expansive example, with the tags set on a directory (and the \noutput shown this time):\n\n$ git info drivers/infiniband/\nCC=\"Roland Dreier \"\nCC=\"Sean Hefty \"\nCC=\"Hal Rosenstock \"\nCC=openib-general@openib.org\nW=http://www.openib.org/\nT=git kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git\n\n$ git info --type=\"W\" drivers/infiniband/\nhttp://www.openib.org/\n\nThe project can link the actual tags such as CC, W and T to --options for \nthe \"info\" command in the git configuration file for the tree (and/or just \ndefine a few upfront I guess) making it look nicer:\n\n$ git info --cc drivers/infiniband/\n\"Roland Dreier \"\n\"Sean Hefty \"\n\"Hal Rosenstock \"\nopenib-general@openib.org\n\n$ git info --website drivers/infiniband/\nhttp://www.openib.org/\n\n$ git info --tree drivers/infiniband/\ngit kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git\n\nExtra: when you have such an implementation, you can use it for other \npurposes as well such as the summary Documentation/ files want for the \n00-INDEX files:\n\n$ git info --summary Documentation/BUG-HUNTING\nbrute force method of doing binary search of patches to find bug.\n\nAnd importantly -- when queuried for a file that itself doesn't have the \nrequested info tag:\n\n$ git info --cc drivers/infiniband/core/addr.c\n\ngit looks for the tag on the drivers/infiniband/core/ directory next, and \nthen on drivers/infiniband/, where it finds it. linux-kernel@vger.kernel.org \nwould be the final fallback, being set on the project root.\n\nI'd really like something like this. As long as projects are both free to \nuse and not use them and free to define their own set of tags I believe this \nwould work very nicely.\n\nOnce you have these tags, you can basically use them for anything.\n\nRene.\n"},{"id":"50742","messageId":"7vwsvx8twx.fsf@assigned-by-dhcp.cox.net","threadId":"9523","inReplyTo":"1187110824.32555.76.camel@localhost","subject":"Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-15T01:31:58Z","receivedAt":"2007-08-15T01:31:58Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Joe Perches writes:\n\n> On Tue, 2007-08-14 at 17:53 +0200, Rene Herman wrote:\n>> It isn't about MODULE_FOO() tags, it is about tagging /source/ files \n>> to help with putting CCs on patch submissals.\n>> If we want to link source file foo.c and the \n>> MAINTAINERS information, we have 3 options:\n>> 1. MAINTAINERS --> foo.c\n>> 2. foo.c --> MAINTAINERS\n>> 3. foo.c <--> some 3rd file <--> MAINTAINERS\n>\n> I added git@vger.kernel.org and Junio Hamano\n>\n> Another possibility is improving git to allow\n> some sort of \"declaration of interest\" in bits\n> of projects.\n>\n> That would allow options like:\n>\n> o git-format-patch to include CCs\n> o git-commit and git-branch to notify or\n> take some other action\n>\n> etc...\n\nThere are things git can help, and other things git does not\nhave any business with.\n\n1. Finding out who the potentially interested parties are.\n\n Linus already gave a script to grep *-by: lines from commit\n messages. I find this is probably be the best option, as it\n follows \"yesterday's weather\". People who had dealt with the\n area are the ones who are likely to be interested.\n\n git records who did the work (author) and who did the\n integration to git-based patch flow (committer). It does not\n structurally track intermediate people who touched the patch\n on e-mail, but Signed-off-by: and Acked-by: (and sometimes I\n see Cc: as well in the commit messages) are accepted social\n convention in the kernel community, and taking advantage of\n that is a good idea.\n\n\n2. Making it easier to send your patches to these people.\n\n There are three possible places to add Signed-off-by: and\n friends in the commit messages you would mail out:\n\n - When you create your own commit, or commit a patch that\n came to you via e-mail. The commit object in your tree\n will carry them --- you can send format-patch output as-is\n to Linus or Andrew and you are done.\n\n - When you run format-patch; your commit will not have extra\n Cc: or \"interested parties\" information, you will use the\n result of 1. and insert it near your own Signed-off-by: to\n the format-patch output.\n\n - When you send format-patch output, via git-send-email\n perhaps.\n\n To make the result useful for \"yesterday's weather\" approach,\n I think it would be the best to do the first. After all,\n your commit may propagate via \"git pull\" not over e-mail, and\n no postprocessing approach would work in such a case.\n\n The second one is my least favorite. format-patch output is\n designed to record author/committer (i.e. origin) and not to\n record recipient at all. \"Who's interested in this\" does not\n simply belong there.\n\n On the other hand, git-send-email _is_ all about sending it\n out, and it needs to know who your patch should reach. I\n think it makes sense to have one script that, given a set of\n paths that are affected, gives a list of potentially\n interested people (that is \"Finding\" part -- and I see there\n are 600+ patches to implement this on the list), and a new\n option to git-send-email to (1) inspect the patch to see what\n paths are affected, and (2) call that \"Find\" script to figure\n out whom to send it to, and probably asking for confirmation.\n"},{"id":"50743","messageId":"46C2585F.60802@student.ltu.se","threadId":"9523","inReplyTo":"alpine.LFD.0.999.0708141131140.30176@woody.linux-foundation.org","subject":"Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl","fromName":"Richard Knutsson","fromEmail":"ricknu-0@student.ltu.se","sentAt":"2007-08-15T01:35:27Z","receivedAt":"2007-08-15T01:35:27Z","isPatch":true,"sender":{"key":"ricknu-0@student.ltu.se","avatar":null},"body":"Linus Torvalds wrote:\n> On Tue, 14 Aug 2007, Joe Perches wrote:\n>\n> \n>> On Tue, 2007-08-14 at 20:03 +0200, Rene Herman wrote:\n>> \n>>> \"git info --maintainer drivers/ide/ide-cd.c\" or some such would say \"Alan \n>>> Cox \".\n>>> \n>> Perhaps maintainer(s), approver(s), listener(s)?\n>>\n>> I think something like this should be a git-goal.\n>> What do the git-wranglers think?\n>> \n>\n> The thing is, if you have git, you can basically already do this.\n>\n> Do a script like this:\n>\n> \t#!/bin/sh\n> \tgit log --since=6.months.ago -- \"$@\" |\n> \t\tgrep -i '^ [-a-z]*by:.*@' |\n> \nsed -r \"s/^.*by: \\\"?([^\\\"]+)\\\"?/\\1/\" |\n> \t\tsort | uniq -c |\n> \t\tsort -r -n | head\n>\n> and it gives you a rather good picture of who is involved with a \n> particular subdirectory or file.\n>\n> \nLike the script! Especially since it reveled --since=6.month.ago and \nuniq to me.\nJust wondering, why order them in the acked, signed and tested? Other \nthen removing those, the added 'sed' also fix the vs \n\"\"-\"problem\". + adding '-i' to uniq should help the result too, right?\n\nNow a simple \"diffstat -p1 -l | xargs \" \nmakes the day. Too bad, as Joe pointed out, it does not include relevant ML.\n\ncheers\nRichard Knutsson\n"},{"id":"50746","messageId":"1187143925.32555.208.camel@localhost","threadId":"9523","inReplyTo":"7vwsvx8twx.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl","fromName":"Joe Perches","fromEmail":"joe@perches.com","sentAt":"2007-08-15T02:12:05Z","receivedAt":"2007-08-15T02:12:05Z","isPatch":true,"sender":{"key":"joe@perches.com","avatar":"https://avatars.githubusercontent.com/u/13122723?v=4"},"body":"On Tue, 2007-08-14 at 18:31 -0700, Junio C Hamano wrote:\n> On the other hand, git-send-email _is_ all about sending it\n> out, and it needs to know who your patch should reach. I\n> think it makes sense to have one script that, given a set of\n> paths that are affected, gives a list of potentially\n> interested people (that is \"Finding\" part -- and I see there\n> are 600+ patches to implement this on the list), and a new\n> option to git-send-email to (1) inspect the patch to see what\n> paths are affected, and (2) call that \"Find\" script to figure\n> out whom to send it to, and probably asking for confirmation.\n\nYes please.\n\nThe LK MAINTAINERS file is ugly.\n\nMight there be a git portable way to \"find\"?\n\nRene Herman had an idea about using some git\nmetadata that might be useful. The completely\nexternal data approach suggested by Al Viro \nmight be OK too in that it wouldn't tie listeners\nto git requiring more content in git metadata.\n\nPerhaps both via something like:\n\n\t--external-find \"cmd @filelist\"\n\nThanks, Joe\n"},{"id":"50748","messageId":"7vlkcdjrmu.fsf@assigned-by-dhcp.cox.net","threadId":"9523","inReplyTo":"1187143925.32555.208.camel@localhost","subject":"Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-15T05:25:45Z","receivedAt":"2007-08-15T05:25:45Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Joe Perches writes:\n\n> Yes please.\n\nHuh?\n\n> Rene Herman had an idea about using some git\n> metadata that might be useful. The completely\n> external data approach suggested by Al Viro \n> might be OK too in that it wouldn't tie listeners\n> to git requiring more content in git metadata.\n\nThe reason I found Linus's suggestion desirable is because it\nfundamentally does not require git to track any metadata. If\nthe commits are in git, then his script would let you gather the\ndata, but otherwise you should be able to do the same by\ngrepping patches. Obviously you would need to filter by paths,\nlooking at the diffstat, but the approach does _not_ tie users\nto git.\n"},{"id":"50753","messageId":"46C2922D.8000408@gmail.com","threadId":"9523","inReplyTo":"7vlkcdjrmu.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl","fromName":"Rene Herman","fromEmail":"rene.herman@gmail.com","sentAt":"2007-08-15T05:42:05Z","receivedAt":"2007-08-15T05:42:05Z","isPatch":true,"sender":{"key":"rene.herman@gmail.com","avatar":null},"body":"On 08/15/2007 07:25 AM, Junio C Hamano wrote:\n\n> Joe Perches writes:\n\n>> Rene Herman had an idea about using some git\n>> metadata that might be useful. The completely\n>> external data approach suggested by Al Viro \n>> might be OK too in that it wouldn't tie listeners\n>> to git requiring more content in git metadata.\n> \n> The reason I found Linus's suggestion desirable is because it\n> fundamentally does not require git to track any metadata. If\n> the commits are in git, then his script would let you gather the\n> data, but otherwise you should be able to do the same by\n> grepping patches. Obviously you would need to filter by paths,\n> looking at the diffstat, but the approach does _not_ tie users\n> to git.\n\nI believe that wouldn't be much of a problem really. Users in this context \nare people submitting patches and most people who do will, could and maybe \neven should be running git these days -- git is very good, GPLd and the \nLinux source code managament system.\n\nBut for occasional contributors that don't, a MAINTAINERS file much like the \ncurrent could also be generated into releases; it's just that the source \nwould live as file/directory metadata inside git.\n\nStill like the notion of a generic file/directory metadata implementation \ninside git, through that \"=\" system that I suggested. Wouldn't \nbe intrinsically tied to Linux or anything, with any project being free to \ninvent their own tags and has heaps of possible uses, from the current \nMAINTAINERS info, through summary information, author/licese information, \nanything goes...\n\nRene.\n"},{"id":"50760","messageId":"46C2C762.7080205@s5r6.in-berlin.de","threadId":"9523","inReplyTo":"alpine.LFD.0.999.0708141131140.30176@woody.linux-foundation.org","subject":"Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl","fromName":"Stefan Richter","fromEmail":"stefanr@s5r6.in-berlin.de","sentAt":"2007-08-15T09:29:06Z","receivedAt":"2007-08-15T09:29:06Z","isPatch":true,"sender":{"key":"stefanr@s5r6.in-berlin.de","avatar":null},"body":"Linus Torvalds wrote:\n> \t#!/bin/sh\n> \tgit log --since=6.months.ago -- \"$@\" |\n> \t\tgrep -i '^ [-a-z]*by:.*@' |\n> \t\tsort | uniq -c |\n> \t\tsort -r -n | head\n> \n> and it gives you a rather good picture of who is involved with a \n> particular subdirectory or file.\n\nNo, it doesn't. The subscribers of are\nnot listed in patch logs.\n-- \nStefan Richter\n-=====-=-=== =--- -====\nhttp://arcgraph.de/sr/\n"},{"id":"50761","messageId":"46C2C9DC.9030307@s5r6.in-berlin.de","threadId":"9523","inReplyTo":"1187143925.32555.208.camel@localhost","subject":"Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl","fromName":"Stefan Richter","fromEmail":"stefanr@s5r6.in-berlin.de","sentAt":"2007-08-15T09:39:40Z","receivedAt":"2007-08-15T09:39:40Z","isPatch":true,"sender":{"key":"stefanr@s5r6.in-berlin.de","avatar":null},"body":"Joe Perches wrote:\n> On Tue, 2007-08-14 at 18:31 -0700, Junio C Hamano wrote:\n>> On the other hand, git-send-email _is_ all about sending it\n>> out, and it needs to know who your patch should reach. I\n>> think it makes sense to have one script that,\n[...]\n\n> Yes please.\n> \n> The LK MAINTAINERS file is ugly.\n> \n> Might there be a git portable way to \"find\"?\n\nNote, maintainer contacts\n - should be available to patch submitters and\n - must be available to *problem reporters*\nwithout having to have git and a .git repo.\n-- \nStefan Richter\n-=====-=-=== =--- -====\nhttp://arcgraph.de/sr/\n"},{"id":"50764","messageId":"46C2E727.3050407@gmail.com","threadId":"9523","inReplyTo":"46C2C9DC.9030307@s5r6.in-berlin.de","subject":"Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl","fromName":"Rene Herman","fromEmail":"rene.herman@gmail.com","sentAt":"2007-08-15T11:44:39Z","receivedAt":"2007-08-15T11:44:39Z","isPatch":true,"sender":{"key":"rene.herman@gmail.com","avatar":null},"body":"On 08/15/2007 11:39 AM, Stefan Richter wrote:\n\n> Note, maintainer contacts\n> - should be available to patch submitters and\n> - must be available to *problem reporters*\n> without having to have git and a .git repo.\n\nThat \"must\" seems rather strong. But those few non-developer users that \ncould care are served by a MAINTAINERS file generated into releases.\n\nRene.\n"},{"id":"50771","messageId":"alpine.LFD.0.999.0708151846130.16414@enigma.security.iitk.ac.in","threadId":"9523","inReplyTo":"46C2548D.80605@gmail.com","subject":"Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl","fromName":"Satyam Sharma","fromEmail":"satyam@infradead.org","sentAt":"2007-08-15T13:33:53Z","receivedAt":"2007-08-15T13:33:53Z","isPatch":true,"sender":{"key":"satyam@infradead.org","avatar":null},"body":"Hi Rene,\n\n\nOn Wed, 15 Aug 2007, Rene Herman wrote:\n\n> It mostly is just about that it seems. However, this would not also allow the\n> other information currently in the MAINTAINERS file to be queried in similar\n> ways.\n> \n> Git could grow a generic file meta data implementation through the use of\n> tags, sort of like tags on multimedia files although while with multimedia\n> files the tags are in fact stored as a file header, here you'd keep them just\n> in git. Any project using git would be free to define its own set of info tags\n> and you'd supply them to git simply as a list of\n> \n> =\n> \n> pairs:\n> \n> $ git info --add drivers/ide/ide-cd.c < CC=\"Alan Cox \", linux-ide@vger.kernel.org\n> EOF\n> \n> Or as a more expansive example, with the tags set on a directory (and the\n> output shown this time):\n> \n> $ git info drivers/infiniband/\n> CC=\"Roland Dreier \"\n> CC=\"Sean Hefty \"\n> CC=\"Hal Rosenstock \"\n> CC=openib-general@openib.org\n\nConsidering some people may want to differentiate between \"those who want\nto be Cc'ed for patches on subsystem X\" and \"those who are maintainer(s)\nof subsystem X\", I think another \"P=\" kind of tag might also be useful\nhere.\n\n> W=http://www.openib.org/\n> T=git kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git\n> \n> $ git info --type=\"W\" drivers/infiniband/\n> http://www.openib.org/\n> \n> The project can link the actual tags such as CC, W and T to --options for the\n> \"info\" command in the git configuration file for the tree (and/or just define\n> a few upfront I guess) making it look nicer:\n> \n> $ git info --cc drivers/infiniband/\n> \"Roland Dreier \"\n> \"Sean Hefty \"\n> \"Hal Rosenstock \"\n> openib-general@openib.org\n> \n> $ git info --website drivers/infiniband/\n> http://www.openib.org/\n> \n> $ git info --tree drivers/infiniband/\n> git kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git\n> \n> Extra: when you have such an implementation, you can use it for other purposes\n> as well such as the summary Documentation/ files want for the 00-INDEX files:\n> \n> $ git info --summary Documentation/BUG-HUNTING\n> brute force method of doing binary search of patches to find bug.\n> \n> And importantly -- when queuried for a file that itself doesn't have the\n> requested info tag:\n> \n> $ git info --cc drivers/infiniband/core/addr.c\n> \n> git looks for the tag on the drivers/infiniband/core/ directory next, and then\n> on drivers/infiniband/, where it finds it. linux-kernel@vger.kernel.org would\n> be the final fallback, being set on the project root.\n> \n> I'd really like something like this. As long as projects are both free to use\n> and not use them and free to define their own set of tags I believe this would\n> work very nicely.\n> \n> Once you have these tags, you can basically use them for anything.\n\nI'd really _love_ a tool that does all that what you've proposed above!\n\nBut why does it have to be \"git-info\" or anything in the git(7) suite for\nthat matter? This sounds like a job for a different specialised tool,\nalong with \".metatags\" kind of files dispersed in the source tree.\n\n\nSatyam\n"},{"id":"50773","messageId":"46C30220.6060007@gmail.com","threadId":"9523","inReplyTo":"alpine.LFD.0.999.0708151846130.16414@enigma.security.iitk.ac.in","subject":"Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl","fromName":"Rene Herman","fromEmail":"rene.herman@gmail.com","sentAt":"2007-08-15T13:39:44Z","receivedAt":"2007-08-15T13:39:44Z","isPatch":true,"sender":{"key":"rene.herman@gmail.com","avatar":null},"body":"On 08/15/2007 03:33 PM, Satyam Sharma wrote:\n\n[ git info --maintainer ]\n\n> I'd really _love_ a tool that does all that what you've proposed above!\n> \n> But why does it have to be \"git-info\" or anything in the git(7) suite for\n> that matter? This sounds like a job for a different specialised tool, \n> along with \".metatags\" kind of files dispersed in the source tree.\n\nTo automatically move (and delete) the meta-data alongside the files \nthemselves is a reason.\n\nMore generally -- shouldn't it? This is about source management (well, maybe \nmore about project management, but...) and the source code management tool \nlooks to be the right place for that. The different parts of git are \nsomewhat/fairly stand-alone as is, no?\n\nRene.\n"},{"id":"50775","messageId":"68B09015-4411-470A-BA88-732969469AA2@mac.com","threadId":"9523","inReplyTo":"46C30220.6060007@gmail.com","subject":"Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl","fromName":"Kyle Moffett","fromEmail":"mrmacman_g4@mac.com","sentAt":"2007-08-15T13:52:29Z","receivedAt":"2007-08-15T13:52:29Z","isPatch":true,"sender":{"key":"mrmacman_g4@mac.com","avatar":null},"body":"On Aug 15, 2007, at 09:39:44, Rene Herman wrote:\n> On 08/15/2007 03:33 PM, Satyam Sharma wrote:\n>\n> [ git info --maintainer ]\n>\n>> I'd really _love_ a tool that does all that what you've proposed \n>> above! But why does it have to be \"git-info\" or anything in the \n>> git(7) suite for that matter? This sounds like a job for a \n>> different specialised tool, long with \".metatags\" kind of files \n>> dispersed in the source tree.\n>\n> To automatically move (and delete) the meta-data alongside the \n> files themselves is a reason.\n>\n> More generally -- shouldn't it? This is about source management \n> (well, maybe more about project management, but...) and the source \n> code management tool looks to be the right place for that. The \n> different parts of git are somewhat/fairly stand-alone as is, no?\n\nIf you were going to do that I'd just suggest making git aware of the \n\"user.*\" extended attributes and having it save those into the git \nrepo along with the permission data.\n\nCheers,\nKyle Moffett\n"},{"id":"50783","messageId":"2c0942db0708150831k3bdf941u540b74b6b351920f@mail.gmail.com","threadId":"9523","inReplyTo":"46C2C762.7080205@s5r6.in-berlin.de","subject":"Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl","fromName":"Ray Lee","fromEmail":"ray@madrabbit.org","sentAt":"2007-08-15T15:31:28Z","receivedAt":"2007-08-15T15:31:28Z","isPatch":true,"sender":{"key":"ray@madrabbit.org","avatar":null},"body":"On 8/15/07, Stefan Richter wrote:\n> Linus Torvalds wrote:\n> > #!/bin/sh\n> > git log --since=6.months.ago -- \"$@\" |\n> > grep -i '^ [-a-z]*by:.*@' |\n> > sort | uniq -c |\n> > sort -r -n | head\n> >\n> > and it gives you a rather good picture of who is involved with a\n> > particular subdirectory or file.\n>\n> No, it doesn't. The subscribers of are\n> not listed in patch logs.\n\nThen maybe they should be added into the patch logs. A CC: line isn't\nthat big of a deal, and also shows who got notified.\n"},{"id":"50800","messageId":"1187198801.7443.20.camel@localhost","threadId":"9523","inReplyTo":"46C2E727.3050407@gmail.com","subject":"Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl","fromName":"Joe Perches","fromEmail":"joe@perches.com","sentAt":"2007-08-15T17:26:41Z","receivedAt":"2007-08-15T17:26:41Z","isPatch":true,"sender":{"key":"joe@perches.com","avatar":"https://avatars.githubusercontent.com/u/13122723?v=4"},"body":"On Wed, 2007-08-15 at 13:44 +0200, Rene Herman wrote:\n> On 08/15/2007 11:39 AM, Stefan Richter wrote:\n> > Note, maintainer contacts\n> > - should be available to patch submitters and\n> > - must be available to *problem reporters*\n> > without having to have git and a .git repo.\n> That \"must\" seems rather strong. But those few non-developer users that \n> could care are served by a MAINTAINERS file generated into releases.\n\nGood idea for scripts to help kernel bug reporters.\nREPORTING-BUGS is underutilized as a guide.\n\nI think Bug reporting is a separate issue from patch CC'ing.\nI'd rather have MAINTAINERS disappear altogether.\n"},{"id":"50811","messageId":"m3fy2kk2ra.fsf@maximus.localdomain","threadId":"9523","inReplyTo":"20070814193333.GI21089@ftp.linux.org.uk","subject":"Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl","fromName":"Krzysztof Halasa","fromEmail":"khc@pm.waw.pl","sentAt":"2007-08-15T19:37:45Z","receivedAt":"2007-08-15T19:37:45Z","isPatch":true,"sender":{"key":"khc@pm.waw.pl","avatar":null},"body":"Al Viro writes:\n\n> I'm not suggesting something like fs.ext2@kernel.org with something\n> like majordomo allowing to add yourself to those,\n\nWhy not\n\n> but something less\n> extreme in that direction might be worth thinking about... Hell,\n> even simple\n> $ finger fs/minix/dir.c@cc.kernel.org\n> with majordomo-like interface for adding yourself to such lists\n> might solve most of those problems...\n\nI think so.\n\nAnd you would be able to add yourself even if you're merely\ninterested in something, not a maintainer.\n\nHowever I think the mailing lists could do better. Duplicate\nsuppression, among other things.\n\nAnd they could eventually supersede the subsystem mailing lists\nwe use today. Just use net@kernel.org or drivers.net@kernel.org.\n-- \nKrzysztof Halasa\n"},{"id":"50838","messageId":"20070815231949.GM21089@ftp.linux.org.uk","threadId":"9523","inReplyTo":"m3fy2kk2ra.fsf@maximus.localdomain","subject":"Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl","fromName":"Al Viro","fromEmail":"viro@ftp.linux.org.uk","sentAt":"2007-08-15T23:19:49Z","receivedAt":"2007-08-15T23:19:49Z","isPatch":true,"sender":{"key":"viro@ftp.linux.org.uk","avatar":null},"body":"On Wed, Aug 15, 2007 at 09:37:45PM +0200, Krzysztof Halasa wrote:\n> > I'm not suggesting something like fs.ext2@kernel.org with something\n> > like majordomo allowing to add yourself to those,\n> \n> Why not\n\nYou'd need to implement serious anti-spam measures for that. Besides,\ncross-postings between random sets of lists would become a nightmare\npretty soon.\n"},{"id":"50874","messageId":"46C42DCB.1060502@gmail.com","threadId":"9523","inReplyTo":"68B09015-4411-470A-BA88-732969469AA2@mac.com","subject":"Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl","fromName":"Rene Herman","fromEmail":"rene.herman@gmail.com","sentAt":"2007-08-16T10:58:19Z","receivedAt":"2007-08-16T10:58:19Z","isPatch":true,"sender":{"key":"rene.herman@gmail.com","avatar":null},"body":"On 08/15/2007 03:52 PM, Kyle Moffett wrote:\n\n> On Aug 15, 2007, at 09:39:44, Rene Herman wrote:\n>> On 08/15/2007 03:33 PM, Satyam Sharma wrote:\n>>\n>> [ git info --maintainer ]\n>>\n>>> I'd really _love_ a tool that does all that what you've proposed \n>>> above! But why does it have to be \"git-info\" or anything in the \n>>> git(7) suite for that matter? This sounds like a job for a different \n>>> specialised tool, long with \".metatags\" kind of files dispersed in \n>>> the source tree.\n>>\n>> To automatically move (and delete) the meta-data alongside the files \n>> themselves is a reason.\n>>\n>> More generally -- shouldn't it? This is about source management (well, \n>> maybe more about project management, but...) and the source code \n>> management tool looks to be the right place for that. The different \n>> parts of git are somewhat/fairly stand-alone as is, no?\n> \n> If you were going to do that I'd just suggest making git aware of the \n> \"user.*\" extended attributes and having it save those into the git repo \n> along with the permission data.\n\nAm looking at it but am not so sure that's a very good idea. I guess it'd be \nlargely okay-ish to require the repo to be on a filesystem that supports EAs \nfor this feature to work, but keeping the attributes intact over file system \noperations seems not all that easy (yet). Having not used EAs before I may \nbe missing something but my version of \"cp\" for example (GNU coreutils 6.9) \nappears to not copy them. Nor do they seem to survive a trip through GNU tar \n1.16.1. EAs appear to not be very useful unless every single tool supports \nthem -- a repo should be resistant against simple operations like that.\n\nGoogling around, I see subversion already has this and calls the meta-data \n\"properties\" (svn propset/get and friends). It uses a few properties itself, \nsuch as the svn:executable property (which I saw is also the only permission \nbit git keeps) and svn:ignore, which serves the same role as the .gitignore \nfiles for git. Both those would fit into this scheme nicely for git as well, \nif git were to do something similar and reserve for example the \"git.*\" \nnamespace for internal use.\n\nJunio (and others), do you have an opinion on this? If these properties are \nversioned themselves such as in svn I believe it's a decidedly non-trivial \naddition (and I'm a complete git newbie) but to me, they look incredibly \nuseful, both for the original \"maintainers\" properties (and anyone else one \nwould want to come up with such as summary properties and author/license \nstuff) and even for git internal reasons such as sketched above.\n\nThe git-blame thing as sketched before by Linus would never be able to point \nout mailing lists, or general lists of \"interested parties\" for example, but \nthese properties can do anything...\n\nRene.\n"},{"id":"50875","messageId":"46C43015.7080804@gmail.com","threadId":"9523","inReplyTo":"46C42DCB.1060502@gmail.com","subject":"Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl","fromName":"Rene Herman","fromEmail":"rene.herman@gmail.com","sentAt":"2007-08-16T11:08:05Z","receivedAt":"2007-08-16T11:08:05Z","isPatch":true,"sender":{"key":"rene.herman@gmail.com","avatar":null},"body":"On 08/16/2007 12:58 PM, Rene Herman wrote:\n\n> On 08/15/2007 03:52 PM, Kyle Moffett wrote:\n\n>> If you were going to do that I'd just suggest making git aware of the \n>> \"user.*\" extended attributes and having it save those into the git \n>> repo along with the permission data.\n> \n> Am looking at it but am not so sure that's a very good idea. I guess \n> it'd be largely okay-ish to require the repo to be on a filesystem that \n> supports EAs for this feature to work, but keeping the attributes intact \n> over file system operations seems not all that easy (yet). Having not \n> used EAs before I may be missing something but my version of \"cp\" for \n> example (GNU coreutils 6.9) appears to not copy them. Nor do they seem \n> to survive a trip through GNU tar 1.16.1. EAs appear to not be very \n> useful unless every single tool supports them -- a repo should be \n> resistant against simple operations like that.\n> \n> Googling around, I see subversion already has this and calls the \n> meta-data \"properties\" (svn propset/get and friends). It uses a few \n> properties itself, such as the svn:executable property (which I saw is \n> also the only permission bit git keeps) and svn:ignore, which serves the \n> same role as the .gitignore files for git. Both those would fit into \n> this scheme nicely for git as well, if git were to do something similar \n> and reserve for example the \"git.*\" namespace for internal use.\n> \n> Junio (and others), do you have an opinion on this? If these properties \n> are versioned themselves such as in svn I believe it's a decidedly \n> non-trivial addition (and I'm a complete git newbie) but to me, they \n> look incredibly useful, both for the original \"maintainers\" properties \n> (and anyone else one would want to come up with such as summary \n> properties and author/license stuff) and even for git internal reasons \n> such as sketched above.\n> \n> The git-blame thing as sketched before by Linus would never be able to \n> point out mailing lists, or general lists of \"interested parties\" for \n> example, but these properties can do anything...\n\nThe svn implemention is that a single property is free-form text. As such, I \nguess a property would be just another file, although one that only lives in \nthe index and is linked from the file/directory it is a property of.\n\nPerhaps that immediately suggests an implementation to someone already \nfamiliar with git internals?\n\nRene.\n"},{"id":"50877","messageId":"fa1c95$sv6$1@sea.gmane.org","threadId":"9523","inReplyTo":"46C43015.7080804@gmail.com","subject":"Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl","fromName":"Salikh Zakirov","fromEmail":"salikh@gmail.com","sentAt":"2007-08-16T11:26:16Z","receivedAt":"2007-08-16T11:26:16Z","isPatch":true,"sender":{"key":"salikh@gmail.com","avatar":"https://gravatar.com/avatar/952c102bb1dcf721dab8de4f5a11d276756a65d301d021f755e265cc3251efae?d=mp&s=160"},"body":"Rene Herman wrote:\n> Perhaps that immediately suggests an implementation to someone already\n> familiar with git internals?\n\nperhaps http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html\nand http://www.kernel.org/pub/software/scm/git/docs/git-check-attr.html\ncan help you?\n"},{"id":"50880","messageId":"46C43BA3.6090807@gmail.com","threadId":"9523","inReplyTo":"fa1c95$sv6$1@sea.gmane.org","subject":"Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl","fromName":"Rene Herman","fromEmail":"rene.herman@gmail.com","sentAt":"2007-08-16T11:57:23Z","receivedAt":"2007-08-16T11:57:23Z","isPatch":true,"sender":{"key":"rene.herman@gmail.com","avatar":null},"body":"On 08/16/2007 01:26 PM, Salikh Zakirov wrote:\n\nPlease don't drop CCs.\n\n> Rene Herman wrote:\n>> Perhaps that immediately suggests an implementation to someone already\n>> familiar with git internals?\n> \n> perhaps http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html\n> and http://www.kernel.org/pub/software/scm/git/docs/git-check-attr.html\n> can help you?\n\nNo, thanks, saw them, but .gitattributes is in fact in the same category as \n.gitignore, which would _be_ a property.\n\nIf you do this stuff in files scattered around the tree, updating and moving \nstuff becomes a pain -- the tool would need to go edit files.\n\nRene.\n"},{"id":"50891","messageId":"20070816154029.GN21089@ftp.linux.org.uk","threadId":"9523","inReplyTo":"46C42DCB.1060502@gmail.com","subject":"Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl","fromName":"Al Viro","fromEmail":"viro@ftp.linux.org.uk","sentAt":"2007-08-16T15:40:29Z","receivedAt":"2007-08-16T15:40:29Z","isPatch":true,"sender":{"key":"viro@ftp.linux.org.uk","avatar":null},"body":"On Thu, Aug 16, 2007 at 12:58:19PM +0200, Rene Herman wrote:\n \n> Googling around, I see subversion already has this and calls the meta-data \n> \"properties\" (svn propset/get and friends). It uses a few properties \n> itself, such as the svn:executable property (which I saw is also the only \n> permission bit git keeps) and svn:ignore, which serves the same role as the \n> .gitignore files for git. Both those would fit into this scheme nicely for \n> git as well, if git were to do something similar and reserve for example \n> the \"git.*\" namespace for internal use.\n\n\"svn does it\" is usually an indication of a bad idea, but anyway - it's\nfundamentally wrong in this case, simply because \"$FOO is interested\nin $BAR\" is a property of $FOO, not of $BAR.\n\n> The git-blame thing as sketched before by Linus would never be able to \n> point out mailing lists, or general lists of \"interested parties\" for \n> example, but these properties can do anything...\n\nNo, they can not. \"I'm interested in drivers/foo/bar.c fixes\" is not\nan earth-shattering event and it sure as hell does not create a new revision\nof the tree.\n"},{"id":"50894","messageId":"46C472E1.6060703@gmail.com","threadId":"9523","inReplyTo":"20070816154029.GN21089@ftp.linux.org.uk","subject":"Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl","fromName":"Rene Herman","fromEmail":"rene.herman@gmail.com","sentAt":"2007-08-16T15:53:05Z","receivedAt":"2007-08-16T15:53:05Z","isPatch":true,"sender":{"key":"rene.herman@gmail.com","avatar":null},"body":"On 08/16/2007 05:40 PM, Al Viro wrote:\n\n> On Thu, Aug 16, 2007 at 12:58:19PM +0200, Rene Herman wrote:\n\n>> The git-blame thing as sketched before by Linus would never be able to \n>> point out mailing lists, or general lists of \"interested parties\" for \n>> example, but these properties can do anything...\n> \n> No, they can not. \"I'm interested in drivers/foo/bar.c fixes\" is not\n> an earth-shattering event and it sure as hell does not create a new revision\n> of the tree.\n\nThat's true. Okay, it can't do those general lists of interested parties.\n\nRene.\n"},{"id":"50900","messageId":"7v7invjodw.fsf@gitster.siamese.dyndns.org","threadId":"9523","inReplyTo":"46C42DCB.1060502@gmail.com","subject":"Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-16T19:00:27Z","receivedAt":"2007-08-16T19:00:27Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Rene Herman writes:\n\n> Am looking at it but am not so sure that's a very good idea. I guess\n> it'd be largely okay-ish to require the repo to be on a filesystem\n> that supports EAs for this feature to work, but keeping the attributes\n> intact over file system operations seems not all that easy\n> (yet). Having not used EAs before I may be missing something but my\n> version of \"cp\" for example (GNU coreutils 6.9) appears to not copy\n> them. Nor do they seem to survive a trip through GNU tar 1.16.1. EAs\n> appear to not be very useful unless every single tool supports them --\n> a repo should be resistant against simple operations like that.\n>\n> Googling around, I see subversion already has this and calls the\n> meta-data \"properties\" (svn propset/get and friends). It uses a few\n> properties itself, such as the svn:executable property (which I saw is\n> also the only permission bit git keeps) and svn:ignore, which serves\n> the same role as the .gitignore files for git. Both those would fit\n> into this scheme nicely for git as well, if git were to do something\n> similar and reserve for example the \"git.*\" namespace for internal use.\n>\n> Junio (and others), do you have an opinion on this?\n\nPlease step back a bit and imagine a world in which there was no\ngit. IOW, you kernel folks switched to tarballs and patches 20\nmonths ago. It is a far superiour solution compared to CVS and\nSVN, so it ought to work, right ;-)?\n\nNow, would you implement the \"whom would I send my patches to\"\nwith EAs?\n\nI would hope not.\n\nGit or no git, I think a file that can be viewed with less,\nedited with regular editor and processed with sed/perl/grep\ntools is the way to go. I do not think adding 600+ patches to\nthe single MAINTAINERS list is workable in the longer term, as\nit would become the single file many subsystem people need to\nupdate and is asking for merge conflicts, but I think a file\nwith known name (say, \"CcMe.txt\") sprinkled in relevant\nsubdirectories, perhaps with the same format originally\nsuggested for MAINTAINERS, would make a lot more sense.\n\nThat would give people who work with tarballs and patches, or a\nsubsystem managed with something other than git (one of the most\nimportant one is quilt), the equal access to the necessary data.\n\nEven with git, it is my understanding that kernel community\nworks largely on patches exchanged over e-mails, between people\nwho do use git and people who do not. You would want to have\nsomething you can easily transfer over e-mail in the patch\nform.\n\nWe _could_ invent a new \"patches to properties\" git diff output\nformat that \"git apply\" can understand to propagate that\ninformation, but that approach is making it less interoperable\nwith others, and you need to demonstrate the benefit far\noutweighs that. I do not see it for this particular\napplication.\n\nThere may be places for \"properties\" that would be useful to\ngit, but I do not think the \"find whom to send patches to\" is\none of them.\n"},{"id":"50902","messageId":"1187296616.5906.100.camel@localhost","threadId":"9523","inReplyTo":"alpine.LFD.0.999.0708141131140.30176@woody.linux-foundation.org","subject":"Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl","fromName":"Joe Perches","fromEmail":"joe@perches.com","sentAt":"2007-08-16T20:36:55Z","receivedAt":"2007-08-16T20:36:55Z","isPatch":true,"sender":{"key":"joe@perches.com","avatar":"https://avatars.githubusercontent.com/u/13122723?v=4"},"body":"On Tue, 2007-08-14 at 11:40 -0700, Linus Torvalds wrote:\n> Do a script like this:\n> \n> \t#!/bin/sh\n> \tgit log --since=6.months.ago -- \"$@\" |\n> \t\tgrep -i '^ [-a-z]*by:.*@' |\n> \t\tsort | uniq -c |\n> \t\tsort -r -n | head\n> (Maybe you want to add a\n> \tgrep -v '\\(Linus Torvalds\\)\\|\\(Andrew Morton\\)'\n> to avoid seeing the normal chain too much, but hey, we probably want to \n> know too. Anyway - the script can certainly be tweaked, the point is \n> really just that the git tree _already_ contains the relevant \n> information).\n\nSo, here's the same get_maintainer.pl with the git\naddition. Seems to work well in combination with MAINTAINERS.\n\ndiff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl\nnew file mode 100755\nindex 0000000..eb3f023\n--- /dev/null\n+++ b/scripts/get_maintainer.pl\n@@ -0,0 +1,351 @@\n+#!/usr/bin/perl -w\n+# (c) 2007, Joe Perches \n+# created from checkpatch.pl\n+#\n+# Print the contact information for the maintainers\n+# of the files modified in a patch\n+#\n+# usage: perl scripts/get_maintainers.pl \n+#\n+# Licensed under the terms of the GNU GPL License version 2\n+\n+use strict;\n+\n+my $P = $0;\n+$P =~ s@.*/@@g;\n+\n+my $V = '0.06';\n+\n+use Getopt::Long qw(:config no_auto_abbrev);\n+\n+my $tree = \"./\";\n+my $email_maintainer = 1;\n+my $email_usename = 1;\n+my $email_list = 1;\n+my $email_subscriber_list = 0;\n+my $email_separator = \", \";\n+my $email_git = 1;\n+my $email_git_chief_penguins = 0;\n+my $email_multiline = 0;\n+my %saw;\n+\n+my $chief_penguins = \"(Linus Torvalds|Andrew Morton)\";\n+\n+GetOptions(\n+\t 'tree=s' => \\$tree,\n+\t 'git!' => $email_git,\n+\t 'git-chief-penguins' => \\$email_git_chief_penguins,\n+\t 'm!' => \\$email_maintainer,\n+\t 'n!' => \\$email_usename,\n+\t 'l!' => \\$email_list,\n+\t 's!' => \\$email_subscriber_list,\n+\t 'multiline!' => \\$email_multiline,\n+\t 'separator=s' => \\$email_separator,\n+\t ) or exit;\n+\n+my $exit = 0;\n+\n+if ($#ARGV < 0 ||\n+ ($email_maintainer == 0\n+ && $email_list == 0\n+ && $email_subscriber_list == 0\n+ && $email_git == 0)) {\n+ print \"usage: $P [options] patchfile\\n\";\n+ print \"version: $V\\n\";\n+ print \" --tree [path] => linux kernel source path\\n\";\n+ print \" --git => include recent git \\*-by: signers\\n\";\n+ print \" --git_chief_penguins => include ${chief_penguins}\\n\";\n+ print \" --m => include maintainer(s) if any\\n\";\n+ print \" --n => include name 'Full Name '\\n\";\n+ print \" --l => include list(s) if any\\n\";\n+ print \" --s => include subscriber only list(s) if any\\n\";\n+ print \" --separator [, ] => separator for multiple addresses on 1 line\\n\";\n+ print \" --multiline => print 1 address per line\\n\";\n+ print \"Default: [--g --m --l --separator \\\", \\\"]\\n\";\n+ print \"Be sure to select something...\\n\";\n+ exit(1);\n+}\n+\n+if ($tree && !top_of_kernel_tree($tree)) {\n+ if (${tree} ne \"\") {\n+\tprint \"'${tree}' \";\n+ } else {\n+\tprint \"The current directory \";\n+ }\n+ print \"doesn't appear to be a linux kernel source tree\\n\";\n+ exit(2);\n+}\n+\n+## Read MAINTAINERS for type/value pairs\n+\n+my @typevalue = ();\n+open(MAINT, \"<${tree}MAINTAINERS\") || die \"$P: Can't open ${tree}MAINTAINERS\\n\";\n+while () {\n+ if (m/^(\\C):\\s*(.*)/) {\n+\tmy $type = $1;\n+\tmy $value = $2;\n+\n+\t##Filename pattern matching\n+\tif ($type eq \"F\" || $type eq \"X\") {\n+\t $value =~ s@\\.@\\\\\\.@g; ##Convert . to \\.\n+\t $value =~ s/\\*/\\.\\*/g; ##Convert * to .*\n+\t}\n+\tpush(@typevalue, \"$type:$value\");\n+ } elsif (!/^(\\s)*$/) {\n+\tpush(@typevalue, $_);\n+ }\n+}\n+close(MAINT);\n+\n+## Find the patched filenames\n+\n+my @patchedfiles = ();\n+open(PATCH, \"<$ARGV[0]\") or die \"Can't open $ARGV[0]\\n\";\n+while () {\n+ if (m/^\\+\\+\\+\\s+(\\S+)/) {\n+\tmy $file = $1;\n+\t$file =~ s@^[^/]*/@@;\n+\t$file =~ s@\\n@@;\n+\tpush(@patchedfiles, $file);\n+ }\n+}\n+close(PATCH);\n+\n+# Sort and uniq patchedfiles\n+\n+undef %saw;\n+@patchedfiles = sort @patchedfiles;\n+@patchedfiles = grep(!$saw{$_}++, @patchedfiles);\n+\n+# Find responsible parties\n+\n+my @email_to = ();\n+foreach (@patchedfiles) {\n+ my $patchedfile = $_;\n+ my $exclude = 0;\n+\n+#Git\n+\n+ recent_git_signoffs($patchedfile);\n+\n+#Do not match excluded file patterns\n+\n+ foreach (@typevalue) {\n+\tif (m/^(\\C):(.*)/) {\n+\t my $type = $1;\n+\t my $value = $2;\n+\t if ($type eq 'X') {\n+\t\tif (file_match_pattern($patchedfile, $value)) {\n+\t\t $exclude = 1;\n+\t\t}\n+\t }\n+\t}\n+ }\n+\n+ if ($exclude == 0) {\n+\tmy $tvi = 0;\n+\tforeach (@typevalue) {\n+\t if (m/^(\\C):(.*)/) {\n+\t\tmy $type = $1;\n+\t\tmy $value = $2;\n+\t\tif ($type eq 'F') {\n+\t\t if (file_match_pattern($patchedfile, $value)) {\n+\t\t\tadd_emails($tvi);\n+\t\t }\n+\t\t}\n+\t }\n+\t $tvi++;\n+\t}\n+ }\n+}\n+\n+## sort and uniq email_to\n+\n+@email_to = sort @email_to;\n+undef %saw;\n+@email_to = grep(!$saw{$_}++, @email_to);\n+\n+## add lk if no one is interested...\n+\n+my $address_cnt = @email_to;\n+if ($address_cnt == 0 && $email_list > 0) {\n+ push(@email_to, \"linux-kernel\\@vger.kernel.org\");\n+}\n+if ($email_multiline != 0) {\n+ foreach (@email_to) {\n+\tprint(\"$_\\n\");\n+ }\n+} else {\n+ print(join($email_separator, @email_to));\n+ print(\"\\n\");\n+}\n+\n+exit($exit);\n+\n+sub file_match_pattern {\n+ my ($file, $pattern) = @_;\n+ if (substr($pattern, -1) eq \"/\") {\n+\tif ($file =~ m@^$pattern@) {\n+\t return 1;\n+\t}\n+ } else {\n+\tif ($file =~ m@^$pattern@) {\n+\t my $s1 = ($file =~ tr@/@@);\n+\t my $s2 = ($pattern =~ tr@/@@);\n+\t if ($s1 == $s2) {\n+\t\treturn 1;\n+\t }\n+\t}\n+ }\n+ return 0;\n+}\n+\n+sub top_of_kernel_tree {\n+\tmy ($tree) = @_;\n+\n+\tif ($tree ne \"\" && substr($tree,length($tree)-1,1) ne \"/\") {\n+\t $tree = $tree . \"/\";\n+\t}\n+\tif ( (-f \"${tree}COPYING\")\n+\t && (-f \"${tree}CREDITS\")\n+\t && (-f \"${tree}Kbuild\")\n+\t && (-f \"${tree}MAINTAINERS\")\n+\t && (-f \"${tree}Makefile\")\n+\t && (-f \"${tree}README\")\n+\t && (-d \"${tree}Documentation\")\n+\t && (-d \"${tree}arch\")\n+\t && (-d \"${tree}include\")\n+\t && (-d \"${tree}drivers\")\n+\t && (-d \"${tree}fs\")\n+\t && (-d \"${tree}init\")\n+\t && (-d \"${tree}ipc\")\n+\t && (-d \"${tree}kernel\")\n+\t && (-d \"${tree}lib\")\n+\t && (-d \"${tree}scripts\")) {\n+\t\treturn 1;\n+\t}\n+\treturn 0;\n+}\n+\n+sub format_email {\n+ my ($name, $email) = @_;\n+ my $formatted_email = $name;\n+\n+ if ($name =~ /[^a-z0-9 \\.\\-]/i) { ##has \"must quote\" chars\n+\t$name =~ s/(?\";\n+ } else {\n+\t$formatted_email = \"${name} \\<${email}\\>\";\n+ }\n+ return $formatted_email;\n+}\n+\n+sub add_emails {\n+ my ($index) = @_;\n+\n+ $index = $index - 1;\n+ while ($index >= 0) {\n+\tmy $tv = $typevalue[$index];\n+\tif ($tv =~ m/^(\\C):(.*)/) {\n+\t my $ptype = $1;\n+\t my $pvalue = $2;\n+\t if ($ptype eq \"L\") {\n+\t\tmy $subscr = $pvalue;\n+\t\tif ($subscr =~ m/\\s*\\(subscribers-only\\)/) {\n+\t\t if ($email_subscriber_list > 0) {\n+\t\t\t$subscr =~ s/\\s*\\(subscribers-only\\)//g;\n+\t\t\tpush(@email_to, $subscr);\n+\t\t }\n+\t\t} else {\n+\t\t if ($email_list > 0) {\n+\t\t\tpush(@email_to, $pvalue);\n+\t\t }\n+\t\t}\n+\t } elsif ($ptype eq \"M\") {\n+\t\tif ($email_maintainer > 0) {\n+\t\t if ($index >= 0) {\n+\t\t\tmy $tv = $typevalue[$index - 1];\n+\t\t\tif ($tv =~ m/^(\\C):(.*)/) {\n+\t\t\t if ($1 eq \"P\" && $email_usename > 0) {\n+\t\t\t\tpush(@email_to, format_email($2, $pvalue));\n+\t\t\t } else {\n+\t\t\t\tpush(@email_to, $pvalue);\n+\t\t\t }\n+\t\t\t}\n+\t\t } else {\n+\t\t\tpush(@email_to, $pvalue);\n+\t\t }\n+\t\t}\n+\t }\n+\t $index--;\n+\t} else {\n+\t $index = -1;\n+\t}\n+ }\n+}\n+\n+sub which {\n+ my ($bin) = @_;\n+\n+ my $path;\n+\n+ foreach $path (split /:/, $ENV{PATH}) {\n+\tif (-e \"$path/$bin\") {\n+\t return \"$path/$bin\";\n+\t}\n+ }\n+ \n+ return \"\";\n+}\n+\n+sub recent_git_signoffs {\n+ my ($file) = @_;\n+\n+ my $sign_offs = \"\";\n+ my $cmd = \"\";\n+ my $output = \"\";\n+\n+ my @lines = ();\n+\n+ if (which(\"git\") eq \"\") {\n+\tdie(\"Git not found\\n\");\n+ }\n+\n+# Search the git logs for \"by:\" lines per file\n+# sort in reverse order by occurance\n+# add at most 5\n+\n+ $cmd = \"git log --since=6.months.ago -- ${file} \";\n+ $cmd = $cmd . \" | grep -i '^ [-a-z]*by:.*\\\\\\@' \";\n+ if ($email_git_chief_penguins == 0) {\n+\t$cmd = $cmd . \" | grep -E -v '${chief_penguins}'\";\n+ }\n+ $cmd = $cmd . \" | sort | uniq -c | sort -r -n | head -n 5\";\n+ $cmd = $cmd . \" | cut -f 2 -d ':' -s \";\n+\n+ $output = `${cmd}`;\n+\n+ $output =~ s/^\\s*//gm;\n+\n+ @lines = split(\"\\n\", $output);\n+ foreach (@lines) {\n+\tmy $line = $_;\n+\tif ($line =~ m/(.*) <(.*)>/) {\n+\t my $git_name = $1;\n+\t my $git_addr = $2;\n+\t $git_name =~ tr/^\\\"//;\n+\t $git_name =~ tr/\\\"$//;\n+\t if ($email_usename > 0) {\n+\t\tpush(@email_to, format_email($git_name, $git_addr));\n+\t } else {\n+\t\tpush(@email_to, $git_addr);\n+\t }\n+\t} elsif ($line =~ m/<(.*)>/) {\n+\t my $git_addr = $1;\n+\t push(@email_to, $git_addr);\n+\t} else {\n+\t push(@email_to, $line);\n+\t}\n+ }\n+ return $output;\n+}\n"},{"id":"50909","messageId":"1187316783.822.19.camel@localhost","threadId":"9523","inReplyTo":"7vwsvx8twx.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl","fromName":"Joe Perches","fromEmail":"joe@perches.com","sentAt":"2007-08-17T02:13:03Z","receivedAt":"2007-08-17T02:13:03Z","isPatch":true,"sender":{"key":"joe@perches.com","avatar":"https://avatars.githubusercontent.com/u/13122723?v=4"},"body":"On Tue, 2007-08-14 at 18:31 -0700, Junio C Hamano wrote:\n> On the other hand, git-send-email _is_ all about sending it\n> out, and it needs to know who your patch should reach. I\n> think it makes sense to have one script that, given a set of\n> paths that are affected, gives a list of potentially\n> interested people (that is \"Finding\" part -- and I see there\n> are 600+ patches to implement this on the list), and a new\n> option to git-send-email to (1) inspect the patch to see what\n> paths are affected, and (2) call that \"Find\" script to figure\n> out whom to send it to, and probably asking for confirmation.\n\nSorry, not a git developer, so the paths are wrong.\nThis seems to work:\n\nExample:\n\ngit-send-email \\\n --cc-cmd \"perl scripts/get_maintainers.pl -non -multiline\" foo.diff\n\n--- git-send-email.pl\t2007-08-16 19:06:07.000000000 -0700\n+++ /usr/local/bin/git-send-email\t2007-05-01 11:59:14.000000000 -0700\n@@ -47,9 +47,6 @@ Options:\n --cc Specify an initial \"Cc:\" list for the entire series\n of emails.\n \n- --cc-cmd Specify a command to execute per file which adds\n- per file specific cc address entries\n-\n --bcc Specify a list of email addresses that should be Bcc:\n \t\t on all the emails.\n \n@@ -143,7 +140,7 @@ my (@to,@cc,@initial_cc,@bcclist,@xh,\n \n # Behavior modification variables\n my ($chain_reply_to, $quiet, $suppress_from, $no_signed_off_cc,\n-\t$dry_run, $cc_cmd) = (1, 0, 0, 0, 0, 0);\n+\t$dry_run) = (1, 0, 0, 0, 0);\n my $smtp_server;\n my $envelope_sender;\n \n@@ -176,7 +173,6 @@ my $rc = GetOptions(\"from=s\" => \\$from,\n \t\t \"subject=s\" => \\$initial_subject,\n \t\t \"to=s\" => \\@to,\n \t\t \"cc=s\" => \\@initial_cc,\n-\t\t \"cc-cmd=s\" => \\$cc_cmd,\n \t\t \"bcc=s\" => \\@bcclist,\n \t\t \"chain-reply-to!\" => \\$chain_reply_to,\n \t\t \"smtp-server=s\" => \\$smtp_server,\n@@ -611,16 +607,6 @@ foreach my $t (@files) {\n \t\t}\n \t}\n \tclose F;\n-\n-\tif (${cc_cmd} ne \"\") {\n-\t my $output = `${cc_cmd} $t`;\n-\t my @lines = split(\"\\n\", $output);\n-\t foreach my $c (@lines) {\n-\t\tpush @cc, $c;\n-\t\tprintf(\"(sob) Adding cc: %s from cc-cmd: '%s'\\n\", $c, $t) unless $quiet;\n-\t }\n-\t}\n-\n \tif (defined $author_not_sender) {\n \t\t$author_not_sender = unquote_rfc2047($author_not_sender);\n \t\t$message = \"From: $author_not_sender\\n\\n$message\";\n"},{"id":"50912","messageId":"1187317826.822.23.camel@localhost","threadId":"9523","inReplyTo":"1187316783.822.19.camel@localhost","subject":"Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl","fromName":"Joe Perches","fromEmail":"joe@perches.com","sentAt":"2007-08-17T02:30:26Z","receivedAt":"2007-08-17T02:30:26Z","isPatch":true,"sender":{"key":"joe@perches.com","avatar":"https://avatars.githubusercontent.com/u/13122723?v=4"},"body":"On Thu, 2007-08-16 at 19:13 -0700, Joe Perches wrote:\n> Sorry, not a git developer, so the paths are wrong.\n> This seems to work:\n\nSorry. Patch reversed too.\n\n--- /usr/local/bin/git-send-email\t2007-05-01 11:59:14.000000000 -0700\n+++ /home/joe/bin/git-send-email.pl\t2007-08-16 19:25:53.000000000 -0700\n@@ -47,6 +47,9 @@ Options:\n --cc Specify an initial \"Cc:\" list for the entire series\n of emails.\n \n+ --cc-cmd Specify a command to execute per file which adds\n+ per file specific cc address entries\n+\n --bcc Specify a list of email addresses that should be Bcc:\n \t\t on all the emails.\n \n@@ -140,7 +143,7 @@ my (@to,@cc,@initial_cc,@bcclist,@xh,\n \n # Behavior modification variables\n my ($chain_reply_to, $quiet, $suppress_from, $no_signed_off_cc,\n-\t$dry_run) = (1, 0, 0, 0, 0);\n+\t$dry_run, $cc_cmd) = (1, 0, 0, 0, 0, \"\");\n my $smtp_server;\n my $envelope_sender;\n \n@@ -173,6 +176,7 @@ my $rc = GetOptions(\"from=s\" => \\$from,\n \t\t \"subject=s\" => \\$initial_subject,\n \t\t \"to=s\" => \\@to,\n \t\t \"cc=s\" => \\@initial_cc,\n+\t\t \"cc-cmd=s\" => \\$cc_cmd,\n \t\t \"bcc=s\" => \\@bcclist,\n \t\t \"chain-reply-to!\" => \\$chain_reply_to,\n \t\t \"smtp-server=s\" => \\$smtp_server,\n@@ -607,6 +611,16 @@ foreach my $t (@files) {\n \t\t}\n \t}\n \tclose F;\n+\n+\tif (${cc_cmd} ne \"\") {\n+\t my $output = `${cc_cmd} $t`;\n+\t my @lines = split(\"\\n\", $output);\n+\t foreach my $c (@lines) {\n+\t\tpush @cc, $c;\n+\t\tprintf(\"(sob) Adding cc: %s from cc-cmd: '%s'\\n\", $c, $t) unless $quiet;\n+\t }\n+\t}\n+\n \tif (defined $author_not_sender) {\n \t\t$author_not_sender = unquote_rfc2047($author_not_sender);\n \t\t$message = \"From: $author_not_sender\\n\\n$message\";\n"},{"id":"50916","messageId":"46C522F5.9080802@gmail.com","threadId":"9523","inReplyTo":"7v7invjodw.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl","fromName":"Rene Herman","fromEmail":"rene.herman@gmail.com","sentAt":"2007-08-17T04:24:21Z","receivedAt":"2007-08-17T04:24:21Z","isPatch":true,"sender":{"key":"rene.herman@gmail.com","avatar":null},"body":"On 08/16/2007 09:00 PM, Junio C Hamano wrote:\n\n> Git or no git, I think a file that can be viewed with less,\n> edited with regular editor and processed with sed/perl/grep\n> tools is the way to go. I do not think adding 600+ patches to\n> the single MAINTAINERS list is workable in the longer term, as\n> it would become the single file many subsystem people need to\n> update and is asking for merge conflicts, but I think a file\n> with known name (say, \"CcMe.txt\") sprinkled in relevant\n> subdirectories, perhaps with the same format originally\n> suggested for MAINTAINERS, would make a lot more sense.\n> \n> That would give people who work with tarballs and patches, or a\n> subsystem managed with something other than git (one of the most\n> important one is quilt), the equal access to the necessary data.\n\nThat is ofcourse an argument but I believe a bit of a non-argument at the \nsame time in practice.\n\nThere's really not much point in pretending that non-git users are still \nfirst class citizens anyway; Linus' own suggestion of using git-blame would \ntie things to git as well, as do for example frequent requests to bisect a \nproblem. I moreover feel there's absolutely nothing wrong with that, given \nthat there's nothing wrong with git.\n\nIt's the kernel's source code management tool, is included out of the box in \nmost distributions nowadays and is GPLd meaning that the tool (itself) won't \nkeep anyone from exporting data from it and importing it into something else \nif someone cares to. Also, I never managed to stay un-annoyed at source code \nmanagement tools long enough to understand why I wanted to use them but have \nbeen using git for months now so as far as I am concerned, it appears to \neven be a good tool.\n\nBut, well, anyways, I did look at a git repo a bit but will unfortunately \nnot be able to follow up the proposal with actual (good) code in a sensible \ntimeframe, let alone \"quickly\", which means I was hoping others would agree. \nI believe these properties make for an elegant setup with many possible uses \nincluding the maintainers information, but if you disagree I guess I'm going \nto shelve it...\n\n> Even with git, it is my understanding that kernel community\n> works largely on patches exchanged over e-mails, between people\n> who do use git and people who do not. You would want to have\n> something you can easily transfer over e-mail in the patch\n> form.\n> \n> We _could_ invent a new \"patches to properties\" git diff output\n> format that \"git apply\" can understand to propagate that\n> information\n\nYes, not unlike the current git move \"meta-diffs\" ...\n\n> but that approach is making it less interoperable with others, and you \n> need to demonstrate the benefit far outweighs that. I do not see it for \n> this particular application.\n> \n> There may be places for \"properties\" that would be useful to git, but I \n> do not think the \"find whom to send patches to\" is one of them.\n\nThe important reason for wiring this into git directly would be keeping the \nmeta-data in sync with the data it refers to in an automated fashion. With \nmanual intervention, there's much more opportunity for things to grow stale.\n\nIn practice, it may not be a huge problem. It certainly is with the current \nMAINTAINERS file but if one does finer-grained data around the tree, that \nwill probably help.\n\nIt's also not a now or never thing fortunately. If git does ever grow these \nproperties, the issue can be revisited, perhaps at that time both with the \nexperience of what the finer-grained in-tree solution did not solve and even \nfewer people around that care about not making git even more of an intrinsic \npart of development.\n\nRene.\n"},{"id":"50948","messageId":"1187373278.822.100.camel@localhost","threadId":"9523","inReplyTo":"1187317826.822.23.camel@localhost","subject":"[PATCH] - git-send-email.perl","fromName":"Joe Perches","fromEmail":"joe@perches.com","sentAt":"2007-08-17T17:54:38Z","receivedAt":"2007-08-17T17:54:38Z","isPatch":true,"sender":{"key":"joe@perches.com","avatar":"https://avatars.githubusercontent.com/u/13122723?v=4"},"body":"Here's a path to enable a command line option\nthat takes a string argument\n\n\tcc-cmd\n\nThis modifies the @cc array to include whatever\noutput is produced by cc_cmd $patchfile\n\ncccmd can be stored in a config settings file\n\nprevious versions of this patch were submitted\nagainst an older version of git-send-email.perl\n\ndiff --git a/git-send-email.perl b/git-send-email.perl\nindex 69559b2..828a77a 100755\n--- a/git-send-email.perl\n+++ b/git-send-email.perl\n@@ -46,6 +46,9 @@ Options:\n --cc Specify an initial \"Cc:\" list for the entire series\n of emails.\n \n+ --cc-cmd Specify a command to execute per file which adds\n+ per file specific cc address entries\n+\n --bcc Specify a list of email addresses that should be Bcc:\n \t\t on all the emails.\n \n@@ -157,13 +160,14 @@ if ($@) {\n my ($quiet, $dry_run) = (0, 0);\n \n # Variables with corresponding config settings\n-my ($thread, $chain_reply_to, $suppress_from, $signed_off_cc);\n+my ($thread, $chain_reply_to, $suppress_from, $signed_off_cc, $cc_cmd);\n \n my %config_settings = (\n \"thread\" => [\\$thread, 1],\n \"chainreplyto\" => [\\$chain_reply_to, 1],\n \"suppressfrom\" => [\\$suppress_from, 0],\n \"signedoffcc\" => [\\$signed_off_cc, 1],\n+ \"cccmd\" => [\\$cc_cmd, \"\"],\n );\n \n foreach my $setting (keys %config_settings) {\n@@ -189,6 +193,7 @@ my $rc = GetOptions(\"sender|from=s\" => \\$sender,\n \t\t \"smtp-server=s\" => \\$smtp_server,\n \t\t \"compose\" => \\$compose,\n \t\t \"quiet\" => \\$quiet,\n+\t\t \"cc-cmd=s\" => \\$cc_cmd,\n \t\t \"suppress-from!\" => \\$suppress_from,\n \t\t \"signed-off-cc|signed-off-by-cc!\" => \\$signed_off_cc,\n \t\t \"dry-run\" => \\$dry_run,\n@@ -652,11 +657,21 @@ foreach my $t (@files) {\n \t\t}\n \t}\n \tclose F;\n+\n+\tif (${cc_cmd} ne \"\") {\n+\t my $output = `${cc_cmd} $t`;\n+\t my @lines = split(\"\\n\", $output);\n+\t foreach my $c (@lines) {\n+\t\tpush @cc, $c;\n+\t\tprintf(\"(cc-cmd) Adding cc: %s from: '%s'\\n\", $c, $cc_cmd)\n+\t\t unless $quiet;\n+\t }\n+\t}\n+\n \tif (defined $author) {\n \t\t$message = \"From: $author\\n\\n$message\";\n \t}\n \n-\n \tsend_message();\n \n \t# set up for the next message\n"},{"id":"50969","messageId":"7vy7g9enqd.fsf@gitster.siamese.dyndns.org","threadId":"9523","inReplyTo":"1187373278.822.100.camel@localhost","subject":"Re: [PATCH] - git-send-email.perl","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-17T23:38:02Z","receivedAt":"2007-08-17T23:38:02Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Joe Perches writes:\n\n> Here's a path to enable a command line option\n> that takes a string argument\n>\n> \tcc-cmd\n>\n> This modifies the @cc array to include whatever\n> output is produced by cc_cmd $patchfile\n>\n> cccmd can be stored in a config settings file\n>\n> previous versions of this patch were submitted\n> against an older version of git-send-email.perl\n\n... Signed-off-by: ...\n\n\n> diff --git a/git-send-email.perl b/git-send-email.perl\n> index 69559b2..828a77a 100755\n> --- a/git-send-email.perl\n> +++ b/git-send-email.perl\n> @@ -46,6 +46,9 @@ Options:\n> --cc Specify an initial \"Cc:\" list for the entire series\n> of emails.\n> \n> + --cc-cmd Specify a command to execute per file which adds\n> + per file specific cc address entries\n> +\n> --bcc Specify a list of email addresses that should be Bcc:\n> \t\t on all the emails.\n> \n\nI do not see a patch to \"Documentation/git-send-email.txt\" here...\n\n> @@ -652,11 +657,21 @@ foreach my $t (@files) {\n> \t\t}\n> \t}\n> \tclose F;\n> +\n> +\tif (${cc_cmd} ne \"\") {\n> +\t my $output = `${cc_cmd} $t`;\n> +\t my @lines = split(\"\\n\", $output);\n> +\t foreach my $c (@lines) {\n> +\t\tpush @cc, $c;\n> +\t\tprintf(\"(cc-cmd) Adding cc: %s from: '%s'\\n\", $c, $cc_cmd)\n> +\t\t unless $quiet;\n> +\t }\n> +\t}\n> +\n\nSomething like this, with appropriate error checking, perhaps?\n\n\topen my $cc, \"${cc_cmd} $t |\";\n while (my $c = <$cc>) {\n \t...\n\t}\n close $cc;\n"},{"id":"50972","messageId":"1187401873.822.146.camel@localhost","threadId":"9523","inReplyTo":"7vy7g9enqd.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] - git-send-email.perl","fromName":"Joe Perches","fromEmail":"joe@perches.com","sentAt":"2007-08-18T01:51:12Z","receivedAt":"2007-08-18T01:51:12Z","isPatch":true,"sender":{"key":"joe@perches.com","avatar":"https://avatars.githubusercontent.com/u/13122723?v=4"},"body":"On Fri, 2007-08-17 at 16:38 -0700, Junio C Hamano wrote:\n> Joe Perches writes:\n> ... Signed-off-by: ...\n> I do not see a patch to \"Documentation/git-send-email.txt\" here...\n> Something like this, with appropriate error checking, perhaps?\n> \n> \topen my $cc, \"${cc_cmd} $t |\";\n> while (my $c = <$cc>) {\n> \t...\n> \t}\n> close $cc;\n\nAdd --cc-cmd, the ability to execute an arbitrary \"cmd\" to\ngenerate per patch file specific \"Cc:\"s to git-send-email.perl\n\nSigned-off-by: Joe Perches \n\ndiff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt\nindex d243ed1..9a48847 100644\n--- a/Documentation/git-send-email.txt\n+++ b/Documentation/git-send-email.txt\n@@ -34,6 +34,12 @@ The --bcc option must be repeated for each user you want on the bcc list.\n +\n The --cc option must be repeated for each user you want on the cc list.\n \n+--cc-cmd::\n+\tSpecify a command to execute once per patch file which\n+\tshould generate patch file specific \"Cc:\" entries.\n+\tOutput of this command must be single email address per line.\n+\tDefault is the value of 'sendemail.cccmd' configuration value.\n+\t\n --chain-reply-to, --no-chain-reply-to::\n \tIf this is set, each email will be sent as a reply to the previous\n \temail sent. If disabled with \"--no-chain-reply-to\", all emails after\n@@ -124,6 +130,9 @@ sendemail.aliasfiletype::\n \tFormat of the file(s) specified in sendemail.aliasesfile. Must be\n \tone of 'mutt', 'mailrc', 'pine', or 'gnus'.\n \n+sendemail.cccmd::\n+\tCommand to execute to generate per patch file specific \"Cc:\"s.\n+\n sendemail.bcc::\n \tEmail address (or alias) to always bcc.\n \ndiff --git a/git-send-email.perl b/git-send-email.perl\nindex 69559b2..d49947c 100755\n--- a/git-send-email.perl\n+++ b/git-send-email.perl\n@@ -46,6 +46,9 @@ Options:\n --cc Specify an initial \"Cc:\" list for the entire series\n of emails.\n \n+ --cc-cmd Specify a command to execute per file which adds\n+ per file specific cc address entries\n+\n --bcc Specify a list of email addresses that should be Bcc:\n \t\t on all the emails.\n \n@@ -157,13 +160,14 @@ if ($@) {\n my ($quiet, $dry_run) = (0, 0);\n \n # Variables with corresponding config settings\n-my ($thread, $chain_reply_to, $suppress_from, $signed_off_cc);\n+my ($thread, $chain_reply_to, $suppress_from, $signed_off_cc, $cc_cmd);\n \n my %config_settings = (\n \"thread\" => [\\$thread, 1],\n \"chainreplyto\" => [\\$chain_reply_to, 1],\n \"suppressfrom\" => [\\$suppress_from, 0],\n \"signedoffcc\" => [\\$signed_off_cc, 1],\n+ \"cccmd\" => [\\$cc_cmd, \"\"],\n );\n \n foreach my $setting (keys %config_settings) {\n@@ -189,6 +193,7 @@ my $rc = GetOptions(\"sender|from=s\" => \\$sender,\n \t\t \"smtp-server=s\" => \\$smtp_server,\n \t\t \"compose\" => \\$compose,\n \t\t \"quiet\" => \\$quiet,\n+\t\t \"cc-cmd=s\" => \\$cc_cmd,\n \t\t \"suppress-from!\" => \\$suppress_from,\n \t\t \"signed-off-cc|signed-off-by-cc!\" => \\$signed_off_cc,\n \t\t \"dry-run\" => \\$dry_run,\n@@ -652,11 +657,25 @@ foreach my $t (@files) {\n \t\t}\n \t}\n \tclose F;\n+\n+\tif (${cc_cmd} ne \"\") {\n+\t open(F, \"${cc_cmd} $t |\")\n+\t\tor die \"(cc-cmd) Could not execute '${cc_cmd}'\\n\";\n+\t while() {\n+\t\tmy $c = $_;\n+\t\t$c =~ s/^\\s*//g;\n+\t\t$c =~ s/\\n$//g;\n+\t\tpush @cc, $c;\n+\t\tprintf(\"(cc-cmd) Adding cc: %s from: '%s'\\n\", $c, $cc_cmd)\n+\t\t unless $quiet;\n+\t }\n+\t close F;\n+\t}\n+\n \tif (defined $author) {\n \t\t$message = \"From: $author\\n\\n$message\";\n \t}\n \n-\n \tsend_message();\n \n \t# set up for the next message\n"}]}