Merge pull request #1076 from rpjday/maintaining

maintaining.asc: standardize on "--" for em dashes, add italics

Author: ben

book/05-distributed-git/sections/maintaining.asc

@@ -8,10 +8,10 @@ Whether you maintain a canonical repository or want to help by verifying or appr
 ==== Working in Topic Branches
 
 (((branches, topic)))
-When you're thinking of integrating new work, it's generally a good idea to try it out in a topic branch – a temporary branch specifically made to try out that new work.
+When you're thinking of integrating new work, it's generally a good idea to try it out in a _topic branch_ -- a temporary branch specifically made to try out that new work.
 This way, it's easy to tweak a patch individually and leave it if it's not working until you have time to come back to it.
 If you create a simple branch name based on the theme of the work you're going to try, such as `ruby_client` or something similarly descriptive, you can easily remember it if you have to abandon it for a while and come back later.
-The maintainer of the Git project tends to namespace these branches as well – such as `sc/ruby_client`, where `sc` is short for the person who contributed the work.
+The maintainer of the Git project tends to namespace these branches as well -- such as `sc/ruby_client`, where `sc` is short for the person who contributed the work.
 As you'll remember, you can create the branch based off your `master` branch like this:
 
 [source,console]
@@ -51,9 +51,9 @@ It's almost identical to running a `patch -p1` command to apply the patch, altho
 It also handles file adds, deletes, and renames if they're described in the `git diff` format, which `patch` won't do.
 Finally, `git apply` is an ``apply all or abort all'' model where either everything is applied or nothing is, whereas `patch` can partially apply patchfiles, leaving your working directory in a weird state.
 `git apply` is overall much more conservative than `patch`.
-It won't create a commit for you – after running it, you must stage and commit the changes introduced manually.
+It won't create a commit for you -- after running it, you must stage and commit the changes introduced manually.
 
-You can also use `git apply` to see if a patch applies cleanly before you try actually applying it – you can run `git apply --check` with the patch:
+You can also use `git apply` to see if a patch applies cleanly before you try actually applying it -- you can run `git apply --check` with the patch:
 
 [source,console]
 ----
@@ -137,7 +137,7 @@ To restore the original branch and stop patching run "git am --abort".
 ----
 
 This command puts conflict markers in any files it has issues with, much like a conflicted merge or rebase operation.
-You solve this issue much the same way – edit the file to resolve the conflict, stage the new file, and then run `git am --resolved` to continue to the next patch:
+You solve this issue much the same way -- edit the file to resolve the conflict, stage the new file, and then run `git am --resolved` to continue to the next patch:
 
 [source,console]
 ----
@@ -149,7 +149,7 @@ Applying: seeing if this helps the gem
 
 If you want Git to try a bit more intelligently to resolve the conflict, you can pass a `-3` option to it, which makes Git attempt a three-way merge.
 This option isn't on by default because it doesn't work if the commit the patch says it was based on isn't in your repository.
-If you do have that commit – if the patch was based on a public commit – then the `-3` option is generally much smarter about applying a conflicting patch:
+If you do have that commit -- if the patch was based on a public commit -- then the `-3` option is generally much smarter about applying a conflicting patch:
 
 [source,console]
 ----
@@ -201,7 +201,7 @@ If she emails you again later with another branch containing another great featu
 This is most useful if you're working with a person consistently.
 If someone only has a single patch to contribute once in a while, then accepting it over email may be less time consuming than requiring everyone to run their own server and having to continually add and remove remotes to get a few patches.
 You're also unlikely to want to have hundreds of remotes, each for someone who contributes only a patch or two.
-However, scripts and hosted services may make this easier – it depends largely on how you develop and how your contributors develop.
+However, scripts and hosted services may make this easier -- it depends largely on how you develop and how your contributors develop.
 
 The other advantage of this approach is that you get the history of the commits as well.
 Although you may have legitimate merge issues, you know where in your history their work is based; a proper three-way merge is the default rather than having to supply a `-3` and hope the patch was generated off a public commit to which you have access.
@@ -406,7 +406,7 @@ Now you can remove your topic branch and drop the commits you didn't want to pul
 (((git commands, rerere)))(((rerere)))
 If you're doing lots of merging and rebasing, or you're maintaining a long-lived topic branch, Git has a feature called ``rerere'' that can help.
 
-Rerere stands for ``reuse recorded resolution'' – it's a way of shortcutting manual conflict resolution.
+Rerere stands for ``reuse recorded resolution'' -- it's a way of shortcutting manual conflict resolution.
 When rerere is enabled, Git will keep a set of pre- and post-images from successful merges, and if it notices that there's a conflict that looks exactly like one you've already fixed, it'll just use the fix from last time, without bothering you with it.
 
 This feature comes in two parts: a configuration setting and a command.