Documentation/git-fsck.txt: include fsck.* config variables
diff mbox series

Message ID 20190729095914.30573-1-szeder.dev@gmail.com
State New
Headers show
Series
  • Documentation/git-fsck.txt: include fsck.* config variables
Related show

Commit Message

SZEDER Gábor July 29, 2019, 9:59 a.m. UTC
The 'fsck.skipList' and 'fsck.<msg-id>' config variables might be
easier to discover when they are documented in 'git fsck's man page.

Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
---
 Documentation/git-fsck.txt | 5 +++++
 1 file changed, 5 insertions(+)

Comments

Ævar Arnfjörð Bjarmason July 29, 2019, 3:33 p.m. UTC | #1
On Mon, Jul 29 2019, SZEDER Gábor wrote:

> The 'fsck.skipList' and 'fsck.<msg-id>' config variables might be
> easier to discover when they are documented in 'git fsck's man page.
>
> Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
> ---
>  Documentation/git-fsck.txt | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/git-fsck.txt b/Documentation/git-fsck.txt
> index e0eae642c1..d72d15be5b 100644
> --- a/Documentation/git-fsck.txt
> +++ b/Documentation/git-fsck.txt
> @@ -104,6 +104,11 @@ care about this output and want to speed it up further.
>  	progress status even if the standard error stream is not
>  	directed to a terminal.
>
> +CONFIGURATION
> +-------------
> +
> +include::config/fsck.txt[]

Before this include let's add:

    The below documentation is the same as what’s found in
    git-config(1):

As I did for a similar change in git-gc in b6a8d09f6d ("gc docs: include
the "gc.*" section from "config" in "gc"", 2019-04-07). Sometimes we
repeat ourselves, it helps the reader to know this isn't some slightly
different prose than what's in git-config.

> +
>  DISCUSSION
>  ----------
Junio C Hamano July 29, 2019, 3:48 p.m. UTC | #2
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> On Mon, Jul 29 2019, SZEDER Gábor wrote:
>
>> The 'fsck.skipList' and 'fsck.<msg-id>' config variables might be
>> easier to discover when they are documented in 'git fsck's man page.
>>
>> Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
>> ---
>>  Documentation/git-fsck.txt | 5 +++++
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/Documentation/git-fsck.txt b/Documentation/git-fsck.txt
>> index e0eae642c1..d72d15be5b 100644
>> --- a/Documentation/git-fsck.txt
>> +++ b/Documentation/git-fsck.txt
>> @@ -104,6 +104,11 @@ care about this output and want to speed it up further.
>>  	progress status even if the standard error stream is not
>>  	directed to a terminal.
>>
>> +CONFIGURATION
>> +-------------
>> +
>> +include::config/fsck.txt[]
>
> Before this include let's add:
>
>     The below documentation is the same as what’s found in
>     git-config(1):

I actually do not think we would want to do that.  I am all for the
kind of 'include' proposed by this patch, and we should strive to
make it easier for us to make sure the duplicated text are in sync.

But that would mean that the readers will have to see the "is the
same as the other one" over and over.  If our documentation set is
consistent, they should not have to.

I think we *must* make such a note in a total opposite case,
i.e. "here are the summary of the most often used options; for full
list, see git-config(1)".

> As I did for a similar change in git-gc in b6a8d09f6d ("gc docs: include
> the "gc.*" section from "config" in "gc"", 2019-04-07). Sometimes we
> repeat ourselves, it helps the reader to know this isn't some slightly
> different prose than what's in git-config.

So, I think we should revert that part out of b6a8d09f6d, too.
Jeff King July 29, 2019, 8:12 p.m. UTC | #3
On Mon, Jul 29, 2019 at 08:48:28AM -0700, Junio C Hamano wrote:

> > Before this include let's add:
> >
> >     The below documentation is the same as what’s found in
> >     git-config(1):
> 
> I actually do not think we would want to do that.  I am all for the
> kind of 'include' proposed by this patch, and we should strive to
> make it easier for us to make sure the duplicated text are in sync.
> 
> But that would mean that the readers will have to see the "is the
> same as the other one" over and over.  If our documentation set is
> consistent, they should not have to.
> 
> I think we *must* make such a note in a total opposite case,
> i.e. "here are the summary of the most often used options; for full
> list, see git-config(1)".

I disagree. _We_ know that the content is the same, because we are
looking at the source that says "include". But as a user, how do I know
when I get to one section or the other that it is something I have
already read and can skip over?

Perhaps if Git were entirely consistent here, they could make the
assumption that "CONFIG" sections were always duplicated and know this
already.  But I think even that is asking a bit much. Unless they are
intimately familiar with our documentation, they don't know that we are,
in fact, consistent. And we are in an uphill battle with every other
thing the user has read, which may not agree with our assumptions of
consistency. ;)

So IMHO it's worth leaving a note that guides the reader, as long as
it's short (and I think this one is).


That said, I think an even _better_ solution would be to avoid includes,
and instead make it clear when we are pointing the user to shared
content. Then we get them to the right place _and_ explicitly instruct
them that concepts/content are shared. For config, for example, I've
worked with a previous system that did something like:

  - include fsck.* documentation in the git-fsck manpage

  - make a master table of config options in git-config.1 with _just_
    the names and the associated manpage where the definition can be
    found. This serves as an index if you don't know where to look.

This would probably involve creating new concept-based pages for some of
the groupings (e.g., where does "remote.*" config go?), but I think that
would probably help round out our documentation (if there is a concept
with related config options but we don't explain it anywhere, that is
probably a gap we should fix).

The biggest downside is that chasing down references in manpages sucks.
For the HTML documentation we'd ideally hyperlink from the git-config.1
index into each definition, but there's no way to do that with a regular
manpage.

-Peff

PS This is an approach I've advocated for a while:

    https://public-inbox.org/git/20110120233429.GB9442@sigill.intra.peff.net/

   but haven't actually done much about, so perhaps I should be putting
   my money where my mouth is. ;)
Junio C Hamano July 29, 2019, 9:32 p.m. UTC | #4
Jeff King <peff@peff.net> writes:

> On Mon, Jul 29, 2019 at 08:48:28AM -0700, Junio C Hamano wrote:
>
>> > Before this include let's add:
>> >
>> >     The below documentation is the same as what’s found in
>> >     git-config(1):
>> 
>> I actually do not think we would want to do that.  I am all for the
>> kind of 'include' proposed by this patch, and we should strive to
>> make it easier for us to make sure the duplicated text are in sync.
>> 
>> But that would mean that the readers will have to see the "is the
>> same as the other one" over and over.  If our documentation set is
>> consistent, they should not have to.
>> 
>> I think we *must* make such a note in a total opposite case,
>> i.e. "here are the summary of the most often used options; for full
>> list, see git-config(1)".
>
> I disagree. _We_ know that the content is the same, because we are
> looking at the source that says "include". But as a user, how do I know
> when I get to one section or the other that it is something I have
> already read and can skip over?

I want to raise the user expectation so that they would expect from
our documentation, unless we say "these are different", we would
never say conflicting things in two places.

So,... I disagree.

Patch
diff mbox series

diff --git a/Documentation/git-fsck.txt b/Documentation/git-fsck.txt
index e0eae642c1..d72d15be5b 100644
--- a/Documentation/git-fsck.txt
+++ b/Documentation/git-fsck.txt
@@ -104,6 +104,11 @@  care about this output and want to speed it up further.
 	progress status even if the standard error stream is not
 	directed to a terminal.
 
+CONFIGURATION
+-------------
+
+include::config/fsck.txt[]
+
 DISCUSSION
 ----------