From: David Greaves <david@dgreaves.com>
To: Petr Baudis <pasky@ucw.cz>
Cc: Steven Cole <elenstev@mesatop.com>, git@vger.kernel.org
Subject: Re: [RFC] Another way to provide help details. (was Re: [PATCH] Add help details to git help command.)
Date: Tue, 19 Apr 2005 15:41:34 +0100 [thread overview]
Message-ID: <4265189E.6090801@dgreaves.com> (raw)
In-Reply-To: <20050419015124.GW5554@pasky.ji.cz>
Petr Baudis wrote:
> Dear diary, on Tue, Apr 19, 2005 at 03:40:54AM CEST, I got a letter
> where Steven Cole <elenstev@mesatop.com> told me that...
>
>>Here is perhaps a better way to provide detailed help for each
>>git command. A command.help file for each command can be
>>written in the style of a man page.
>
>
> I don't like it. I think the 'help' command should serve primarily as a
> quick reference, which does not blend so well with a manual page - it's
> too long and too convoluted by repeated output.
>
> I'd just print the top comment from each file. :-)
>
On the other hand, having more complete docs seems like an excellent
idea (and other threads support that)
I'd certainly like to see more specification oriented documentation...
(even if it turns out to be disposable)
Steven, if you carry on sending more verbose docs I'll certainly read
and work with you on editing them...
Nb kernel-doc doesn't seem appropriate for user level docs.
maybe, whilst there's so much flux, have:
git man command
that just outputs text
If Petr wants the top comment to be extracted by help then maybe a
bottom comment block could contain the more complete text?
I *really* think that the user docs should live in the source for now
(hence I think that git man is better than going straight to man/docbook).
I wasn't sure whether to perlise the code or do a shell-lib - but
looking at the algorithms needed in things like git status I reckon the
shell will end up becoming a hackish mess of awk/sed/tr/sort/uniq/pipe
(ie perl) anyway.
So I'm going to have a go at that - Petr, if you have a minute could you
send me, off list, a bit of perl code that epitomises the style you like?
David
next prev parent reply other threads:[~2005-04-19 14:40 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-18 4:42 [PATCH] Add help details to git help command Steven Cole
2005-04-18 10:24 ` Petr Baudis
2005-04-18 16:59 ` Steven Cole
2005-04-19 1:40 ` [RFC] Another way to provide help details. (was Re: [PATCH] Add help details to git help command.) Steven Cole
2005-04-19 1:51 ` Petr Baudis
2005-04-19 14:41 ` David Greaves [this message]
2005-04-19 16:03 ` Steven Cole
2005-04-19 17:32 ` Petr Baudis
2005-04-19 17:35 ` [PATCH] Add help details to git help command. (This time with Perl) Steven Cole
2005-04-19 17:50 ` Petr Baudis
2005-04-19 19:04 ` David Greaves
2005-04-19 20:34 ` Steven Cole
2005-04-19 20:45 ` David Greaves
2005-04-20 23:34 ` Petr Baudis
2005-04-21 9:29 ` David Greaves
2005-04-23 23:41 ` Petr Baudis
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=4265189E.6090801@dgreaves.com \
--to=david@dgreaves.com \
--cc=elenstev@mesatop.com \
--cc=git@vger.kernel.org \
--cc=pasky@ucw.cz \
/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).