GSoC 2016 Microproject
Hi everyone,
I'm Sidhant Sharma. I'm looking to participate in GSoC 2016 (and contribute to Git in general as well). I read up the pages relating to participation in GSoC and selected the microproject "Add configuration options for some commonly used command-line options". I have some queries regarding this though:
1. I believe the option can be added by a reassignment of the verbose variable in parse_and_validate_options function inside the builtin/commit.c. It can be a logical OR between the verbose (which was parsed by the argument parser) and the value obtained by using git_config_get_bool("command.verbose", &opt_verbose). Am I thinking on the right lines?
2. Should I also add an option to override the configuration for verbose?
3. The microproject title suggests there can more such options, so are there more to be added?
Thanks in advance.
Regards
Sidhant Sharma [:tk]
Quoted 7 lines · Sidhant Sharma
Hi everyone,
I'm Sidhant Sharma. I'm looking to participate in GSoC 2016 (and contribute to Git in general as well). I read up the pages relating to participation in GSoC and selected the microproject "Add configuration options for some commonly used command-line options".
There's already work in progress on this project, see the mailing list the last few days.
Signature · 2 lines
Matthieu Moy http://www-verimag.imag.fr/~moy/
Quoted 4 lines
There's already work in progress on this project, see the mailing list the last few days.
Okay, in that case, I'd like to try is the one titled "Make upload-pack and receive-pack use the parse-options api". In that, I can take up the builtin/receive-pack.c file. Would that be okay?
Thanks again.
Regards,
Sidhant Sharma [:tk]
Quoted 7 lines · Sidhant Sharma
Quoted 3 lines
There's already work in progress on this project, see the mailing list the last few days.
Okay, in that case, I'd like to try is the one titled "Make upload-pack and receive-pack use the parse-options api". In that, I can take up the
builtin/receive-pack.cfile. Would that be okay?
I didn't see anything going on for this one, but you may want to double-check with the ml's archives.
Signature · 2 lines
Matthieu Moy http://www-verimag.imag.fr/~moy/
Hi,
Quoted 3 lines
I didn't see anything going on for this one, but you may want to double-check with the ml's archives.
I checked the archives and there doesn't seem to be any active work on this.
I made the required changes and ran the test suite. Though all the tests pass, there still are two queries I have.
First, 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).
Second, 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.
Regards,
Sidhant Sharma [:tk]
Hi,
Should I make a patch for this and submit it for discussion on the mailing list?
Regards,
Sidhant Sharma [:tk]
Quoted 10 lines · Sidhant Sharma
Hi,
Quoted 3 lines
I didn't see anything going on for this one, but you may want to double-check with the ml's archives.
I checked the archives and there doesn't seem to be any active work on this. I made the required changes and ran the test suite. Though all the tests pass, there still are two queries I have.
First, 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).
They are currently undocumented. We sometimes have explicitly undocumented options (PARSE_OPT_HIDDEN) when they are used only internally to avoid polluting the end-user's UI.
In this case, the command is anyway not meant for end-users so I think it would make sense to document them, but not necessarily within the the microproject.
Quoted 7 lines
Second, regarding the reject-thin-pack-for-testing option, currently when the option is entered,
fix_thinis unset
(https://github.com/git/git/blob/master/builtin/receive-pack.c#L1736).
But usingOPT_BOOL(...)for the same, the variable would instead be set when the option is given. I think one solution can be to invertfix_thinafter callingparse_options. Am I going right so far? Suggestions and corrections welcome.
Or use OPT_SET_INT(..., 0) on a variable initialized to 1.
Quoted 1 line
Should I make a patch for this and submit it for discussion on the mailing list?
On this list, it is indeed often more efficient to say "here's what I'm done. Any comments?" than "here's what I'm about to do".
Signature · 2 lines
Matthieu Moy http://www-verimag.imag.fr/~moy/
Quoted 11 lines
Quoted 4 lines
First, 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).
They are currently undocumented. We sometimes have explicitly undocumented options (
PARSE_OPT_HIDDEN) when they are used only internally to avoid polluting the end-user's UI.In this case, the command is anyway not meant for end-users so I think it would make sense to document them, but not necessarily within the the microproject.
So what may I put in the message parameter? I was thinking perhaps the option itself, without hyphens. Would that be correct?
Quoted 9 lines
Quoted 8 lines
Second, regarding the reject-thin-pack-for-testing option, currently when the option is entered,
fix_thinis unset
(https://github.com/git/git/blob/master/builtin/receive-pack.c#L1736).
But usingOPT_BOOL(...)for the same, the variable would instead be set when the option is given. I think one solution can be to invertfix_thinafter callingparse_options. Am I going right so far? Suggestions and corrections welcome.Or use
OPT_SET_INT(..., 0)on a variable initialized to 1.
Okay, will do that.
Quoted 4 lines
Quoted 1 line
Should I make a patch for this and submit it for discussion on the mailing list?
On this list, it is indeed often more efficient to say "here's what I'm done. Any comments?" than "here's what I'm about to do".
I'm really sorry, I'm not very familiar with mailing list etiquettes. I'll keep that in mind :)
Thanks and regards,
Sidhant Sharma [:tk]
Quoted 7 lines · Sidhant Sharma
Quoted 7 lines
Quoted 3 lines
First, 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).
They are currently undocumented. We sometimes have explicitly undocumented options (
PARSE_OPT_HIDDEN) when they are used only internally to avoid polluting the end-user's UI.
Quoted 6 lines
Quoted 3 lines
In this case, the command is anyway not meant for end-users so I think it would make sense to document them, but not necessarily within the the microproject.
So what may I put in the message parameter? I was thinking perhaps the option itself, without hyphens. Would that be correct?
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 ...
Quoted 7 lines
Quoted 5 lines
Quoted 1 line
Should I make a patch for this and submit it for discussion on the mailing list?
On this list, it is indeed often more efficient to say "here's what I'm done. Any comments?" than "here's what I'm about to do".
I'm really sorry, I'm not very familiar with mailing list etiquettes. I'll keep that in mind :)
No problem. It's OK to say what you do beforehand and to ask help. Just don't be surprised when you don't get much feedback on message not starting with [PATCH] ;-).
Signature · 2 lines
Matthieu Moy http://www-verimag.imag.fr/~moy/
Quoted 2 lines
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 ...
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?
Thanks and regards,
Sidhant Sharma [:tk]
Quoted 3 lines · Sidhant Sharma
Quoted 2 lines
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 ...I used
OPT_HIDDEN_BOOLfor all except for reject-thin-pack-for-testing, where I usedPARSE_OPT_HIDDEN. I ran the test locally and also on Travis, and the all tests passed. How do I proceed now?
Now you can send a patch to the mailing list. See Documentation/SubmittingPatches for more details.
It usually is helpful to send the patches to yourself first as well, and try to apply them using git am, to avoid mistakes in the patch submission.
Quoted 7 lines
Thanks and regards,
Sidhant Sharma [:tk]
--
To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Thomas