[NON-PATCH 3/2] Documentation/git-merge: format full commands in typewriter font

From: Thomas Rast <trast@student.ethz.ch>
Date: Jan 7, 2010, 17:03 UTC
Message-ID: <ebbb4e2b0e98490a64b3cd52c33d3a995fa7e980.1262883414.git.trast@student.ethz.ch>
In-Reply-To: <2e53c91e536e1ff585bc7464c1b8863e6cc45c45.1262883414.git.trast@student.ethz.ch>

Use `code snippet` style instead of 'emphasis' for the full commands specified in the "how to resolve conflicts" section.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---

Not intended for application, but for discussion.

I originally wanted to tack this on the series as an "obvious cleanup", but then I noticed two things:

* While the general trend as per

    git grep '`git '
    git grep \''git '

  seems to go towards the `code` style where full commands are
  concerned, and the 'emphasis' where only a git-command is named,
  this is not consistent yet.  Especially the git-svn manpage seems to
  have a few hybrids.

* More importantly, while `code` style seems to be an improvement in
  HTML output (because it gives typewriter font), my local 'man'
  renders 'emphasis' as underlines -- which actually makes the code
  snippets much more visible than `literal` quotes which are not
  rendered specially at all.

So which way should it be changed?

 Documentation/git-merge.txt |   14 +++++++-------
 1 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index b224daf..e04c800 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -193,7 +193,7 @@ After seeing a conflict, you can do two things:
 
  * Decide not to merge.  The only clean-ups you need are to reset
    the index file to the `HEAD` commit to reverse 2. and to clean
-   up working tree changes made by 2. and 3.; 'git-reset --hard' can
+   up working tree changes made by 2. and 3.; `git-reset --hard` can
    be used for this.
 
  * Resolve the conflicts.  Git will mark the conflicts in
@@ -202,19 +202,19 @@ After seeing a conflict, you can do two things:
 
 You can work through the conflict with a number of tools:
 
- * Use a mergetool.  'git mergetool' to launch a graphical
+ * Use a mergetool.  `git mergetool` to launch a graphical
    mergetool which will work you through the merge.
 
- * Look at the diffs.  'git diff' will show a three-way diff,
+ * Look at the diffs.  `git diff` will show a three-way diff,
    highlighting changes from both the HEAD and 'theirs' versions.
 
- * Look at the diffs on their own. 'git log --merge -p <path>'
+ * Look at the diffs on their own. `git log --merge -p <path>`
    will show diffs first for the HEAD version and then the
    'theirs' version.
 
- * Look at the originals.  'git show :1:filename' shows the
-   common ancestor, 'git show :2:filename' shows the HEAD
-   version and 'git show :3:filename' shows 'their' version.
+ * Look at the originals.  `git show :1:filename` shows the
+   common ancestor, `git show :2:filename` shows the HEAD
+   version and `git show :3:filename` shows 'their' version.
 
 
 EXAMPLES

-- 
1.6.6.202.gdf32a