git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: help: bisect single file from repos

From
SZEDER Gábor <szeder@ira.uka.de>
Date
Dec 9, 2009, 01:28 UTC
Message-ID
<20091209012855.GA3208@neumann>
In-Reply-To
<7vein5e2lc.fsf@alter.siamese.dyndns.org>
Hi,
On Tue, Dec 08, 2009 at 10:35:11AM -0800, Junio C Hamano wrote:
Show 6 quoted lines
> 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 (;

Previous: Junio C HamanoNext: Nanako Shiraishi
Message 7 of 10 in “help: bisect single file from repos”
  1. walter harmsDec 7, 2009
  2. Michael J GruberDec 7, 2009
  3. walter harmsDec 7, 2009
  4. Christian CouderDec 8, 2009
  5. walter harmsDec 8, 2009
  6. Junio C HamanoDec 8, 2009
  7. SZEDER GáborDec 9, 2009
  8. Nanako ShiraishiDec 9, 2009
  9. SZEDER GáborDec 9, 2009
  10. walter harmsDec 9, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.