{"thread":{"id":"41552","subject":"GSoC 2016 Microproject","startedAt":"2016-02-27T13:04:57Z","lastAt":"2016-03-01T12:22:28Z","messageCount":11,"participants":["Sidhant Sharma","Matthieu Moy","Thomas Gummerer"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"279640","messageId":"56D19EF9.3070702@gmail.com","threadId":"41552","inReplyTo":null,"subject":"GSoC 2016 Microproject","fromName":"Sidhant Sharma","fromEmail":"tigerkid001@gmail.com","sentAt":"2016-02-27T13:04:57Z","receivedAt":"2016-02-27T13:04:57Z","isPatch":false,"sender":{"key":"tigerkid001@gmail.com","avatar":"https://avatars.githubusercontent.com/u/7801881?v=4"},"body":"Hi everyone,\n\n\nI'm Sidhant Sharma. I'm looking to participate in GSoC 2016 (and contribute  \nto Git in general as well). I read up the pages relating to participation  \nin GSoC and selected the microproject \"Add configuration options for some  \ncommonly used command-line options\". I have some queries regarding this  \nthough:\n\n1. I believe the option can be added by a reassignment of the `verbose`  \nvariable in `parse_and_validate_options` function inside the  \n`builtin/commit.c`. It can be a logical OR between the `verbose` (which was  \nparsed by the argument parser) and the value obtained by using  \n`git_config_get_bool(\"command.verbose\", &opt_verbose)`. Am I thinking on  \nthe right lines?\n\n2. Should I also add an option to override the configuration for verbose?\n\n3. The microproject title suggests there can more such options, so are  \nthere more to be added?\n\n\nThanks in advance.\n\n\n\nRegards\n\nSidhant Sharma [:tk]\n"},{"id":"279641","messageId":"vpq8u26qo3y.fsf@anie.imag.fr","threadId":"41552","inReplyTo":"56D19EF9.3070702@gmail.com","subject":"Re: GSoC 2016 Microproject","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2016-02-27T13:28:17Z","receivedAt":"2016-02-27T13:28:17Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Sidhant Sharma <tigerkid001@gmail.com> writes:\n\n> Hi everyone,\n>\n>\n> I'm Sidhant Sharma. I'm looking to participate in GSoC 2016 (and contribute  \n> to Git in general as well). I read up the pages relating to participation  \n> in GSoC and selected the microproject \"Add configuration options for some  \n> commonly used command-line options\".\n\nThere's already work in progress on this project, see the mailing list\nthe last few days.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"279644","messageId":"56D1BEC8.9010302@gmail.com","threadId":"41552","inReplyTo":"vpq8u26qo3y.fsf@anie.imag.fr","subject":"Re: GSoC 2016 Microproject","fromName":"Sidhant Sharma","fromEmail":"tigerkid001@gmail.com","sentAt":"2016-02-27T15:20:40Z","receivedAt":"2016-02-27T15:20:40Z","isPatch":false,"sender":{"key":"tigerkid001@gmail.com","avatar":"https://avatars.githubusercontent.com/u/7801881?v=4"},"body":"\n> There's already work in progress on this project, see the mailing list\n> the last few days.\n>\n\nOkay, in that case, I'd like to try is the one titled \"Make upload-pack\nand receive-pack use the parse-options api\". In that, I can take up\nthe `builtin/receive-pack.c` file. Would that be okay?\n\n\nThanks again.\n\nRegards,\nSidhant Sharma [:tk]\n"},{"id":"279645","messageId":"vpq1t7yqgi4.fsf@anie.imag.fr","threadId":"41552","inReplyTo":"56D1BEC8.9010302@gmail.com","subject":"Re: GSoC 2016 Microproject","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2016-02-27T16:12:35Z","receivedAt":"2016-02-27T16:12:35Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Sidhant Sharma <tigerkid001@gmail.com> writes:\n\n>> There's already work in progress on this project, see the mailing list\n>> the last few days.\n>>\n>\n> Okay, in that case, I'd like to try is the one titled \"Make upload-pack\n> and receive-pack use the parse-options api\". In that, I can take up\n> the `builtin/receive-pack.c` file. Would that be okay?\n\nI didn't see anything going on for this one, but you may want to\ndouble-check with the ml's archives.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"279704","messageId":"56D2C828.6010901@gmail.com","threadId":"41552","inReplyTo":"vpq1t7yqgi4.fsf@anie.imag.fr","subject":"Re: GSoC 2016 Microproject","fromName":"Sidhant Sharma","fromEmail":"tigerkid001@gmail.com","sentAt":"2016-02-28T10:12:56Z","receivedAt":"2016-02-28T10:12:56Z","isPatch":false,"sender":{"key":"tigerkid001@gmail.com","avatar":"https://avatars.githubusercontent.com/u/7801881?v=4"},"body":"Hi,\n> I didn't see anything going on for this one, but you may want to\n> double-check with the ml's archives.\n>\nI checked the archives and there doesn't seem to be any active work on this.\nI made the required changes and ran the test suite. Though all the tests pass, there still are two queries I have.\nFirst, I'm not quite sure what to put in the help message for the options (--quiet, --stateless-rpc, --advertise-refs and --reject-thin-pack-for-testing).\nSecond, regarding the reject-thin-pack-for-testing option, currently when the option is entered, `fix_thin` is unset (https://github.com/git/git/blob/master/builtin/receive-pack.c#L1736). But using `OPT_BOOL(...)` for the same, the variable would instead be set when the option is given. I think one solution can be to invert `fix_thin` after calling `parse_options`. Am I going right so far? Suggestions and corrections welcome.\n\n\n\nRegards,\nSidhant Sharma [:tk]\n"},{"id":"279782","messageId":"56D45AFD.2060200@gmail.com","threadId":"41552","inReplyTo":"56D2C828.6010901@gmail.com","subject":"Re: GSoC 2016 Microproject","fromName":"Sidhant Sharma","fromEmail":"tigerkid001@gmail.com","sentAt":"2016-02-29T14:51:41Z","receivedAt":"2016-02-29T14:51:41Z","isPatch":false,"sender":{"key":"tigerkid001@gmail.com","avatar":"https://avatars.githubusercontent.com/u/7801881?v=4"},"body":"Hi,\nShould I make a patch for this and submit it for discussion on the mailing list?\n\n\nRegards,\nSidhant Sharma [:tk]\n"},{"id":"279783","messageId":"vpqpovfblru.fsf@anie.imag.fr","threadId":"41552","inReplyTo":"56D2C828.6010901@gmail.com","subject":"Re: GSoC 2016 Microproject","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2016-02-29T15:04:37Z","receivedAt":"2016-02-29T15:04:37Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Sidhant Sharma <tigerkid001@gmail.com> writes:\n\n> Hi,\n>> I didn't see anything going on for this one, but you may want to\n>> double-check with the ml's archives.\n>>\n> I checked the archives and there doesn't seem to be any active work on this.\n> I made the required changes and ran the test suite. Though all the\n> tests pass, there still are two queries I have.\n> First, I'm not quite sure what to put in the help message for the\n> options (--quiet, --stateless-rpc, --advertise-refs and\n> --reject-thin-pack-for-testing).\n\nThey are currently undocumented. We sometimes have explicitly\nundocumented options (PARSE_OPT_HIDDEN) when they are used only\ninternally to avoid polluting the end-user's UI.\n\nIn this case, the command is anyway not meant for end-users so I think\nit would make sense to document them, but not necessarily within the the\nmicroproject.\n\n> Second, regarding the reject-thin-pack-for-testing option, currently\n> when the option is entered, `fix_thin` is unset\n> (https://github.com/git/git/blob/master/builtin/receive-pack.c#L1736).\n> But using `OPT_BOOL(...)` for the same, the variable would instead be\n> set when the option is given. I think one solution can be to invert\n> `fix_thin` after calling `parse_options`. Am I going right so far?\n> Suggestions and corrections welcome.\n\nOr use OPT_SET_INT(..., 0) on a variable initialized to 1.\n\n> Should I make a patch for this and submit it for discussion on the mailing list?\n\nOn this list, it is indeed often more efficient to say \"here's what I'm\ndone. Any comments?\" than \"here's what I'm about to do\".\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"279786","messageId":"56D46493.4040909@gmail.com","threadId":"41552","inReplyTo":"vpqpovfblru.fsf@anie.imag.fr","subject":"Re: GSoC 2016 Microproject","fromName":"Sidhant Sharma","fromEmail":"tigerkid001@gmail.com","sentAt":"2016-02-29T15:32:35Z","receivedAt":"2016-02-29T15:32:35Z","isPatch":false,"sender":{"key":"tigerkid001@gmail.com","avatar":"https://avatars.githubusercontent.com/u/7801881?v=4"},"body":"\n>> First, I'm not quite sure what to put in the help message for the\n>> options (--quiet, --stateless-rpc, --advertise-refs and\n>> --reject-thin-pack-for-testing).\n> They are currently undocumented. We sometimes have explicitly\n> undocumented options (PARSE_OPT_HIDDEN) when they are used only\n> internally to avoid polluting the end-user's UI.\n>\n> In this case, the command is anyway not meant for end-users so I think\n> it would make sense to document them, but not necessarily within the the\n> microproject.\nSo what may I put in the message parameter? I was thinking\nperhaps the option itself, without hyphens. Would that be\ncorrect?\n>\n>> Second, regarding the reject-thin-pack-for-testing option, currently\n>> when the option is entered, `fix_thin` is unset\n>> (https://github.com/git/git/blob/master/builtin/receive-pack.c#L1736).\n>> But using `OPT_BOOL(...)` for the same, the variable would instead be\n>> set when the option is given. I think one solution can be to invert\n>> `fix_thin` after calling `parse_options`. Am I going right so far?\n>> Suggestions and corrections welcome.\n> Or use OPT_SET_INT(..., 0) on a variable initialized to 1.\nOkay, will do that.\n>> Should I make a patch for this and submit it for discussion on the mailing list?\n> On this list, it is indeed often more efficient to say \"here's what I'm\n> done. Any comments?\" than \"here's what I'm about to do\".\n>\nI'm really sorry, I'm not very familiar with mailing list etiquettes.\nI'll keep that in mind :)\n\n\n\nThanks and regards,\nSidhant Sharma [:tk]\n"},{"id":"279787","messageId":"vpqfuwbbjlx.fsf@anie.imag.fr","threadId":"41552","inReplyTo":"56D46493.4040909@gmail.com","subject":"Re: GSoC 2016 Microproject","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2016-02-29T15:51:22Z","receivedAt":"2016-02-29T15:51:22Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Sidhant Sharma <tigerkid001@gmail.com> writes:\n\n>>> First, I'm not quite sure what to put in the help message for the\n>>> options (--quiet, --stateless-rpc, --advertise-refs and\n>>> --reject-thin-pack-for-testing).\n>> They are currently undocumented. We sometimes have explicitly\n>> undocumented options (PARSE_OPT_HIDDEN) when they are used only\n>> internally to avoid polluting the end-user's UI.\n>>\n>> In this case, the command is anyway not meant for end-users so I think\n>> it would make sense to document them, but not necessarily within the the\n>> microproject.\n> So what may I put in the message parameter? I was thinking\n> perhaps the option itself, without hyphens. Would that be\n> correct?\n\nIf you use PARSE_OPT_HIDDEN, I think you don't need to specify a\nmessage. Otherwise, the documentation only has value if it contains more\nthan just the option name, but that is the hard part if you're not\nfamiliar with the code. The best place to find documentation is in the\nhistory (git blame the file and see if the commit message introducing\nthe option enlightens you). But that's why I said this didn't have to be\npart of the microproject: writting good doc requires a good\nunderstanding of the whole thing ...\n\n>>> Should I make a patch for this and submit it for discussion on the mailing list?\n>>\n>> On this list, it is indeed often more efficient to say \"here's what I'm\n>> done. Any comments?\" than \"here's what I'm about to do\".\n>>\n> I'm really sorry, I'm not very familiar with mailing list etiquettes.\n> I'll keep that in mind :)\n\nNo problem. It's OK to say what you do beforehand and to ask help. Just\ndon't be surprised when you don't get much feedback on message not\nstarting with [PATCH] ;-).\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"279950","messageId":"56D57F4E.7000402@gmail.com","threadId":"41552","inReplyTo":"vpqfuwbbjlx.fsf@anie.imag.fr","subject":"Re: GSoC 2016 Microproject","fromName":"Sidhant Sharma","fromEmail":"tigerkid001@gmail.com","sentAt":"2016-03-01T11:38:54Z","receivedAt":"2016-03-01T11:38:54Z","isPatch":false,"sender":{"key":"tigerkid001@gmail.com","avatar":"https://avatars.githubusercontent.com/u/7801881?v=4"},"body":"\n> If you use PARSE_OPT_HIDDEN, I think you don't need to specify a message. Otherwise, the documentation only has value if it contains more than just the option name, but that is the hard part if you're not familiar with the code. The best place to find documentation is in the history (git blame the file and see if the commit message introducing the option enlightens you). But that's why I said this didn't have to be part of the microproject: writting good doc requires a good understanding of the whole thing ... \nI used OPT_HIDDEN_BOOL for all except for reject-thin-pack-for-testing, where I used PARSE_OPT_HIDDEN. I ran the test locally and also on Travis, and the all tests passed. How do I proceed now?\n\n\n\nThanks and regards,\nSidhant Sharma [:tk]\n"},{"id":"279951","messageId":"20160301122228.GL1831@hank","threadId":"41552","inReplyTo":"56D57F4E.7000402@gmail.com","subject":"Re: GSoC 2016 Microproject","fromName":"Thomas Gummerer","fromEmail":"t.gummerer@gmail.com","sentAt":"2016-03-01T12:22:28Z","receivedAt":"2016-03-01T12:22:28Z","isPatch":false,"sender":{"key":"t.gummerer@gmail.com","avatar":"https://avatars.githubusercontent.com/u/191004?v=4"},"body":"On 03/01, Sidhant Sharma wrote:\n>\n> > If you use PARSE_OPT_HIDDEN, I think you don't need to specify a message. Otherwise, the documentation only has value if it contains more than just the option name, but that is the hard part if you're not familiar with the code. The best place to find documentation is in the history (git blame the file and see if the commit message introducing the option enlightens you). But that's why I said this didn't have to be part of the microproject: writting good doc requires a good understanding of the whole thing ...\n> I used OPT_HIDDEN_BOOL for all except for reject-thin-pack-for-testing, where I used PARSE_OPT_HIDDEN. I ran the test locally and also on Travis, and the all tests passed. How do I proceed now?\n\nNow you can send a patch to the mailing list.  See\nDocumentation/SubmittingPatches for more details.\n\nIt usually is helpful to send the patches to yourself first as well,\nand try to apply them using git am, to avoid mistakes in the patch\nsubmission.\n\n>\n> Thanks and regards,\n> Sidhant Sharma [:tk]\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n\n--\nThomas\n"}]}