Git development
 help / color / mirror / Atom feed
From: "Philip Oakley" <philipoakley@iee.org>
To: "Git List" <git@vger.kernel.org>
Subject: Improve 'git help' with basic user guide linkss
Date: Fri, 8 Feb 2013 20:28:39 -0000	[thread overview]
Message-ID: <6D91D31A093D46869F43DD8D1012F0FB@PhilipOakley> (raw)

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.

If the user doesn't yet know which is the relevant command then they 
should also be offered a clue on how to finding the various guides. Many 
users are stuck on the 'If I were you I wouldn't start from here' step 
(many blog comments on the alleged poor documentation and difficulty of 
understanding ...).

I've started on adding a few tweaks to the basic 'git help' message, 
adding an end line indicating that there are guides, such as 'tutorial'. 
Initial hacks at https://github.com/PhilipOakley/git/commits/morehelp 
for thos interested.

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.

I'm thinking of adding -g --guides and -c --commands options to 
complement the existing -a --all (becomes both commands and guides) 
option. I'm not yet sure how to determine which other special guides 
should be listed (api- etc.) and when.

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.

Does this appear sensible, and should the Documentation/* directories 
also be searched for 'guides', or is that a step too far [and it's less 
coding] ?

Philip Oakley

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

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-08 20:28 Philip Oakley [this message]
2013-02-08 20:53 ` Improve 'git help' with basic user guide linkss Junio C Hamano
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=6D91D31A093D46869F43DD8D1012F0FB@PhilipOakley \
    --to=philipoakley@iee.org \
    --cc=git@vger.kernel.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