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

Re: [PATCH 3/7] Documentation: complicate example of "man git-command"

From
Jonathan Nieder <jrnieder@uchicago.edu>
Date
Jul 3, 2008, 01:45 UTC
Message-ID
<Pine.GSO.4.62.0807022010280.10323@harper.uchicago.edu>
In-Reply-To
<20080702213148.GA26921@fieldses.org>
J. Bruce Fields wrote:
Show 18 quoted lines
> On Tue, Jul 01, 2008 at 04:54:53PM -0700, Junio C Hamano wrote:
>
>> We would want to mention the typesetting convention early in the manuals
>> (git(7), gittutorial(7) and user-manual.html) as well, so how about...
>> 
>> 	Conventions used in this document
>>         ---------------------------------
>> 
>> 	When talking about a git subcommand 'cmd', this documentation
>> 	typesets the name of it like 'git-cmd', and that is the name you
>> 	ask for its manual page.
>> 
>>         Examples are typeset like this: `$ git cmd` (`$` is your command
>> 	prompt, do not actually type it to your shell).  Note that a
>> 	subcommand is specified as the first parameter to the 'git'
>> 	program when you actually run it from the command line.
> 
> I'm not convinced this last sentence is necessary.

I agree, but I think it doesn't hurt. I think the point was to establish the word and concept "subcommand".

> > [example showing typographical conventions]
> 
> Typographical conventions shouldn't need so much explanation.

Yes, I suppose. I'm used to printed manuals having a page on the meaning of different typefaces inside, but that's a bit of a different situation.

> I'm curious: Jonathan, was this the original patch the result of a
> real-life instance of confusion?  What happened?

No, I'm actually a bit ashamed to have sent the patch... I was just changing `git subcommand` to `git-subcommand` wherever it was the name of a command, rather than the command line to run it, that was in question. Consistency would have made the old example awkward, so I looked around for alternatives.

