All of lore.kernel.org
 help / color / mirror / Atom feed
From: "SZEDER Gábor" <szeder@ira.uka.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Christian Couder <chriscool@tuxfamily.org>,
	Michael J Gruber <git@drmicha.warpmail.net>,
	wharms@bfs.de
Subject: Re: help: bisect single file from repos
Date: Wed, 9 Dec 2009 02:28:55 +0100	[thread overview]
Message-ID: <20091209012855.GA3208@neumann> (raw)
In-Reply-To: <7vein5e2lc.fsf@alter.siamese.dyndns.org>

Hi,


On Tue, Dec 08, 2009 at 10:35:11AM -0800, Junio C Hamano wrote:
> But I wonder if there is
> something we _could_ have done better in the documentation area to avoid
> this from the beginning, iow, make it easier to "learn how things work
> before using"?  I think there is a lesson to be learned by us in here, and
> I'd like to hear comments and improvement suggestions, especially from
> "usability" and "friendly to new people" advocates.

when a git command accepts a commit as command line option, the
documentation usually refers to the "Specifying revisions" section of
'git rev-parse's docs for "a more complete list of ways to spell
commits"[1].  Even the docs of porcelain commands and the user manual
do that.  But 'git rev-parse' is plumbing, and we actively advertise
that avarage users don't really need to know about plumbing at all.
While new to git I repeatedly encountered this reference to 'git
rev-parse' all over the porcelain manpages, and it was a real burden
for me back then.  I was like "but I don't want to know about all the
glory details, just give me a short summary".

I think the user should not refer to plumbing manpages to be able to
use porcelain commands.  Therefore, the manpage of every command
accepting a commit option need to have a section about specifying
these commits.  This section doesn't need to be as detailed as 'git
rev-parse'; perhaps we don't need to discuss the ^{} notation there.
Also, the precedence in case of an ambiguous symbolic ref name should
be described without reference to the internal $GIT_DIR/refs/
directory structure.

Furthermore, some manpages use the term "<commit>", while others
"<committish>" or "<rev>".  The same term should be used everywhere.


Best,
Gábor


[1] - 'git cherry-pick' doc says the following:

  <commit>
    Commit to cherry-pick. For a more complete list of ways to spell
    commits, see the "SPECIFYING REVISIONS" section in git-rev-parse(1).

What?  "A _more_ complete list"!?  Well, it's not very hard to be more
complete than this, there is not a single way described here (;

  reply	other threads:[~2009-12-09  1:29 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-07 12:59 help: bisect single file from repos walter harms
2009-12-07 15:08 ` Michael J Gruber
2009-12-07 16:05   ` walter harms
2009-12-08  8:17     ` Christian Couder
2009-12-08 13:41       ` walter harms
2009-12-08 18:35         ` Junio C Hamano
2009-12-09  1:28           ` SZEDER Gábor [this message]
2009-12-09  8:27             ` Nanako Shiraishi
2009-12-09  9:45               ` SZEDER Gábor
2009-12-09 12:12                 ` walter harms

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=20091209012855.GA3208@neumann \
    --to=szeder@ira.uka.de \
    --cc=chriscool@tuxfamily.org \
    --cc=git@drmicha.warpmail.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=wharms@bfs.de \
    /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.