Re: [PATCH] user-manual: mention git gui citool (commit, amend)

["Shawn O. Pearce" <spearce@spearce.org>]

"J. Bruce Fields" <bfields@fieldses.org> wrote:
> On Thu, Aug 02, 2007 at 11:04:59PM -0400, Shawn O. Pearce wrote:
> > Online help?  In git-gui?  :-)
> > 
> > We don't have an online help system yet.
> 
> Fair enough.
> 
> Though I'd like to keep the main body of the manual focused on the major
> command line tools, I'd have no objection to a separate chapter (or
> appendix?) devoted to git-gui; then you could point directly at that.
> Would that make sense?

Yea, that makes a lot of sense.  git-gui isn't a full replacement
for the command line anyway, so I would never suggest a wholesale
rewrite of the user manual to slant the entire thing towards git-gui.
Doing so would only point out the many shortcomings in git-gui.  :)

I haven't explored any in-Tk rendering options yet, been too busy
with other projects.  Ideally I'd like to just render the asciidoc
markup directly, but I don't think anyone has done an asciidoc
viewer for Tk.  I can't imagine it would be that difficult to get
some sort of parser working though...


But at this point in git (and git-gui's) life I think it would
be very worthwhile to devote an entire (new) chapter to git-gui,
maybe as part of git 1.5.4/git-gui 0.9.0.  I think we're far too
late in the 1.5.3 cycle to do it now.  I personally won't have the
time to even try to rough draft something anytime soon, let alone
let others copy-edit me before Juino releases 1.5.3.  :)

Being bundled with core git has brought git-gui a sizeable and
growing userbase, and more and more users are discovering it
each day.  We're now seeing it be translated into many different
languages, and it is a somewhat core part of the MSYS port as many
Windows users prefer to click in GUIs over type in cmd.exe terminal
windows (can't say I blame them, cmd.exe is aweful!).

In other words I think git-gui should get roughly as much attention
from the user manual as git-add/rm/mv/commit/checkout/branch get,
as it offers the same feature set.  But it shouldn't distract from
the command line part of the manual.

Maybe we should write parts of the manual in a "choose your own
adventure style" and use different chapters for different paths.
I think users can easily decide between the command line "i like to
type" vs. the gui "i like to click" paths and focus their attention
to the material they are most interested in.  :-)

-- 
Shawn.