Why worry about whether the man pages have no consistent rule about dashes? Since it is not obvious why the man pages use the dashed form when they do, I think a fraction of people will naturally use the dashed form by default. That means trouble once Git 1.6.0 comes out (e.g. see Ingo's recent post <http://thread.gmane.org/gmane.comp.version-control.git/87012/focus=87020>).

Here's a patch implementing Junio's suggestion, because I do like it. Please let me know what you think (especially ideas for making it shorter).

Thanks for all your thoughts so far. Sorry I took so long to get back.
--- %< --- %< --- %< ----
Subject: gittutorial(7): add "Conventions used in this document" section
    
The manual page for the git subcommand invoked as "git clone" is
named git-clone(1), and similarly for the rest of the git
subcommands. This patch should make the convention a little
clearer when it is introduced at the beginning of gittutorial(7).
Thanks to Junio C Hamano for the idea and wording.

It remains to make an analogous change for user-manual.html and maybe git(1).

Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>
---
 Documentation/gittutorial.txt |   35 ++++++++++++++++++++++++++++++-----
 1 files changed, 30 insertions(+), 5 deletions(-)
diff --git a/Documentation/gittutorial.txt
b/Documentation/gittutorial.txt
index 036a27c..51ad814 100644
--- a/Documentation/gittutorial.txt
+++ b/Documentation/gittutorial.txt
@@ -19,12 +19,37 @@ If you are instead primarily interested in using
git to fetch a project,
 for example, to test the latest version, you may prefer to start with
 the first two chapters of link:user-manual.html[The Git User's Manual].
 
-First, note that you can get documentation for a command such as
-`git log --graph` with:
+Conventions used in this document
+---------------------------------
 
-------------------------------------------------
-$ man git-log
-------------------------------------------------
+When discussing a git subcommand 'cmd', this documentation
+typesets the name of it like 'git-cmd', and that is the name you
+ask for its manual page by.
+
+Examples are typeset like this: `$ git cmd`. (`$` is your command
+prompt; do not actually type it to your shell.) A subcommand
+is specified as the first parameter to the 'git' program
+when you actually run it from the command line.
+
+So a typical command description may go like this:
+
+To propagate the changes you made back to the original subversion
+repository, you would use the 'git-svn dcommit' command. It does
+these things (long description here).  Some examples:
+
+------------
+$ ... some example command sequence ...
+$ git svn dcommit
+------------
+
+For full details, type:
+
+------------
+$ man git-svn
+------------
+
+Introducing yourself to git
+---------------------------
 
 It is a good idea to introduce yourself to git with your name and
 public email address before doing any operation.  The easiest
-- 
1.5.5.GIT
Previous: J. Bruce FieldsNext: J. Bruce Fields
Message 10 of 40 in “Some superficial documentation changes”
  1. 0/7 Some superficial documentation changesJonathan Nieder, Jun 30, 2008
  2. 1/7 Documentation: fix links to tutorials and other new manual pagesJonathan Nieder, Jun 30, 2008
  3. Christian CouderJun 30, 2008
  4. 2/7 whitespace fix in Documentation/git-repack.txtJonathan Nieder, Jun 30, 2008
  5. 3/7 Documentation: complicate example of "man git-command"Jonathan Nieder, Jun 30, 2008
  6. Christian CouderJun 30, 2008
  7. J. Bruce FieldsJul 1, 2008
  8. Junio C HamanoJul 1, 2008
  9. J. Bruce FieldsJul 2, 2008
  10. Jonathan NiederJul 3, 2008
  11. J. Bruce FieldsJul 3, 2008
  12. Christian CouderJul 3, 2008
  13. Junio C HamanoJul 3, 2008
  14. 4/7 git-daemon(1): don't assume git-daemon is in /usr/binJonathan Nieder, Jun 30, 2008
  15. 5/7 Documentation: prepare to be consistent about "git-" versus "git "Jonathan Nieder, Jun 30, 2008
  16. 6/7 Documentation: be consistent about "git-" versus "git "Jonathan Nieder, Jun 30, 2008
  17. 7/7 Documentation formatting and cleanupJonathan Nieder, Jun 30, 2008
  18. Olivier MarinJul 1, 2008
  19. Junio C HamanoJul 1, 2008
  20. Jonathan NiederJul 3, 2008
  21. Jonathan NiederJul 3, 2008
  22. Junio C HamanoJul 1, 2008
  23. Jonathan NiederJul 3, 2008
  24. 01/15 git-format-patch(1): fix stray \ in outputJonathan Nieder, Jul 3, 2008
  25. 02/15 Documentation: fix gitlinksJonathan Nieder, Jul 3, 2008
  26. 03/15 manpages: fix bogus whitespaceJonathan Nieder, Jul 3, 2008
  27. Junio C HamanoJul 3, 2008
  28. Jonathan NiederJul 4, 2008
  29. 04/15 git(1): add commaJonathan Nieder, Jul 3, 2008
  30. 05/15 git-commit(1): depersonalize descriptionJonathan Nieder, Jul 3, 2008
  31. 06/15 Documentation: rewrap to prepare for "git-" vs "git " changeJonathan Nieder, Jul 3, 2008
  32. 07/15 Documentation: more "git-" versus "git " changesJonathan Nieder, Jul 3, 2008
  33. 08/15 gitdiffcore(7): fix awkward wordingJonathan Nieder, Jul 3, 2008
  34. 09/15 manpages: italicize command names in synopsesJonathan Nieder, Jul 3, 2008
  35. 10/15 manpages: italicize command namesJonathan Nieder, Jul 3, 2008
  36. 11/15 manpages: italicize git command names (which were in teletype font)Jonathan Nieder, Jul 3, 2008
  37. 12/15 manpages: italicize gitk's name (where it was in teletype font)Jonathan Nieder, Jul 3, 2008
  38. 13/15 manpages: italicize nongit command names (if they are in teletype font)Jonathan Nieder, Jul 3, 2008
  39. 14/15 manpages: italicize git subcommand names (which were in teletype font)Jonathan Nieder, Jul 3, 2008
  40. 15/15 manpages: use teletype font for sample command linesJonathan Nieder, Jul 3, 2008

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.