All of lore.kernel.org
 help / color / mirror / Atom feed
From: "SZEDER Gábor" <szeder@ira.uka.de>
To: Nanako Shiraishi <nanako3@lavabit.com>
Cc: Junio C Hamano <gitster@pobox.com>,
	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 10:45:32 +0100	[thread overview]
Message-ID: <20091209094532.GS18686@neumann> (raw)
In-Reply-To: <20091209172737.6117@nanako3.lavabit.com>

Hi,


On Wed, Dec 09, 2009 at 05:27:37PM +0900, Nanako Shiraishi wrote:
> Quoting SZEDER Gábor <szeder@ira.uka.de>
> 
> > [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 (;
> 

> I agree that "more" shouldn't be in that sentence, and I understand
> your hesitation to read plumbing manual pages, but I don't think it
> is a sane solution to the issue to repeat how to name a commit in
> manual pages for every single command to bloat the two line
> description you quoted into a half-page paragraph.  Even within that
> two lines, the real information that should be in the manual for
> cherry-pick is only three words "Commit to cherry-pick" and the rest
> is to help people who don't know.

I agree, that's why I proposed "a _section_ about specifying these
commits" in the more relevant part of my previous email you did not
quote.

The description of the "<commit>" option would remain almost the same,
but it will now refer to a dedicated section about specifying commits
below, but still in the same manpage.  This new dedicated section
would contain the list of three, five, N most common ways to specify a
commit, avoiding the bloatage in the options section.  And for those
who really want to dig deep, this dedicated section will refer to 'git
rev-parse' for the complete list.

And this would not be the first time we document something in many
places, think of '--pretty' and diff options, for example.


Best,
Gábor

  reply	other threads:[~2009-12-09  9:45 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
2009-12-09  8:27             ` Nanako Shiraishi
2009-12-09  9:45               ` SZEDER Gábor [this message]
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=20091209094532.GS18686@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=nanako3@lavabit.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.