{"thread":{"id":"18490","subject":"[RFC/WIP 1/2] Documentation: fix minor inconsistency","startedAt":"2009-03-23T14:28:51Z","lastAt":"2009-03-24T08:24:30Z","messageCount":11,"participants":["Michael J Gruber","Matthieu Moy","Junio C Hamano","Chris Johnsen","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"109071","messageId":"1237818533-31577-1-git-send-email-git@drmicha.warpmail.net","threadId":"18490","inReplyTo":null,"subject":"[RFC/WIP 0/2] Documentation clean-up: git commands","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-03-23T14:28:51Z","receivedAt":"2009-03-23T14:28:51Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"In current git documentation, git commands are still written in various\nstyles: with and without dash, unformatted and formatted with `, ' or \".\n\nI propose to use `git command` consistently. In asciidoc, backticks are\nfor commands, ticks for paths. [Quotes should be like ``this''.]\n\nA first step is reaching a consistent use of backticks. A second step\nwould be sed magic to get rid of the dashes in the text, not in the\nlinks (linkgit:...).\n\nPatch 1 is a preparation patch where I spotted the use of a command with\n\"git\" in an instance where it looks very inconsistent. (It feels OK when\ntalking about commands more colloquially.)\n\nPatch 2 is an example for the first step.\n\nQuestions:\n- Do we want this at all?\n- Do we want it this way (`git command`)?\n- How to prepare: 1 patch per file/per 5 files/per 50 changes?\n- How to submit: single patch once ready or whole series at end (5 years\n  from now)?\n- How to send: Bother the list or send pull requests only?\n\nI don't know what I'm getting myself into...\nMichael\n\nMichael J Gruber (2):\n  Documentation: fix minor inconsistency\n  Documentation: format git commands consistently\n\n Documentation/config.txt              |  114 ++++++++++++++++----------------\n Documentation/diff-format.txt         |    6 +-\n Documentation/diff-generate-patch.txt |   12 ++--\n Documentation/diff-options.txt        |    4 +-\n Documentation/everyday.txt            |    6 +-\n Documentation/fetch-options.txt       |   12 ++--\n Documentation/git-add.txt             |   28 ++++----\n Documentation/git-am.txt              |   16 ++--\n 8 files changed, 99 insertions(+), 99 deletions(-)\n"},{"id":"109069","messageId":"1237818533-31577-2-git-send-email-git@drmicha.warpmail.net","threadId":"18490","inReplyTo":"1237818533-31577-1-git-send-email-git@drmicha.warpmail.net","subject":"[RFC/WIP 1/2] Documentation: fix minor inconsistency","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-03-23T14:28:52Z","receivedAt":"2009-03-23T14:28:52Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"While we don't always write out commands in full (`git command`) we\nshould do it consistently in adjacent paragraphs.\n\nSigned-off-by: Michael J Gruber <git@drmicha.warpmail.net>\n---\n Documentation/config.txt |    2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 089569a..e093ff3 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -1254,7 +1254,7 @@ receive.denyDeletes::\n \tthe ref. Use this to prevent such a ref deletion via a push.\n \n receive.denyCurrentBranch::\n-\tIf set to true or \"refuse\", receive-pack will deny a ref update\n+\tIf set to true or \"refuse\", git-receive-pack will deny a ref update\n \tto the currently checked out branch of a non-bare repository.\n \tSuch a push is potentially dangerous because it brings the HEAD\n \tout of sync with the index and working tree. If set to \"warn\",\n-- \n1.6.2.149.g6462\n"},{"id":"109070","messageId":"1237818533-31577-3-git-send-email-git@drmicha.warpmail.net","threadId":"18490","inReplyTo":"1237818533-31577-2-git-send-email-git@drmicha.warpmail.net","subject":"[RFC/WIP 2/2] Documentation: format git commands consistently","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-03-23T14:28:53Z","receivedAt":"2009-03-23T14:28:53Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Commands should be formatted `command` in asciidoc. So, try and catch all\npresent styles (\"command\", 'command', command) and convert to this at\nleast for git commands.\n\nSigned-off-by: Michael J Gruber <git@drmicha.warpmail.net>\n---\n Documentation/config.txt              |  114 ++++++++++++++++----------------\n Documentation/diff-format.txt         |    6 +-\n Documentation/diff-generate-patch.txt |   12 ++--\n Documentation/diff-options.txt        |    4 +-\n Documentation/everyday.txt            |    6 +-\n Documentation/fetch-options.txt       |   12 ++--\n Documentation/git-add.txt             |   28 ++++----\n Documentation/git-am.txt              |   16 ++--\n 8 files changed, 99 insertions(+), 99 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex e093ff3..ea15552 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -63,7 +63,7 @@ The values following the equals sign in variable assign are all either\n a string, an integer, or a boolean.  Boolean values may be given as yes/no,\n 0/1 or true/false.  Case is not significant in boolean values, when\n converting value to the canonical form using '--bool' type specifier;\n-'git-config' will ensure that the output is \"true\" or \"false\".\n+`git-config` will ensure that the output is \"true\" or \"false\".\n \n String values may be entirely or partially enclosed in double quotes.\n You need to enclose variable value in double quotes if you want to\n@@ -393,8 +393,8 @@ core.pager::\n \n core.whitespace::\n \tA comma separated list of common whitespace problems to\n-\tnotice.  'git-diff' will use `color.diff.whitespace` to\n-\thighlight them, and 'git-apply --whitespace=error' will\n+\tnotice.  `git-diff` will use `color.diff.whitespace` to\n+\thighlight them, and `git-apply --whitespace=error` will\n \tconsider them as errors.  You can prefix `-` to disable\n \tany of them (e.g. `-trailing-space`):\n +\n@@ -419,9 +419,9 @@ journalling (traditional UNIX filesystems) or that only journal metadata\n and not file contents (OS X's HFS+, or Linux ext3 with \"data=writeback\").\n \n core.preloadindex::\n-\tEnable parallel index preload for operations like 'git diff'\n+\tEnable parallel index preload for operations like `git diff`\n +\n-This can speed up operations like 'git diff' and 'git status' especially\n+This can speed up operations like `git diff` and `git status` especially\n on filesystems like NFS that have weak caching semantics and thus\n relatively high IO latencies.  With this set to 'true', git will do the\n index comparison to the filesystem data in parallel, allowing\n@@ -430,7 +430,7 @@ overlapping IO's.\n alias.*::\n \tCommand aliases for the linkgit:git[1] command wrapper - e.g.\n \tafter defining \"alias.last = cat-file commit HEAD\", the invocation\n-\t\"git last\" is equivalent to \"git cat-file commit HEAD\". To avoid\n+\t`git last` is equivalent to `git cat-file commit HEAD`. To avoid\n \tconfusion and troubles with script usage, aliases that\n \thide existing git commands are ignored. Arguments are split by\n \tspaces, the usual shell quoting and escaping is supported.\n@@ -439,15 +439,15 @@ alias.*::\n If the alias expansion is prefixed with an exclamation point,\n it will be treated as a shell command.  For example, defining\n \"alias.new = !gitk --all --not ORIG_HEAD\", the invocation\n-\"git new\" is equivalent to running the shell command\n-\"gitk --all --not ORIG_HEAD\".\n+`git new` is equivalent to running the shell command\n+`gitk --all --not ORIG_HEAD`.\n \n apply.whitespace::\n-\tTells 'git-apply' how to handle whitespaces, in the same way\n+\tTells `git-apply` how to handle whitespaces, in the same way\n \tas the '--whitespace' option. See linkgit:git-apply[1].\n \n branch.autosetupmerge::\n-\tTells 'git-branch' and 'git-checkout' to setup new branches\n+\tTells `git-branch` and `git-checkout` to setup new branches\n \tso that linkgit:git-pull[1] will appropriately merge from the\n \tstarting point branch. Note that even if this option is not set,\n \tthis behavior can be chosen per-branch using the `--track`\n@@ -458,7 +458,7 @@ branch.autosetupmerge::\n \tbranch. This option defaults to true.\n \n branch.autosetuprebase::\n-\tWhen a new branch is created with 'git-branch' or 'git-checkout'\n+\tWhen a new branch is created with `git-branch` or `git-checkout`\n \tthat tracks another branch, this variable tells git to set\n \tup pull to rebase instead of merge (see \"branch.<name>.rebase\").\n \tWhen `never`, rebase is never automatically set to true.\n@@ -473,20 +473,20 @@ branch.autosetuprebase::\n \tThis option defaults to never.\n \n branch.<name>.remote::\n-\tWhen in branch <name>, it tells 'git-fetch' which remote to fetch.\n-\tIf this option is not given, 'git-fetch' defaults to remote \"origin\".\n+\tWhen in branch <name>, it tells `git-fetch` which remote to fetch.\n+\tIf this option is not given, `git-fetch` defaults to remote \"origin\".\n \n branch.<name>.merge::\n-\tWhen in branch <name>, it tells 'git-fetch' the default\n+\tWhen in branch <name>, it tells `git-fetch` the default\n \trefspec to be marked for merging in FETCH_HEAD. The value is\n \thandled like the remote part of a refspec, and must match a\n \tref which is fetched from the remote given by\n \t\"branch.<name>.remote\".\n-\tThe merge information is used by 'git-pull' (which at first calls\n-\t'git-fetch') to lookup the default branch for merging. Without\n-\tthis option, 'git-pull' defaults to merge the first refspec fetched.\n+\tThe merge information is used by `git-pull` (which at first calls\n+\t`git-fetch`) to lookup the default branch for merging. Without\n+\tthis option, `git-pull` defaults to merge the first refspec fetched.\n \tSpecify multiple values to get an octopus merge.\n-\tIf you wish to setup 'git-pull' so that it merges into <name> from\n+\tIf you wish to setup `git-pull` so that it merges into <name> from\n \tanother branch in the local repository, you can point\n \tbranch.<name>.merge to the desired branch, and use the special setting\n \t`.` (a period) for branch.<name>.remote.\n@@ -500,7 +500,7 @@ branch.<name>.mergeoptions::\n branch.<name>.rebase::\n \tWhen true, rebase the branch <name> on top of the fetched branch,\n \tinstead of merging the default branch from the default remote when\n-\t\"git pull\" is run.\n+\t`git pull` is run.\n \t*NOTE*: this is a possibly dangerous operation; do *not* use\n \tit unless you understand the implications (see linkgit:git-rebase[1]\n \tfor details).\n@@ -516,7 +516,7 @@ browser.<tool>.path::\n \tworking repository in gitweb (see linkgit:git-instaweb[1]).\n \n clean.requireForce::\n-\tA boolean to make git-clean do nothing unless given -f\n+\tA boolean to make `git-clean` do nothing unless given -f\n \tor -n.   Defaults to true.\n \n color.branch::\n@@ -574,12 +574,12 @@ color.grep.match::\n \n color.interactive::\n \tWhen set to `always`, always use colors for interactive prompts\n-\tand displays (such as those used by \"git-add --interactive\").\n+\tand displays (such as those used by `git-add --interactive`).\n \tWhen false (or `never`), never.  When set to `true` or `auto`, use\n \tcolors only when the output is to the terminal. Defaults to false.\n \n color.interactive.<slot>::\n-\tUse customized color for 'git-add --interactive'\n+\tUse customized color for `git-add --interactive`\n \toutput. `<slot>` may be `prompt`, `header`, `help` or `error`, for\n \tfour distinct types of normal output from interactive\n \tprograms.  The values of these variables may be specified as\n@@ -616,14 +616,14 @@ commit.template::\n \tSpecify a file to use as the template for new commit messages.\n \n diff.autorefreshindex::\n-\tWhen using 'git-diff' to compare with work tree\n+\tWhen using `git-diff` to compare with work tree\n \tfiles, do not consider stat-only change as changed.\n \tInstead, silently run `git update-index --refresh` to\n \tupdate the cached stat information for paths whose\n \tcontents in the work tree match the contents in the\n \tindex.  This option defaults to true.  Note that this\n-\taffects only 'git-diff' Porcelain, and not lower level\n-\t'diff' commands, such as 'git-diff-files'.\n+\taffects only `git-diff` Porcelain, and not lower level\n+\t`diff` commands, such as `git-diff-files`.\n \n diff.external::\n \tIf this config variable is set, diff generation is not\n@@ -635,24 +635,24 @@ diff.external::\n \tyour files, you\tmight want to use linkgit:gitattributes[5] instead.\n \n diff.mnemonicprefix::\n-\tIf set, 'git-diff' uses a prefix pair that is different from the\n+\tIf set, `git-diff` uses a prefix pair that is different from the\n \tstandard \"a/\" and \"b/\" depending on what is being compared.  When\n \tthis configuration is in effect, reverse diff output also swaps\n \tthe order of the prefixes:\n-'git-diff';;\n+`git-diff`;;\n \tcompares the (i)ndex and the (w)ork tree;\n-'git-diff HEAD';;\n+`git-diff HEAD`;;\n \t compares a (c)ommit and the (w)ork tree;\n-'git diff --cached';;\n+`git diff --cached`;;\n \tcompares a (c)ommit and the (i)ndex;\n-'git-diff HEAD:file1 file2';;\n+`git-diff HEAD:file1 file2`;;\n \tcompares an (o)bject and a (w)ork tree entity;\n-'git diff --no-index a b';;\n+`git diff --no-index a b`;;\n \tcompares two non-git things (1) and (2).\n \n diff.renameLimit::\n \tThe number of files to consider when performing the copy/rename\n-\tdetection; equivalent to the 'git-diff' option '-l'.\n+\tdetection; equivalent to the `git-diff` option '-l'.\n \n diff.renames::\n \tTells git to detect renames.  If set to any boolean value, it\n@@ -719,7 +719,7 @@ format.pretty::\n \tlinkgit:git-whatchanged[1].\n \n format.thread::\n-\tThe default threading style for 'git-format-patch'.  Can be\n+\tThe default threading style for `git-format-patch`.  Can be\n \teither a boolean value, `shallow` or `deep`.  'Shallow'\n \tthreading makes every mail a reply to the head of the series,\n \twhere the head is chosen from the cover letter, the\n@@ -730,7 +730,7 @@ format.thread::\n \n gc.aggressiveWindow::\n \tThe window size parameter used in the delta compression\n-\talgorithm used by 'git-gc --aggressive'.  This defaults\n+\talgorithm used by `git-gc --aggressive`.  This defaults\n \tto 10.\n \n gc.auto::\n@@ -747,39 +747,39 @@ gc.autopacklimit::\n \tdefault\tvalue is 50.  Setting this to 0 disables it.\n \n gc.packrefs::\n-\t'git-gc' does not run `git pack-refs` in a bare repository by\n+\t`git-gc` does not run `git pack-refs` in a bare repository by\n \tdefault so that older dumb-transport clients can still fetch\n-\tfrom the repository.  Setting this to `true` lets 'git-gc'\n+\tfrom the repository.  Setting this to `true` lets `git-gc`\n \tto run `git pack-refs`.  Setting this to `false` tells\n-\t'git-gc' never to run `git pack-refs`. The default setting is\n+\t`git-gc` never to run `git pack-refs`. The default setting is\n \t`notbare`. Enable it only when you know you do not have to\n \tsupport such clients.  The default setting will change to `true`\n \tat some stage, and setting this to `false` will continue to\n-\tprevent `git pack-refs` from being run from 'git-gc'.\n+\tprevent `git pack-refs` from being run from `git-gc`.\n \n gc.pruneexpire::\n-\tWhen 'git-gc' is run, it will call 'prune --expire 2.weeks.ago'.\n+\tWhen `git-gc` is run, it will call `prune --expire 2.weeks.ago`.\n \tOverride the grace period with this config variable.  The value\n \t\"now\" may be used to disable this  grace period and always prune\n \tunreachable objects immediately.\n \n gc.reflogexpire::\n-\t'git-reflog expire' removes reflog entries older than\n+\t`git-reflog expire` removes reflog entries older than\n \tthis time; defaults to 90 days.\n \n gc.reflogexpireunreachable::\n-\t'git-reflog expire' removes reflog entries older than\n+\t`git-reflog expire` removes reflog entries older than\n \tthis time and are not reachable from the current tip;\n \tdefaults to 30 days.\n \n gc.rerereresolved::\n \tRecords of conflicted merge you resolved earlier are\n-\tkept for this many days when 'git-rerere gc' is run.\n+\tkept for this many days when `git-rerere gc` is run.\n \tThe default is 60 days.  See linkgit:git-rerere[1].\n \n gc.rerereunresolved::\n \tRecords of conflicted merge you have not resolved are\n-\tkept for this many days when 'git-rerere gc' is run.\n+\tkept for this many days when `git-rerere gc` is run.\n \tThe default is 15 days.  See linkgit:git-rerere[1].\n \n gitcvs.commitmsgannotation::\n@@ -814,7 +814,7 @@ gitcvs.allbinary::\n \tit is binary, similar to 'core.autocrlf'.\n \n gitcvs.dbname::\n-\tDatabase used by git-cvsserver to cache revision information\n+\tDatabase used by `git-cvsserver` to cache revision information\n \tderived from the git repository. The exact meaning depends on the\n \tused database driver, for SQLite (which is the default driver) this\n \tis a filename. Supports variable substitution (see\n@@ -823,7 +823,7 @@ gitcvs.dbname::\n \n gitcvs.dbdriver::\n \tUsed Perl DBI driver. You can specify any available driver\n-        for this here, but it might not work. git-cvsserver is tested\n+        for this here, but it might not work. `git-cvsserver` is tested\n \twith 'DBD::SQLite', reported to work with 'DBD::Pg', and\n \treported *not* to work with 'DBD::mysql'. Experimental feature.\n \tMay not contain double colons (`:`). Default: 'SQLite'.\n@@ -887,19 +887,19 @@ gui.spellingdictionary::\n \toff.\n \n gui.fastcopyblame::\n-\tIf true, 'git gui blame' uses '-C' instead of '-C -C' for original\n+\tIf true, `git gui blame` uses '-C' instead of '-C -C' for original\n \tlocation detection. It makes blame significantly faster on huge\n \trepositories at the expense of less thorough copy detection.\n \n gui.copyblamethreshold::\n-\tSpecifies the threshold to use in 'git gui blame' original location\n+\tSpecifies the threshold to use in `git gui blame` original location\n \tdetection, measured in alphanumeric characters. See the\n \tlinkgit:git-blame[1] manual for more information on copy detection.\n \n gui.blamehistoryctx::\n \tSpecifies the radius of history context in days to show in\n \tlinkgit:gitk[1] for the selected commit, when the `Show History\n-\tContext` menu item is invoked from 'git gui blame'. If this\n+\tContext` menu item is invoked from `git gui blame`. If this\n \tvariable is set to zero, the whole history is shown.\n \n guitool.<name>.cmd::\n@@ -1026,7 +1026,7 @@ i18n.commitEncoding::\n \n i18n.logOutputEncoding::\n \tCharacter encoding the commit messages are converted to when\n-\trunning 'git-log' and friends.\n+\trunning `git-log` and friends.\n \n imap::\n \tThe configuration variables in the 'imap' section are described\n@@ -1060,7 +1060,7 @@ interactive.singlekey::\n \n log.date::\n \tSet default date-time mode for the log command. Setting log.date\n-\tvalue is similar to using 'git-log'\\'s --date option. The value is one of the\n+\tvalue is similar to using `git-log`\\'s --date option. The value is one of the\n \tfollowing alternatives: {relative,local,default,iso,rfc,short}.\n \tSee linkgit:git-log[1].\n \n@@ -1212,7 +1212,7 @@ pull.twohead::\n \tThe default merge strategy to use when pulling a single branch.\n \n push.default::\n-\tDefines the action git push should take if no refspec is given\n+\tDefines the action `git push` should take if no refspec is given\n \ton the command line, no refspec is configured in the remote, and\n \tno refspec is implied by any of the options given on the command\n \tline.\n@@ -1234,7 +1234,7 @@ rebase.stat::\n \trebase. False by default.\n \n receive.fsckObjects::\n-\tIf it is set to true, git-receive-pack will check all received\n+\tIf it is set to true, `git-receive-pack` will check all received\n \tobjects. It will abort in the case of a malformed object or a\n \tbroken link. The result of an abort are only dangling objects.\n \tDefaults to false.\n@@ -1250,11 +1250,11 @@ receive.unpackLimit::\n \t`transfer.unpackLimit` is used instead.\n \n receive.denyDeletes::\n-\tIf set to true, git-receive-pack will deny a ref update that deletes\n+\tIf set to true, `git-receive-pack` will deny a ref update that deletes\n \tthe ref. Use this to prevent such a ref deletion via a push.\n \n receive.denyCurrentBranch::\n-\tIf set to true or \"refuse\", git-receive-pack will deny a ref update\n+\tIf set to true or \"refuse\", `git-receive-pack` will deny a ref update\n \tto the currently checked out branch of a non-bare repository.\n \tSuch a push is potentially dangerous because it brings the HEAD\n \tout of sync with the index and working tree. If set to \"warn\",\n@@ -1263,7 +1263,7 @@ receive.denyCurrentBranch::\n \tmessage. Defaults to \"warn\".\n \n receive.denyNonFastForwards::\n-\tIf set to true, git-receive-pack will deny a ref update which is\n+\tIf set to true, `git-receive-pack` will deny a ref update which is\n \tnot a fast forward. Use this to prevent such an update via a push,\n \teven if that push is forced. This configuration variable is\n \tset when initializing a shared repository.\n@@ -1306,8 +1306,8 @@ remote.<name>.tagopt::\n \tfetching from remote <name>\n \n remotes.<group>::\n-\tThe list of remotes which are fetched by \"git remote update\n-\t<group>\".  See linkgit:git-remote[1].\n+\tThe list of remotes which are fetched by `git remote update\n+\t<group>`.  See linkgit:git-remote[1].\n \n repack.usedeltabaseoffset::\n \tBy default, linkgit:git-repack[1] creates packs that use\ndiff --git a/Documentation/diff-format.txt b/Documentation/diff-format.txt\nindex 1eeb1c7..31653c1 100644\n--- a/Documentation/diff-format.txt\n+++ b/Documentation/diff-format.txt\n@@ -1,5 +1,5 @@\n-The output format from \"git-diff-index\", \"git-diff-tree\",\n-\"git-diff-files\" and \"git diff --raw\" are very similar.\n+The output format from `git-diff-index`, `git-diff-tree`,\n+`git-diff-files` and `git diff --raw` are very similar.\n \n These commands all compare two sets of things; what is\n compared differs:\n@@ -78,7 +78,7 @@ respectively.\n diff format for merges\n ----------------------\n \n-\"git-diff-tree\", \"git-diff-files\" and \"git-diff --raw\"\n+`git-diff-tree`, `git-diff-files` and `git-diff --raw`\n can take '-c' or '--cc' option\n to generate diff output also for merge commits.  The output differs\n from the format described above in the following way:\ndiff --git a/Documentation/diff-generate-patch.txt b/Documentation/diff-generate-patch.txt\nindex 0f25ba7..8889d19 100644\n--- a/Documentation/diff-generate-patch.txt\n+++ b/Documentation/diff-generate-patch.txt\n@@ -1,9 +1,9 @@\n Generating patches with -p\n --------------------------\n \n-When \"git-diff-index\", \"git-diff-tree\", or \"git-diff-files\" are run\n-with a '-p' option, \"git diff\" without the '--raw' option, or\n-\"git log\" with the \"-p\" option, they\n+When `git-diff-index`, `git-diff-tree`, or `git-diff-files` are run\n+with a '-p' option, `git diff` without the '--raw' option, or\n+`git log` with the \"-p\" option, they\n do not produce the output described above; instead they produce a\n patch file.  You can customize the creation of such patches via the\n GIT_EXTERNAL_DIFF and the GIT_DIFF_OPTS environment variables.\n@@ -11,7 +11,7 @@ GIT_EXTERNAL_DIFF and the GIT_DIFF_OPTS environment variables.\n What the -p option produces is slightly different from the traditional\n diff format.\n \n-1.   It is preceded with a \"git diff\" header, that looks like\n+1.   It is preceded with a `git diff` header, that looks like\n      this:\n \n        diff --git a/file1 b/file2\n@@ -54,9 +54,9 @@ file made it into the new one.\n combined diff format\n --------------------\n \n-\"git-diff-tree\", \"git-diff-files\" and \"git-diff\" can take '-c' or\n+`git-diff-tree`, `git-diff-files` and `git-diff` can take '-c' or\n '--cc' option to produce 'combined diff'.  For showing a merge commit\n-with \"git log -p\", this is the default format.\n+with `git log -p`, this is the default format.\n A 'combined diff' format looks like this:\n \n ------------\ndiff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt\nindex 9276fae..8fc26b3 100644\n--- a/Documentation/diff-options.txt\n+++ b/Documentation/diff-options.txt\n@@ -78,7 +78,7 @@ endif::git-format-patch[]\n -z::\n \tNUL-line termination on output.  This affects the --raw\n \toutput field terminator.  Also output from commands such\n-\tas \"git-log\" will be delimited with NUL between commits.\n+\tas `git-log` will be delimited with NUL between commits.\n \n --name-only::\n \tShow only names of changed files.\n@@ -128,7 +128,7 @@ override configuration settings.\n \n --binary::\n \tIn addition to --full-index, output \"binary diff\" that\n-\tcan be applied with \"git apply\".\n+\tcan be applied with `git apply`.\n \n --abbrev[=<n>]::\n \tInstead of showing the full 40-byte hexadecimal object\ndiff --git a/Documentation/everyday.txt b/Documentation/everyday.txt\nindex 9310b65..da3dfa0 100644\n--- a/Documentation/everyday.txt\n+++ b/Documentation/everyday.txt\n@@ -360,7 +360,7 @@ $ grep 9418 /etc/services\n git\t\t9418/tcp\t\t# Git Version Control System\n ------------\n \n-Run git-daemon to serve /pub/scm from inetd.::\n+Run `git-daemon` to serve /pub/scm from inetd.::\n +\n ------------\n $ grep git /etc/inetd.conf\n@@ -370,7 +370,7 @@ git\tstream\ttcp\tnowait\tnobody \\\n +\n The actual configuration line should be on one line.\n \n-Run git-daemon to serve /pub/scm from xinetd.::\n+Run `git-daemon` to serve /pub/scm from xinetd.::\n +\n ------------\n $ cat /etc/xinetd.d/git-daemon\n@@ -405,7 +405,7 @@ $ grep git /etc/shells <2>\n /usr/bin/git-shell\n ------------\n +\n-<1> log-in shell is set to /usr/bin/git-shell, which does not\n+<1> log-in shell is set to `/usr/bin/git-shell`, which does not\n allow anything but `git push` and `git pull`.  The users should\n get an ssh access to the machine.\n <2> in many distributions /etc/shells needs to list what is used\ndiff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt\nindex d313795..4aed833 100644\n--- a/Documentation/fetch-options.txt\n+++ b/Documentation/fetch-options.txt\n@@ -1,6 +1,6 @@\n -q::\n --quiet::\n-\tPass --quiet to git-fetch-pack and silence any other internally\n+\tPass --quiet to `git-fetch-pack` and silence any other internally\n \tused programs.\n \n -v::\n@@ -15,13 +15,13 @@\n \n --upload-pack <upload-pack>::\n \tWhen given, and the repository to fetch from is handled\n-\tby 'git-fetch-pack', '--exec=<upload-pack>' is passed to\n+\tby `git-fetch-pack`, `--exec=<upload-pack>` is passed to\n \tthe command to specify non-default path for the command\n \trun on the other end.\n \n -f::\n --force::\n-\tWhen 'git-fetch' is used with `<rbranch>:<lbranch>`\n+\tWhen `git-fetch` is used with `<rbranch>:<lbranch>`\n \trefspec, it refuses to update the local branch\n \t`<lbranch>` unless the remote branch `<rbranch>` it\n \tfetches is a descendant of `<lbranch>`.  This option\n@@ -53,10 +53,10 @@ endif::git-pull[]\n \n -u::\n --update-head-ok::\n-\tBy default 'git-fetch' refuses to update the head which\n+\tBy default `git-fetch` refuses to update the head which\n \tcorresponds to the current branch.  This flag disables the\n-\tcheck.  This is purely for the internal use for 'git-pull'\n-\tto communicate with 'git-fetch', and unless you are\n+\tcheck.  This is purely for the internal use for `git-pull`\n+\tto communicate with `git-fetch`, and unless you are\n \timplementing your own Porcelain you are not supposed to\n \tuse it.\n \ndiff --git a/Documentation/git-add.txt b/Documentation/git-add.txt\nindex ce71838..ef9c136 100644\n--- a/Documentation/git-add.txt\n+++ b/Documentation/git-add.txt\n@@ -8,7 +8,7 @@ git-add - Add file contents to the index\n SYNOPSIS\n --------\n [verse]\n-'git add' [-n] [-v] [--force | -f] [--interactive | -i] [--patch | -p]\n+`git add` [-n] [-v] [--force | -f] [--interactive | -i] [--patch | -p]\n \t  [--all | [--update | -u]] [--intent-to-add | -N]\n \t  [--refresh] [--ignore-errors] [--] <filepattern>...\n \n@@ -20,22 +20,22 @@ index, thus staging that content for inclusion in the next commit.\n The \"index\" holds a snapshot of the content of the working tree, and it\n is this snapshot that is taken as the contents of the next commit.  Thus\n after making any changes to the working directory, and before running\n-the commit command, you must use the 'add' command to add any new or\n+the commit command, you must use the `add` command to add any new or\n modified files to the index.\n \n This command can be performed multiple times before a commit.  It only\n adds the content of the specified file(s) at the time the add command is\n run; if you want subsequent changes included in the next commit, then\n-you must run 'git add' again to add the new content to the index.\n+you must run `git add` again to add the new content to the index.\n \n-The 'git status' command can be used to obtain a summary of which\n+The `git status` command can be used to obtain a summary of which\n files have changes that are staged for the next commit.\n \n-The 'git add' command will not add ignored files by default.  If any\n-ignored files were explicitly specified on the command line, 'git add'\n+The `git add` command will not add ignored files by default.  If any\n+ignored files were explicitly specified on the command line, `git add`\n will fail with a list of ignored files.  Ignored files reached by\n directory recursion or filename globbing performed by Git (quote your\n-globs before the shell) will be silently ignored.  The 'add' command can\n+globs before the shell) will be silently ignored.  The `add` command can\n be used to add ignored files with the `-f` (force) option.\n \n Please see linkgit:git-commit[1] for alternative ways to add content to a\n@@ -81,7 +81,7 @@ OPTIONS\n \tUpdate only files that git already knows about, staging modified\n \tcontent for commit and marking deleted files for removal. This\n \tis similar\n-\tto what \"git commit -a\" does in preparation for making a commit,\n+\tto what `git commit -a` does in preparation for making a commit,\n \texcept that the update is limited to paths specified on the\n \tcommand line. If no paths are specified, all tracked files in the\n \tcurrent directory and its subdirectories are updated.\n@@ -98,8 +98,8 @@ OPTIONS\n \tRecord only the fact that the path will be added later. An entry\n \tfor the path is placed in the index with no content. This is\n \tuseful for, among other things, showing the unstaged content of\n-\tsuch files with 'git diff' and committing them with 'git commit\n-\t-a'.\n+\tsuch files with `git diff` and committing them with `git commit\n+\t-a`.\n \n --refresh::\n \tDon't add the file(s), but only refresh their stat()\n@@ -120,7 +120,7 @@ Configuration\n -------------\n \n The optional configuration variable 'core.excludesfile' indicates a path to a\n-file containing patterns of file names to exclude from git-add, similar to\n+file containing patterns of file names to exclude from `git-add`, similar to\n $GIT_DIR/info/exclude.  Patterns in the exclude file are used in addition to\n those in info/exclude.  See linkgit:gitrepository-layout[5].\n \n@@ -175,9 +175,9 @@ The main command loop has 6 subcommands (plus help and quit).\n status::\n \n    This shows the change between HEAD and index (i.e. what will be\n-   committed if you say \"git commit\"), and between index and\n+   committed if you say `git commit`), and between index and\n    working tree files (i.e. what you could stage further before\n-   \"git commit\" using \"git-add\") for each path.  A sample output\n+   `git commit` using `git-add`) for each path.  A sample output\n    looks like this:\n +\n ------------\n@@ -191,7 +191,7 @@ binary so line count cannot be shown) and there is no\n difference between indexed copy and the working tree\n version (if the working tree version were also different,\n 'binary' would have been shown in place of 'nothing').  The\n-other file, git-add--interactive.perl, has 403 lines added\n+other file, `git-add--interactive.perl`, has 403 lines added\n and 35 lines deleted if you commit what is in the index, but\n working tree file has further modifications (one addition and\n one deletion).\ndiff --git a/Documentation/git-am.txt b/Documentation/git-am.txt\nindex 1e71dd5..c9a444b 100644\n--- a/Documentation/git-am.txt\n+++ b/Documentation/git-am.txt\n@@ -9,13 +9,13 @@ git-am - Apply a series of patches from a mailbox\n SYNOPSIS\n --------\n [verse]\n-'git am' [--signoff] [--keep] [--utf8 | --no-utf8]\n+`git am` [--signoff] [--keep] [--utf8 | --no-utf8]\n \t [--3way] [--interactive] [--committer-date-is-author-date]\n \t [--ignore-date]\n \t [--whitespace=<option>] [-C<n>] [-p<n>] [--directory=<dir>]\n \t [--reject]\n \t [<mbox> | <Maildir>...]\n-'git am' (--skip | --resolved | --abort)\n+`git am` (--skip | --resolved | --abort)\n \n DESCRIPTION\n -----------\n@@ -37,11 +37,11 @@ OPTIONS\n \n -k::\n --keep::\n-\tPass `-k` flag to 'git-mailinfo' (see linkgit:git-mailinfo[1]).\n+\tPass `-k` flag to `git-mailinfo` (see linkgit:git-mailinfo[1]).\n \n -u::\n --utf8::\n-\tPass `-u` flag to 'git-mailinfo' (see linkgit:git-mailinfo[1]).\n+\tPass `-u` flag to `git-mailinfo` (see linkgit:git-mailinfo[1]).\n \tThe proposed commit log message taken from the e-mail\n \tis re-coded into UTF-8 encoding (configuration variable\n \t`i18n.commitencoding` can be used to specify project's\n@@ -51,7 +51,7 @@ This was optional in prior versions of git, but now it is the\n default.   You can use `--no-utf8` to override this.\n \n --no-utf8::\n-\tPass `-n` flag to 'git-mailinfo' (see\n+\tPass `-n` flag to `git-mailinfo` (see\n \tlinkgit:git-mailinfo[1]).\n \n -3::\n@@ -66,7 +66,7 @@ default.   You can use `--no-utf8` to override this.\n -p<n>::\n --directory=<dir>::\n --reject::\n-\tThese flags are passed to the 'git-apply' (see linkgit:git-apply[1])\n+\tThese flags are passed to the `git-apply` (see linkgit:git-apply[1])\n \tprogram that applies\n \tthe patch.\n \n@@ -106,7 +106,7 @@ default.   You can use `--no-utf8` to override this.\n \tto the screen before exiting.  This overrides the\n \tstandard message informing you to use `--resolved`\n \tor `--skip` to handle the failure.  This is solely\n-\tfor internal use between 'git-rebase' and 'git-am'.\n+\tfor internal use between `git-rebase` and `git-am`.\n \n --abort::\n \tRestore the original branch and abort the patching operation.\n@@ -159,7 +159,7 @@ names.\n \n Before any patches are applied, ORIG_HEAD is set to the tip of the\n current branch.  This is useful if you have problems with multiple\n-commits, like running 'git am' on the wrong branch or an error in the\n+commits, like running `git am` on the wrong branch or an error in the\n commits that is more easily fixed by changing the mailbox (e.g.\n errors in the \"From:\" lines).\n \n-- \n1.6.2.149.g6462\n"},{"id":"109072","messageId":"49C79D34.3000408@drmicha.warpmail.net","threadId":"18490","inReplyTo":"1237818533-31577-1-git-send-email-git@drmicha.warpmail.net","subject":"Re: [RFC/WIP 0/2] Documentation clean-up: git commands","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-03-23T14:31:16Z","receivedAt":"2009-03-23T14:31:16Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Michael J Gruber venit, vidit, dixit 23.03.2009 15:28:\n> In current git documentation, git commands are still written in various\n> styles: with and without dash, unformatted and formatted with `, ' or \".\n> \n> I propose to use `git command` consistently. In asciidoc, backticks are\n> for commands, ticks for paths. [Quotes should be like ``this''.]\n> \n> A first step is reaching a consistent use of backticks. A second step\n> would be sed magic to get rid of the dashes in the text, not in the\n> links (linkgit:...).\n> \n> Patch 1 is a preparation patch where I spotted the use of a command with\n> \"git\" in an instance where it looks very inconsistent. (It feels OK when\n\ns/with/without/\n\nSorry :|\n"},{"id":"109075","messageId":"vpq7i2g9u4m.fsf@bauges.imag.fr","threadId":"18490","inReplyTo":"1237818533-31577-2-git-send-email-git@drmicha.warpmail.net","subject":"Re: [RFC/WIP 1/2] Documentation: fix minor inconsistency","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2009-03-23T14:44:09Z","receivedAt":"2009-03-23T14:44:09Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Michael J Gruber <git@drmicha.warpmail.net> writes:\n\n> While we don't always write out commands in full (`git command`) we\n> should do it consistently in adjacent paragraphs.\n\n> -\tIf set to true or \"refuse\", receive-pack will deny a ref update\n> +\tIf set to true or \"refuse\", git-receive-pack will deny a ref update\n\nThen, shouldn't this be `git receive-pack` ?\n\n-- \nMatthieu\n"},{"id":"109077","messageId":"49C7A326.2050403@drmicha.warpmail.net","threadId":"18490","inReplyTo":"vpq7i2g9u4m.fsf@bauges.imag.fr","subject":"Re: [RFC/WIP 1/2] Documentation: fix minor inconsistency","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-03-23T14:56:38Z","receivedAt":"2009-03-23T14:56:38Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Matthieu Moy venit, vidit, dixit 23.03.2009 15:44:\n> Michael J Gruber <git@drmicha.warpmail.net> writes:\n> \n>> While we don't always write out commands in full (`git command`) we\n>> should do it consistently in adjacent paragraphs.\n> \n>> -\tIf set to true or \"refuse\", receive-pack will deny a ref update\n>> +\tIf set to true or \"refuse\", git-receive-pack will deny a ref update\n> \n> Then, shouldn't this be `git receive-pack` ?\n\nIt should be git-receive-pack in the first patch (adding missing git in\nthe same style as used there), `git-receive-pack` in the second patch\n(implementation of step 1) and `git receive-pack` in step 2 (the\nun-dashifying step), which comes later, just as outlined in the cover\nletter. Mixing these steps into one patch would be a reviewing\nnightmare. Squashing those two patches (constituting step 1 for the\nfirst few files) would be fine.\n\nMichael\n"},{"id":"109083","messageId":"7vwsag5hva.fsf@gitster.siamese.dyndns.org","threadId":"18490","inReplyTo":"1237818533-31577-1-git-send-email-git@drmicha.warpmail.net","subject":"Re: [RFC/WIP 0/2] Documentation clean-up: git commands","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-03-23T16:22:33Z","receivedAt":"2009-03-23T16:22:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber <git@drmicha.warpmail.net> writes:\n\n> - Do we want it this way (`git command`)?\n\nThat's my personal preference but other people may differ; wasn't there an\nissue with \"man\" backend losing the typesetting information?\n\n> - How to prepare: 1 patch per file/per 5 files/per 50 changes?\n> - How to submit: single patch once ready or whole series at end (5 years\n>   from now)?\n> - How to send: Bother the list or send pull requests only?\n\nHow about a fork of git.git on repo.or.cz that branches from 1.6.2 and that:\n\n - does not pull from git.git/master unless absoletely necessary; and\n - contains only these clean-up changes and nothing else?\n\nA bonus point would be for a publically reachable pages rendered out of\nthe tip of this \"documentation updates\" repository, so that people can\nview it, compare it with www.kernel.org/pub/software/git/docs/.\n\nI would love to have a separate \"documentation maintainer\" in the longer\nrun, and it would be great if your tree becomes it.  I can start pulling\nfrom you, forwarding any documentation patches your way.\n\nThanks.\n"},{"id":"109087","messageId":"49C7BA5F.9090600@drmicha.warpmail.net","threadId":"18490","inReplyTo":"7vwsag5hva.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC/WIP 0/2] Documentation clean-up: git commands","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-03-23T16:35:43Z","receivedAt":"2009-03-23T16:35:43Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 23.03.2009 17:22:\n> Michael J Gruber <git@drmicha.warpmail.net> writes:\n> \n>> - Do we want it this way (`git command`)?\n> \n> That's my personal preference but other people may differ; wasn't there an\n> issue with \"man\" backend losing the typesetting information?\n\nSome man readers reconstruct links when they see something like\ngit-add[1], which is why I proposed not changing those for now. A while\nago I introduced a backend specific linkgit macro (git-command for man,\ngit command for others), but that was not so well received.\n\n>> - How to prepare: 1 patch per file/per 5 files/per 50 changes?\n>> - How to submit: single patch once ready or whole series at end (5 years\n>>   from now)?\n>> - How to send: Bother the list or send pull requests only?\n> \n> How about a fork of git.git on repo.or.cz that branches from 1.6.2 and that:\n> \n>  - does not pull from git.git/master unless absoletely necessary; and\n>  - contains only these clean-up changes and nothing else?\n>\n\nWhatever works for you. I have a fork there anyway but would need to\nrebase to 1.6.2 as opposed to next. But somehow we would need to ensure\nthat new Documentation patches don't regress away from the consistent style.\n\n> A bonus point would be for a publically reachable pages rendered out of\n> the tip of this \"documentation updates\" repository, so that people can\n> view it, compare it with www.kernel.org/pub/software/git/docs/.\n\nI didn't plan on changing style, only making the usage of ` and such\nmore consistent. I find these are spotted most conveniently with diff\n--color-words. Do you really think rendered versions are worthwhile for\nthat?\n\n> I would love to have a separate \"documentation maintainer\" in the longer\n> run, and it would be great if your tree becomes it.  I can start pulling\n> from you, forwarding any documentation patches your way.\n> \n> Thanks.\n\nUhm, ohm. Let's see how the quotation and dash thing goes first... I\ndon't want to make promises I can't keep (time-wise).\n\nMichael\n"},{"id":"109112","messageId":"37FD43AD-E43A-4565-8085-95E606E0B868@pobox.com","threadId":"18490","inReplyTo":"7vwsag5hva.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC/WIP 0/2] Documentation clean-up: git commands","fromName":"Chris Johnsen","fromEmail":"chris_johnsen@pobox.com","sentAt":"2009-03-23T23:13:11Z","receivedAt":"2009-03-23T23:13:11Z","isPatch":false,"sender":{"key":"chris_johnsen@pobox.com","avatar":"https://avatars.githubusercontent.com/u/107071?v=4"},"body":"On 2009 Mar 23, at 11:22, Junio C Hamano wrote:\n> Michael J Gruber <git@drmicha.warpmail.net> writes:\n>\n>> - Do we want it this way (`git command`)?\n>\n> That's my personal preference but other people may differ; wasn't  \n> there an\n> issue with \"man\" backend losing the typesetting information?\n\nAn issue that came up recently was that the backticks seem to have no  \ntypeset representation in the official kernel.org manpages.\n\nIn my recent fumbling with the documentation generation, I have often  \nbeen using git-init.txt as a \"test bed\". It shows clearly enough that  \nbackticks, by themselves, are not represented in the official manpages:\n\n$ git grep core/templates Documentation/git-init.txt\n  Documentation/git-init.txt:directory is `/usr/share/git-core/ \ntemplates`.\n\nThere we see the path in backticks with a period outside the  \nbackticks. If any inline typesetting were to come between \"core/ \ntemplates\" and \".\", I think this command would turn it up:\n\n$ git log -p -Score/templates. origin/man -- man1/git-init.1\n\nIt gets two hits. The first where the sentence is introduced, and a  \nsecond where the period is escaped:\n\n43e513c (Autogenerated man pages for v1.5.0-rc1, 2007-01-12)\n2cbdf46 (Autogenerated manpages for v1.5.6.2-212-g08b5, 2008-07-06)\n\nThe last one leaves us with \"core/templates\\.\". So search again to  \nsee if that has changed since the last one:\n\ngit log -p -Score/templates\\\\. origin/man -- man1/git-init.1\n\nNope, that only shows the one hit (2cbdf46). In case I made an error  \nusing the `git log` to do the searching, I also checked by hand by  \nloading the diffs from <http://git.kernel.org/?p=git/ \ngit.git;a=history;f=man1/git-init.1;hb=man> (they agree, no  \nformatting around that path in any of the generated git-init.1).\n\nWhen I generate the manpage on my machine (asciidoc 8.3.1; docbook- \nxsl 1.74.0), I do get some formatting for backticks:\n\n$ grep core/templates Documentation/git-init.1\nProvide the directory from which templates will be used\\&. The  \ndefault template directory is \\FC/usr/share/git\\-core/templates\\F[]\\&.\n\n From what I can tell the \\FC is supposed to introduce monospace type  \nand \\F[] is to reset to the previous type. When I run it through  \ngroff -man -Tps, it  does come out in a monospaced font. The change  \nin font is not obvious when viewing the manpage in a tty-based  \nmanpage viewer (which was my original \"gripe\"), but there is some  \ntypesetting info there for pages I generate.\n\nI suspect the main difference between my generated pages and the  \nofficial pages (at least for typesetting of literal text) is the  \ndocbook-xsl version (though I have not dug into previous versions of  \ndcobook-xsl to bolster this hypothesis).\n\nI have a series of patches prepared to \"cleanup\" and modify  \n{callout,manpage-1.72}.xsl and asciidoc.conf, but I am still running  \na series of \"make doc\" runs across the changes to try to make sure  \nthey are sane. Here is a preview:\n\nDocumentation: move callouts.xsl to manpage-{base,normal}.xsl\nDocumentation: use parametrized manpage-base.xsl with manpage- \n{1.72,normal}.xsl\nDocumentation: rename docbook-xsl-172 attribute to git-asciidoc-no-roff\nDocumentation: move quieting params into manpage-base.xsl\nDocumentation: move \"spurious .sp\" code into manpage-base.xsl\nDocumentation: asciidoc.conf: always use <literallayout> for [blocktext]\nDocumentation: asciidoc.conf: fix verse block with block titles\nDocumentation: option to render literal text as italic for manpages\n\nThe first three restructure things a bit. The next three make some  \ncleanups that could be dropped if they are deemed inappropriate. The  \nlast one add an option that changes the manpage formatting used  \naround asciidoc backticked strings (literal text).\n\nI plan on sending the patches along after my trial doc-generations  \nfinish and I have reviewed the results (my machine is slow, it may  \nnot be until tomorrow).\n\n-- \nChris\n"},{"id":"109153","messageId":"20090324033410.GB12829@coredump.intra.peff.net","threadId":"18490","inReplyTo":"37FD43AD-E43A-4565-8085-95E606E0B868@pobox.com","subject":"Re: [RFC/WIP 0/2] Documentation clean-up: git commands","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-03-24T03:34:11Z","receivedAt":"2009-03-24T03:34:11Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Mar 23, 2009 at 06:13:11PM -0500, Chris Johnsen wrote:\n\n> I have a series of patches prepared to \"cleanup\" and modify  \n> {callout,manpage-1.72}.xsl and asciidoc.conf, but I am still running a \n> series of \"make doc\" runs across the changes to try to make sure they are \n> sane. Here is a preview:\n>\n> Documentation: move callouts.xsl to manpage-{base,normal}.xsl\n> Documentation: use parametrized manpage-base.xsl with manpage- \n> {1.72,normal}.xsl\n> Documentation: rename docbook-xsl-172 attribute to git-asciidoc-no-roff\n> Documentation: move quieting params into manpage-base.xsl\n> Documentation: move \"spurious .sp\" code into manpage-base.xsl\n> Documentation: asciidoc.conf: always use <literallayout> for [blocktext]\n> Documentation: asciidoc.conf: fix verse block with block titles\n> Documentation: option to render literal text as italic for manpages\n\nOh, good, thanks for working on this. I was actually about to start\nlooking at it tonight.\n\nFor the final one, italicized or emphasized text will often end up\nunderlined in most terminals. Peeking at other manpages led me to the\nconclusion that bolding literal text is the most common convention.\n\n-Peff\n"},{"id":"109178","messageId":"49C898BE.4020205@drmicha.warpmail.net","threadId":"18490","inReplyTo":"37FD43AD-E43A-4565-8085-95E606E0B868@pobox.com","subject":"Re: [RFC/WIP 0/2] Documentation clean-up: git commands","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-03-24T08:24:30Z","receivedAt":"2009-03-24T08:24:30Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Chris Johnsen venit, vidit, dixit 24.03.2009 00:13:\n> On 2009 Mar 23, at 11:22, Junio C Hamano wrote:\n>> Michael J Gruber <git@drmicha.warpmail.net> writes:\n>>\n>>> - Do we want it this way (`git command`)?\n>>\n>> That's my personal preference but other people may differ; wasn't  \n>> there an\n>> issue with \"man\" backend losing the typesetting information?\n> \n> An issue that came up recently was that the backticks seem to have no  \n> typeset representation in the official kernel.org manpages.\n\nThe man backend seems to handle ` and ' differently, that's true. But\nthat's an issue of the asciidoc configuration in combination with the\ndocbook stylesheets. In any case, backticks are for commands.\n\nI'm grateful if you look into the asciidoc/docbook issues. We also have\ncompatibility issues going on there between different asciidoc 8\nversions, as well as docbook versions.\n\n> In my recent fumbling with the documentation generation, I have often  \n> been using git-init.txt as a \"test bed\". It shows clearly enough that  \n> backticks, by themselves, are not represented in the official manpages:\n> \n> $ git grep core/templates Documentation/git-init.txt\n>   Documentation/git-init.txt:directory is `/usr/share/git-core/ \n> templates`.\n> \n> There we see the path in backticks with a period outside the  \n> backticks. If any inline typesetting were to come between \"core/ \n> templates\" and \".\", I think this command would turn it up:\n> \n> $ git log -p -Score/templates. origin/man -- man1/git-init.1\n> \n> It gets two hits. The first where the sentence is introduced, and a  \n> second where the period is escaped:\n> \n> 43e513c (Autogenerated man pages for v1.5.0-rc1, 2007-01-12)\n> 2cbdf46 (Autogenerated manpages for v1.5.6.2-212-g08b5, 2008-07-06)\n> \n> The last one leaves us with \"core/templates\\.\". So search again to  \n> see if that has changed since the last one:\n> \n> git log -p -Score/templates\\\\. origin/man -- man1/git-init.1\n> \n> Nope, that only shows the one hit (2cbdf46). In case I made an error  \n> using the `git log` to do the searching, I also checked by hand by  \n> loading the diffs from <http://git.kernel.org/?p=git/ \n> git.git;a=history;f=man1/git-init.1;hb=man> (they agree, no  \n> formatting around that path in any of the generated git-init.1).\n> \n> When I generate the manpage on my machine (asciidoc 8.3.1; docbook- \n> xsl 1.74.0), I do get some formatting for backticks:\n> \n> $ grep core/templates Documentation/git-init.1\n> Provide the directory from which templates will be used\\&. The  \n> default template directory is \\FC/usr/share/git\\-core/templates\\F[]\\&.\n> \n>  From what I can tell the \\FC is supposed to introduce monospace type  \n> and \\F[] is to reset to the previous type. When I run it through  \n> groff -man -Tps, it  does come out in a monospaced font. The change  \n> in font is not obvious when viewing the manpage in a tty-based  \n> manpage viewer (which was my original \"gripe\"), but there is some  \n> typesetting info there for pages I generate.\n> \n> I suspect the main difference between my generated pages and the  \n> official pages (at least for typesetting of literal text) is the  \n> docbook-xsl version (though I have not dug into previous versions of  \n> dcobook-xsl to bolster this hypothesis).\n> \n> I have a series of patches prepared to \"cleanup\" and modify  \n> {callout,manpage-1.72}.xsl and asciidoc.conf, but I am still running  \n> a series of \"make doc\" runs across the changes to try to make sure  \n> they are sane. Here is a preview:\n> \n> Documentation: move callouts.xsl to manpage-{base,normal}.xsl\n> Documentation: use parametrized manpage-base.xsl with manpage- \n> {1.72,normal}.xsl\n> Documentation: rename docbook-xsl-172 attribute to git-asciidoc-no-roff\n> Documentation: move quieting params into manpage-base.xsl\n> Documentation: move \"spurious .sp\" code into manpage-base.xsl\n> Documentation: asciidoc.conf: always use <literallayout> for [blocktext]\n> Documentation: asciidoc.conf: fix verse block with block titles\n> Documentation: option to render literal text as italic for manpages\n> \n> The first three restructure things a bit. The next three make some  \n> cleanups that could be dropped if they are deemed inappropriate. The  \n> last one add an option that changes the manpage formatting used  \n> around asciidoc backticked strings (literal text).\n> \n> I plan on sending the patches along after my trial doc-generations  \n> finish and I have reviewed the results (my machine is slow, it may  \n> not be until tomorrow).\n> \n"}]}