From: Scott Chacon <schacon@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git list <git@vger.kernel.org>
Subject: Re: [PATCH v2] Group the default git help message by topic
Date: Mon, 14 Jun 2010 08:31:55 -0700 [thread overview]
Message-ID: <AANLkTimFUGkYeZaXA7BqX8ghsHX_gGYRK69ScHMXbw2l@mail.gmail.com> (raw)
In-Reply-To: <7vbpbeazy5.fsf@alter.siamese.dyndns.org>
Hey,
On Sun, Jun 13, 2010 at 11:30 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> I am lazy, and I loathe having to maintain another hardcoded table (let
> alone sequence of print_command() calls, like this patch does, yuck).
>
Sorry, but it seemed to me this would have to be separately maintained
anyhow, plus it doesn't change much. How often are basic commands
going to be added or removed? Also, it may not be that pretty, but
it's undeniably clear.
> The two words, "21" and "group", in your proposed commit log message have
> been nagging me for a while, and I finally figured out why this patch made
> me feel very disturbed. We already have a perfect source to generate the
> necessary most commonly used command list with a good grouping hint, but
> the patch does not make use of it.
The only issue I would have with this statement is the word 'perfect'.
To disambiguate what we're talking about here, this is the output that
is generated from this new patch:
Some commonly used git commands per developer roles are:
* Individual Developer (Standalone)
init Create an empty git repository or reinitialize an existing one
show-branch Show branches and their commits
log Show commit logs
checkout Checkout a branch or paths to the working tree
add Add file contents to the index
diff Show changes between commits, commit and working tree, etc
commit Record changes to the repository
reset Reset current HEAD to the specified state
merge Join two or more development histories together
rebase Forward-port local commits to the updated upstream head
tag Create, list, delete or verify a tag object signed with GPG
* Individual Developer (Participant)
clone Clone a repository into a new directory
pull Fetch from and merge with another repository or a local branch
push Update remote refs along with associated objects
format-patch Prepare patches for e-mail submission
* Integrator
am Apply a series of patches from a mailbox
revert Revert an existing commit
* Repository Administration
daemon A really simple server for git repositories
shell Restricted login shell for GIT-only SSH access
Though the implementation of the solution is undeniably more elegant,
I have some serious issues with the output. As you mention next,
'show-branches' is second in the list, which is an issue, but there
are several more. 'am', 'revert', 'daemon', 'shell', 'rebase' - none
of these are appropriate for someone running 'git' and trying to see
where to start. If we put those aside, all we have is a big list of
commands again which adds almost no value to what we had before.
> If readers notice that there are some commands that are out of fashion
> (e.g. I don't think many people use show-branch anymore in the presence of
> "log --oneline --graph" and friends) listed in the "git help" output, that
> is a _good thing_. It will give us an incentive to keep the Everyday
> document up to date, and with the effort spent for that, "git help" will
> automatically be kept up to date as well for free ;-)
That's a fine goal, but I feel like it shouldn't be an "everyday"
document that generates that output, it should be a "beginner"
document or a "how to start using Git" document that isn't really in
the Git source. I mean, I suppose we could write one with the goal of
using it to generate the help output, but given how much people
disagreed with even the basic grouping of the first patch I sent, I
can't see how we're going to agree on a new help doc. Perhaps we
should decide on what we would ultimately like the basic help output
to look like and then I can craft a document that would produce it
given this patch and then the list can rip it apart until it's
basically acceptable.
Thoughts?
Scott
next prev parent reply other threads:[~2010-06-14 15:32 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-11 16:03 [PATCH v2] Group the default git help message by topic Scott Chacon
2010-06-11 16:26 ` Wincent Colaiuta
2010-06-11 22:00 ` A Large Angry SCM
2010-06-11 22:28 ` Ævar Arnfjörð Bjarmason
2010-06-12 16:19 ` Scott Chacon
2010-06-12 16:35 ` Ævar Arnfjörð Bjarmason
2010-06-12 18:44 ` A Large Angry SCM
2010-06-12 16:17 ` Scott Chacon
2010-06-12 17:53 ` Wincent Colaiuta
2010-06-11 16:46 ` Ævar Arnfjörð Bjarmason
2010-06-14 6:30 ` Junio C Hamano
2010-06-14 15:31 ` Scott Chacon [this message]
2010-06-14 16:49 ` Tay Ray Chuan
2010-06-14 16:59 ` Scott Chacon
2010-06-14 17:24 ` Junio C Hamano
2010-06-14 7:48 ` Matthieu Moy
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=AANLkTimFUGkYeZaXA7BqX8ghsHX_gGYRK69ScHMXbw2l@mail.gmail.com \
--to=schacon@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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).