Matthieu Moy writes:
> Nguyen Thai Ngoc Duy writes:
>
>> On Fri, Oct 05, 2012 at 01:03:28PM -0700, Junio C Hamano wrote:
>>
>>> OK, the messages are supposed to advise how to turn them off, so we
>>> would want some code updates in that case.
>>
>> Something like this? It turns out none of the a
On Thu, Oct 11, 2012 at 9:18 PM, Matthieu Moy
wrote:
> For example, it makes the output of git status look like:
>
> # On branch master
> # Changes to be committed:
> # (use "git reset HEAD ..." to unstage)
> # Set advice.statusHints to false to turn off this message
> #
> # modified:
Nguyen Thai Ngoc Duy writes:
> On Fri, Oct 05, 2012 at 01:03:28PM -0700, Junio C Hamano wrote:
>
>> OK, the messages are supposed to advise how to turn them off, so we
>> would want some code updates in that case.
>
> Something like this? It turns out none of the advice messages says
> anything a
On Fri, Oct 05, 2012 at 01:03:28PM -0700, Junio C Hamano wrote:
> >>> OK. I think I was surprised that some messages were controlled by
> >>> advice.* but gave no hints about that and I found that out by other
> >>> means. I'll check all the advice messages.
> >
> > It's about the commands, not the
Jeff King writes:
> On Wed, Oct 03, 2012 at 11:26:55AM -0700, Junio C Hamano wrote:
>
>> Please do not label the list as "These variables affect this
>> command" to give a false impression that it is the complete list if
>> it isn't.
>>
>> Unless somebody promises to keep an up-to-date complete
Junio C Hamano wrote:
> Ramkumar Ramachandra writes:
>
>> Junio C Hamano wrote:
>>>
>>> With a weaker phrase, e.g. "These configuration variables may be of
>>> interest", such a list may not hurt readers, but personally I do not
>>> think it adds much value to have a list of variables without even
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>>
>> With a weaker phrase, e.g. "These configuration variables may be of
>> interest", such a list may not hurt readers, but personally I do not
>> think it adds much value to have a list of variables without even a
>> single line description
Junio C Hamano wrote:
> Nguyen Thai Ngoc Duy writes:
>
>> On Wed, Oct 3, 2012 at 3:46 PM, Ramkumar Ramachandra
>> wrote:
>>> On second thought, it might not be such a good idea. There are *lots*
>>> of variables that control the operation of each command, and it's hard
>>> to decide which ones
Nguyen Thai Ngoc Duy writes:
> On Thu, Oct 4, 2012 at 12:45 PM, Junio C Hamano wrote:
>> Nguyen Thai Ngoc Duy writes:
>>
>>> On Thu, Oct 4, 2012 at 1:49 AM, Junio C Hamano wrote:
I would recommend against listing any advice.* in the command manual
pages. They are meant to give an ad
On Thu, Oct 4, 2012 at 12:45 PM, Junio C Hamano wrote:
> Nguyen Thai Ngoc Duy writes:
>
>> On Thu, Oct 4, 2012 at 1:49 AM, Junio C Hamano wrote:
>>> I would recommend against listing any advice.* in the command manual
>>> pages. They are meant to give an advice in cases that are often
>>> confu
Nguyen Thai Ngoc Duy writes:
> On Thu, Oct 4, 2012 at 1:49 AM, Junio C Hamano wrote:
>> I would recommend against listing any advice.* in the command manual
>> pages. They are meant to give an advice in cases that are often
>> confusing to new people and are supposed to advise how to turn it
>>
On Wed, Oct 03, 2012 at 11:26:55AM -0700, Junio C Hamano wrote:
> Please do not label the list as "These variables affect this
> command" to give a false impression that it is the complete list if
> it isn't.
>
> Unless somebody promises to keep an up-to-date complete list there
> (or even better
Nguyen Thai Ngoc Duy writes:
> On Wed, Oct 3, 2012 at 3:46 PM, Ramkumar Ramachandra
> wrote:
>> On second thought, it might not be such a good idea. There are *lots*
>> of variables that control the operation of each command, and it's hard
>> to decide which ones to list and which ones to omit
Nguyen Thai Ngoc Duy writes:
> On Wed, Oct 3, 2012 at 3:46 PM, Ramkumar Ramachandra
> wrote:
>> On second thought, it might not be such a good idea. There are *lots*
>> of variables that control the operation of each command, and it's hard
>> to decide which ones to list and which ones to omit
Nguyen Thai Ngoc Duy:
I'm just thinking whether it's a good idea to add a section in the
end of each command's man page to list all relevant config keys to
that command, somewhat similar to "see also" section.
Yes, please. Discoverability of configuration settings is not very
good at the mom
On Wed, Oct 3, 2012 at 3:46 PM, Ramkumar Ramachandra wrote:
> On second thought, it might not be such a good idea. There are *lots*
> of variables that control the operation of each command, and it's hard
> to decide which ones to list and which ones to omit. I've listed all
> the relevant varia
Junio C Hamano wrote:
> Ramkumar Ramachandra writes:
>> [...]
>> --8<--
>
> FYI: the above is not a scissors line.
Excerpt from git-mailinfo[1]:
--scissors::
Remove everything in body before a scissors line. A line that
mainly consists of scissors (either ">8" or "8<") and perfo
[+CC: Junio, for comments]
Nguyen Thai Ngoc Duy wrote:
> On Wed, Oct 3, 2012 at 3:17 PM, Ramkumar Ramachandra
> wrote:
>> Hi Duy,
>>
>> Nguyen Thai Ngoc Duy wrote:
>>> Your patch is fine. I'm just thinking whether it's a good idea to add
>>> a section in the end of each command's man page to lis
On Wed, Oct 3, 2012 at 3:17 PM, Ramkumar Ramachandra wrote:
> Hi Duy,
>
> Nguyen Thai Ngoc Duy wrote:
>> Your patch is fine. I'm just thinking whether it's a good idea to add
>> a section in the end of each command's man page to list all relevant
>> config keys to that command, somewhat similar to
On Tue, Oct 2, 2012 at 10:09 PM, Ramkumar Ramachandra
wrote:
> David Glasser wrote:
>> Is the newish push.default documented in the "git push" manpage
>> anywhere? I don't see it mentioned (and there are several references
>> to the "default" behavior), but maybe I'm missing something. Is it
>> le
Junio C Hamano writes:
> I'll queue this instead. Thanks.
Even better, perfect!
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.o
David Glasser writes:
> Thanks Junio! Note that I think the word is usually spelled
> "controlled" not "controled".
Thanks; I cannot spelll...
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vg
Thanks Junio! Note that I think the word is usually spelled
"controlled" not "controled".
On Tue, Oct 2, 2012 at 11:34 AM, Junio C Hamano wrote:
> Ramkumar Ramachandra writes:
>
>> David Glasser wrote:
>>> Thanks Rankumar! There's also the reference in the "git push origin"
>>> example and the "
Ramkumar Ramachandra writes:
> David Glasser wrote:
>> Thanks Rankumar! There's also the reference in the "git push origin"
>> example and the "This is the default operation mode if no explicit
>> refspec is found".
>
> Sorry; here's a revised patch.
>
> --8<--
FYI: the above is not a scissors
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> Ramkumar Ramachandra writes:
>>
>>> David Glasser wrote:
Thanks Rankumar! There's also the reference in the "git push origin"
example and the "This is the default operation mode if no explicit
refspec is found".
>>>
>>> Sorry; h
Matthieu Moy writes:
> Ramkumar Ramachandra writes:
>
>> David Glasser wrote:
>>> Thanks Rankumar! There's also the reference in the "git push origin"
>>> example and the "This is the default operation mode if no explicit
>>> refspec is found".
>>
>> Sorry; here's a revised patch.
>
> Sounds go
Matthieu Moy wrote:
> Ramkumar Ramachandra writes:
>
>> David Glasser wrote:
>>> Thanks Rankumar! There's also the reference in the "git push origin"
>>> example and the "This is the default operation mode if no explicit
>>> refspec is found".
>>
>> Sorry; here's a revised patch.
>
> Sounds good,
Ramkumar Ramachandra writes:
> David Glasser wrote:
>> Thanks Rankumar! There's also the reference in the "git push origin"
>> example and the "This is the default operation mode if no explicit
>> refspec is found".
>
> Sorry; here's a revised patch.
Sounds good, thanks (resend and Cc Junio if
Thanks Rankumar! There's also the reference in the "git push origin"
example and the "This is the default operation mode if no explicit
refspec is found".
(I would have sent my own patch but I can't figure out where the
syntax for the manpages is documented.)
--dave
On Tue, Oct 2, 2012 at 8:09 A
David Glasser wrote:
> Is the newish push.default documented in the "git push" manpage
> anywhere? I don't see it mentioned (and there are several references
> to the "default" behavior), but maybe I'm missing something. Is it
> left out on purpose (ie, config values aren't supposed to be mentioned
Is the newish push.default documented in the "git push" manpage
anywhere? I don't see it mentioned (and there are several references
to the "default" behavior), but maybe I'm missing something. Is it
left out on purpose (ie, config values aren't supposed to be mentioned
in command manpages)?
--dav
31 matches
Mail list logo
