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

Re: [PATCH] Documentation/git-add.txt: Explain --patch option in layman terms

From
Jari Aalto <jari.aalto@cante.net>
Date
Aug 30, 2009, 23:06 UTC
Message-ID
<87ab1gaol2.fsf@jondo.cante.net>
In-Reply-To
<7vskf954sr.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Sections that are common in all manual pages (e.g. NAME, SYNOPSIS,
> DESCRIPTION, EXAMPLES, SEE ALSO) are often spelled in and referred to in
> caps. 

Not just common ones. All sections that are top level heading are best spelled out consistently. Examples can be found from the URL to POSIX/Susv in my other post.

[I'll get back to the CAPS patch in anaother post if we can sort this out]
> See http://www.kernel.org/pub/software/scm/git/docs/git-add.html#_interactive_mode
> for what I mean.

I think the convention used in git's manual pages deviate from the standard practise. We could make the git manual pages into line of:

- write all the first level headings in all caps: "HEADING LIKE THIS"
- write second level heading: start Upper-lower: "Heading like this"
Cf. rsync(1), ssh(1) etc. many pages prior git's existense.
Show 15 quoted lines
>>> I personally think fixing misworded phrase "initial command loop" would be
>>> sufficient.  It should read "initial command menu".  Perhaps like this.
>>>
>>> 	Run ``add --interactive``, but bypass the initial command menu and
>>> 	directly jump to `patch` subcommand.  See ``Interactive mode'' for
>>> 	details.
>>
>> It's still too technical. The 1st line should go right into business:
>>
>>  	Patch each file on command line interactively. This is this is
>>  	the same as ``add --interactive``, but bypass the initial
>>  	command menu and directly jump to `patch` subcommand. See
>>  	``Interactive mode'' for details.
>
> I do not think it is better than the original.
Your proposal that starts:
    ...but bypass the initial command menu
Mine:
    Patch each file on command line interactively

The first line should somehow strike immediately what the command does. I would like to see a suggestion that has 'patch(ing)' somewhere at the very first row. I hope we can find compromise.

Jari
Previous: Junio C HamanoNext: Junio C Hamano
Message 6 of 21 in “Documentation/git-add.txt: Explain --patch option in layman terms”
  1. Documentation/git-add.txt: Explain --patch option in layman termsJari Aalto, Aug 30, 2009
  2. Junio C HamanoAug 30, 2009
  3. Jeff KingAug 30, 2009
  4. Jari AaltoAug 30, 2009
  5. Junio C HamanoAug 30, 2009
  6. Jari AaltoAug 30, 2009
  7. Junio C HamanoAug 30, 2009
  8. Jari AaltoAug 31, 2009
  9. Junio C HamanoAug 31, 2009
  10. Improve --patch option documentation in git-addJari Aalto, Sep 13, 2009
  11. Mikael MagnussonSep 13, 2009
  12. Jari AaltoSep 13, 2009
  13. Sean EstabrooksSep 14, 2009
  14. Jari AaltoSep 15, 2009
  15. Nanako ShiraishiSep 15, 2009
  16. Jari AaltoSep 15, 2009
  17. Nanako ShiraishiSep 15, 2009
  18. Junio C HamanoAug 30, 2009
  19. Jari AaltoAug 31, 2009
  20. Junio C HamanoAug 31, 2009
  21. Jari AaltoAug 30, 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.