Re: GSoC 2016 Microproject

[Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>]

Sidhant Sharma <tigerkid001@gmail.com> writes:

>>> 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?

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 ...

>>> 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] ;-).

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/