From: Junio C Hamano <junkio@cox.net>
To: Jon Loeliger <jdl@freescale.com>
Cc: git@vger.kernel.org
Subject: Re: Now What?
Date: Thu, 03 Nov 2005 12:55:28 -0800 [thread overview]
Message-ID: <7vll05e9j3.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <E1EXTw5-00063o-Gt@jdl.com> (Jon Loeliger's message of "Wed, 02 Nov 2005 19:30:37 -0600")
Jon Loeliger <jdl@freescale.com> writes:
> Finally, a procedure or style question. Should this
> write-up be in the form of a structured FAQ? A stand-alone
> expository document?
Earlier I suggested bunch of unconnected Documentation/howto
pages, but I'd like to take it back at least partially. I have
two alternatives; I do not know which one I prefer more...
A table-of-contents (FAQ-list) with task-oriented categorization
would help guide the users facing "Now What?" situation. It
might start like this:
It broke after you tried to ...
* pull from remote
breakage #1 --> see this...
breakage #2 --> see that...
...
* checkout a branch
breakage #1 --> see this...
breakage #2 --> see that...
...
and each breakage and solution would be a separate document.
If we go with this separate FAQ-list approach, I'd love to keep
the result under Documentation/ hierarchy we ship as part of the
source, but I suspect that building-up this kind of thing might
be better suited to Wiki. I wonder if there is a Wiki whose
document storage format is in asciidoc, and uses git as its
revision control backend. Then we could let people update Wiki,
and occasionally merge from there. We also should be able to
push things back to Wiki, essentially treating Wiki as one of
the repositories from the git side. Hmm...
The other alternative is to add "NOW WHAT" section to each man
page. The idea is that "if the last command you ran was this
command and if it did not do what you wanted it to do, here are
its common failure modes and how you would recover from them".
So the materials we covered during the failed pull/merge
discussion would go to "NOW WHAT" section of git-pull(1), with
perhaps git-merge(1) saying "See also".
We would want "EXAMPLES" section for all the major commands as
suggested by Linus anyway, and going this way we _may_ be able
to get away without coming up with the higher level problem
categorization; the user would at least know what the last
command he tried to use was already.
next prev parent reply other threads:[~2005-11-03 20:55 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-03 1:30 Now What? Jon Loeliger
2005-11-03 1:43 ` Chris Shoemaker
2005-11-03 9:00 ` Junio C Hamano
2005-11-03 18:51 ` Jon Loeliger
2005-11-06 20:33 ` Junio C Hamano
2005-11-03 8:38 ` Peter Eriksen
2005-11-03 10:00 ` Junio C Hamano
2005-11-03 17:05 ` Daniel Barkalow
2005-11-03 17:27 ` Linus Torvalds
2005-11-03 18:38 ` Junio C Hamano
2005-11-03 17:30 ` Peter Eriksen
2005-11-03 22:07 ` Junio C Hamano
2005-11-03 22:33 ` Josef Weidendorfer
2005-11-04 17:06 ` Daniel Barkalow
2005-11-03 17:25 ` Linus Torvalds
2005-11-03 8:58 ` Junio C Hamano
2005-11-03 20:55 ` Junio C Hamano [this message]
2005-11-03 22:17 ` Josef Weidendorfer
2005-11-03 22:51 ` Junio C Hamano
2005-11-03 23:26 ` Josef Weidendorfer
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=7vll05e9j3.fsf@assigned-by-dhcp.cox.net \
--to=junkio@cox.net \
--cc=git@vger.kernel.org \
--cc=jdl@freescale.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.