git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christian Couder <chriscool@tuxfamily.org>
To: Jeff King <peff@peff.net>, Jakub Narebski <jnareb@gmail.com>
Cc: "J. Bruce Fields" <bfields@fieldses.org>, git@vger.kernel.org
Subject: Re: [PATCH 3/3] Documentation: convert tutorials to man pages
Date: Sat, 3 May 2008 06:04:31 +0200	[thread overview]
Message-ID: <200805030604.32123.chriscool@tuxfamily.org> (raw)
In-Reply-To: <20080502124900.GA2923@sigill.intra.peff.net>

Le vendredi 2 mai 2008, Jeff King a écrit :
> On Fri, May 02, 2008 at 11:55:10AM +0200, Jakub Narebski wrote:
> > On 5/2/08, Christian Couder <chriscool@tuxfamily.org> wrote:
> > > This patch renames the following documents and at the same time
> > > converts them to the man page format:
> > >
> > >  cvs-migration.txt -> gitcvs-migration.txt
> > >  everyday.txt      -> giteveryday.txt
> > >  tutorial.txt      -> gittutorial.txt
> > >  tutorial-2.txt    -> gittutorial-2.txt
> >
> > I like the rest of the series, but this I have serious doubts about. I
> > think that manpage format is just not suitable for guides and tutorials
> > (larger works), especially that we have HTML and beginnings of info
> > versions.
> >
> > Beside, the filenames looks stupid... githooks would go in a pinch, but
> > other names...
>
> I don't know about that:
>
>   $ man perlretut | wc -l
>   2348

Yeah:

$ man perlfunc | wc -l
6708
$ man bash | wc -l
4916
$ man git | wc -l
825
$ man gittutorial | wc -l
691
$ man gittutorial-2 | wc -l
472
$ man giteveryday | wc -l
478
$ man gitcvs-migration | wc -l
201

so the 4 tutorials are much shorter than some other man pages and even 
shorter than the git(7) man page.

> which is basically the same thing (funny name, and very long).

I would even say that the name is better and that the content is sometimes 
much shorter compared with perl man pages. 

> At least 
> for me, looking at a manpage is much more convenient than info or HTML.
> It's quick to load and easy to search through. Sure, the HTML will look
> a lot nicer. But it seems like if even a few people use the man version,
> the almost zero effort to generate them is worth it 

I agree. Sometimes the man pages are the only thing you can easily read.

> (though I would 
> argue that it should remain "tutorial.txt" and "tutorial.html", but
> generate "gittutorial.1").

I am open to suggestions for a better naming and for choosing man page 
sections, but I think we should be consistent as much as possible.

For example, the man page starts with:

NAME
       gittutorial - A tutorial introduction to git (for version 1.5.1 or
       newer)

If we keep "gittutorial" in the HTML format man page but we still name the 
file "tutorial.html", we are not very consistent.

And I think it will be some work to get links or references working in both 
the man format and HTML format man pages, especially if the naming is the 
same for some files (gitmodules, gitignore, git, gitk, git-log, ...) but 
not others (tutorial, everyday, ...)

About man page sections, Perl is consistent because every thing is in 
section 1. Now for git we already have git commands in section 1 and some 
other documentation (gitattributes, gitignore, gitmodules) in section 5 
and "git" in section 7. Do we want to keep "git" alone in section 7 and put 
tutorials in section 1 ? Or put everything in section 1 ?

Thanks,
Christian.

  parent reply	other threads:[~2008-05-03  4:00 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-02  3:30 [PATCH 3/3] Documentation: convert tutorials to man pages Christian Couder
2008-05-02  9:55 ` Jakub Narebski
2008-05-02 12:49   ` Jeff King
2008-05-02 14:31     ` J. Bruce Fields
2008-05-03  4:04     ` Christian Couder [this message]
2008-05-03 17:44       ` Junio C Hamano
2008-05-05  3:48         ` Documentation status (was Re: [PATCH 3/3] Documentation: convert tutorials to man pages) Christian Couder
2008-05-05  4:27           ` Documentation status Junio C Hamano
2008-05-05  7:34             ` Jakub Narebski
2008-05-06  3:11             ` Christian Couder

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200805030604.32123.chriscool@tuxfamily.org \
    --to=chriscool@tuxfamily.org \
    --cc=bfields@fieldses.org \
    --cc=git@vger.kernel.org \
    --cc=jnareb@gmail.com \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).