Git development
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Philip Oakley" <philipoakley@iee.org>
Cc: "Git List" <git@vger.kernel.org>
Subject: Re: Improve 'git help' with basic user guide linkss
Date: Fri, 08 Feb 2013 12:53:30 -0800	[thread overview]
Message-ID: <7vr4kqzfw5.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <6D91D31A093D46869F43DD8D1012F0FB@PhilipOakley> (Philip Oakley's message of "Fri, 8 Feb 2013 20:28:39 -0000")

"Philip Oakley" <philipoakley@iee.org> writes:

> I'm looking at extending the 'git help' to include some information
> for the basic user who isn't ready for the extensive man page
> documentation for the various commands.

We have pointers at the beginning of "git(1)" for that exact reason.
I am not saying the documents pointed at from there are perfect, but
shouldn't that approach work?

> My real question is on the right approach to generating a list of
> guides and including them into the git help options. I'm planning on
> extending the command-list.txt file to include 'guides' and then
> extending the generate-cmdlist.sh to generate a guides array in
> common-cmds.h.

Having a catalog of guide documents in help.o sounds like a good way
to go, but I doubt "command-list" is a good place to store it.  It
is about git subcommands, "git help -a" uses it to show the list of
them, and the bash completion support uses the list via "git help -a".

The common-cmds.h does not have to be the only avenue to add your
catalog of guide documents to help.o. As a part of the build
procedure, you can list Documentation/guides/ and generate an array
definition into "guides.h", and add #include "guides.h" in help.c,
for example.

> I'm thinking of adding -g --guides and -c --commands options to
> complement the existing -a --all (becomes both commands and guides)

Complement is fine.  Contaminating -a with guides is probably not.

> I was expecting to update the user-manual. to become
> gituser-manual.txt so that the existing 'git help user-manual' scheme
> would discover it. The Tutorial and the User manual obviously(?) being
> the first port of call for the confused user.

Again, we do have pointer to tutorial fairly prominently at the
beginning of "git(1)".  Perhaps we want index.html that redirects to
git.html or something?

  reply	other threads:[~2013-02-08 20:53 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-08 20:28 Improve 'git help' with basic user guide linkss Philip Oakley
2013-02-08 20:53 ` Junio C Hamano [this message]
2013-02-08 21:43   ` Philip Oakley
2013-02-08 22:54     ` Junio C Hamano
2013-02-08 23:16       ` Philip Oakley
2013-02-12 11:11         ` Philip Oakley
2013-02-12 11:37           ` John Keeping
2013-02-12 12:00             ` Philip Oakley

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=7vr4kqzfw5.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=philipoakley@iee.org \
    /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