From: Christian Couder <chriscool@tuxfamily.org>
To: "Elijah Newren" <newren@gmail.com>
Cc: git@vger.kernel.org, "Havoc Pennington" <hp@pobox.com>,
"Carl Worth" <cworth@cworth.org>
Subject: Re: EasyGit [Was: Re: my git problem]
Date: Sun, 4 May 2008 12:00:45 +0200 [thread overview]
Message-ID: <200805041200.46099.chriscool@tuxfamily.org> (raw)
In-Reply-To: <51419b2c0805020454p144698e4l843e8edab00ddeb7@mail.gmail.com>
Le vendredi 2 mai 2008, Elijah Newren a écrit :
>
> EasyGit (eg) is a single-file script/porcelain that looks and feels like
> core git. In contrast to other simple-to-use porcelains, eg has all the
> same capabilities as git (in particular, it does not remove the index)
> and uses the same general syntax as core git. Eg primarily reduces the
> learning curve associated with git and prevents common user errors.
>
> Changes:
> Most of the changes in eg relative to git boil down to:
> - plugging a large gap in git documentation (namely, providing a
> tutorial-oriented built-in help system)
I had a look at it. And I have a few comments that I prefixed with '#'
below.
$ eg help
[...]
Time saving commands
eg bisect Find the change that introduced a bug by binary search
[...]
# What did they do to my beloved bisect? I need to have a look.
$ eg help bisect
Sorry, bisect is not overridden or modified for eg, and no
help has been written for it. If you're feeling brave, you may
want to try running 'git help bisect'.
# So they did nothing to it. Good ;-)
# But then why don't they ask people to use "git bisect" directly instead
# of "eg bisect" ?
#
# And they point to "git help bisect", good point.
# No need to "feel brave" to look at "git help bisect" though, because I
# think it is quite good. But I guess this is a generic message aimed at
# other commands.
$ eg help clone
[...]
See also
Run 'man git-clone' for a comprehensive list of options available.
eg clone is designed to accept the same options as git clone, and
with the same meanings unless specified otherwise in the above
"Differences" section.
# The output is longer than my terminal's 41 lines so I don't see its top
# because there is no paging.
# And why ask people to use "man git-clone" here, instead of "git help
# clone" ?
$ git clone -h
[...]
# "git clone -h" show more options in 18 lines only, but no examples
# and no description.
#
# I am not sure that the "Differences from git clone" part from "eg help
# clone" is really usefull for beginners.
$ eg changes --details
[...]
# Very long output but it's paged.
$ eg help help
[...]
Differences from git help:
eg help uses its own help system, ignoring the one from git help...except
that eg help will call git help if asked for help on a subcommand it does
not recognize.
"git help COMMAND" simply calls "man git-COMMAND". The git man pages are
really nice for people who are experts with git; they are comprehensive
and detailed.
# It's not true that "eg help will call git help if asked for help on a
# subcommand it does not recognize", it only display the same message as
# for "eg help bisect" above.
#
# Also it's not exactly true that '"git help COMMAND" simply calls "man
# git-COMMAND". If you use "git help -w COMMAND" or if you have
# the "help.format" set to "web", you get a HTML man page opened in a new
# tab in firefox (or something like that).
#
# And why not pointing to "git COMMAND -h" too, as it should give a "long
# usage" string that is often usefull and easier to use as the man page ?
[...]
>
> I would like to see the parts of eg that the community likes
> incorporated into git core. I do not know which changes would be
> wanted or welcome, and it may turn out that some of my changes show
> ignorance of certain aspects of git (some such cases have previously been
> uncovered already...and fixed). But the discussion can't hurt, and a
> number of the solutions I used in eg I have not found in searches of
> previous discussions in the archives.
What I like about the built-in help system in eg is that there are lots of
examples displayed. I think the git man pages are somewhat lacking in this
area. (Some examples are still using the "git-COMMAND" syntax for example.)
The built-in help text in eg also seems simpler and easier to understand,
but it may be because there are fewer options and simpler commands to
explain.
So here are some things that could be done to improve git help system:
- find a way to make users know that they can get long usage help using "git
COMMAND -h"
- find a way to display some examples on the command line without the full
man page
- add and improve examples in man pages
- add some simpler explanations to man pages and perhaps move more complex
explanations to a "DETAILED DESCRIPTION" part of the man page
- improve man pages in other ways
Thanks,
Christian.
next prev parent reply other threads:[~2008-05-04 9:56 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-02 11:41 EasyGit [Was: Re: my git problem] Elijah Newren
2008-05-02 11:54 ` Elijah Newren
2008-05-04 10:00 ` Christian Couder [this message]
2008-06-30 16:23 ` Sean Kelley
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=200805041200.46099.chriscool@tuxfamily.org \
--to=chriscool@tuxfamily.org \
--cc=cworth@cworth.org \
--cc=git@vger.kernel.org \
--cc=hp@pobox.com \
--cc=newren@gmail.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 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).