Fix man page links

With markup

    [`bundle platform(1)`][bundle-platform(1)]

ronn creates this HTML fragment

    <dt><a href="bundle-platform.html"><code>bundle platform(1)</code></a></dt><dd><p>Display platform compatibility information</p></dd>

At the same time, it generates HTML file `bundle-platform.1.html` based on the
man page section, and this results in certain inter-man-page links 404.

We resolve this inconsistency by spelling out the href attributes.

1 files changed, 8 insertions, 8 deletions

diff --git a/man/bundle-update.ronn b/man/bundle-update.ronn
index 493986a7a4..2ad678f424 100644
--- a/man/bundle-update.ronn
+++ b/man/bundle-update.ronn
@@ -21,7 +21,7 @@ bundle-update(1) -- Update your gems to the latest available versions
 
 Update the gems specified (all gems, if `--all` flag is used), ignoring
 the previously installed gems specified in the `Gemfile.lock`. In
-general, you should use [bundle install(1)][bundle-install(1)] to install the same exact
+general, you should use [bundle install(1)](bundle-install.1.html) to install the same exact
 gems and versions across machines.
 
 You would use `bundle update` to explicitly update the version of a
@@ -95,7 +95,7 @@ Consider the following Gemfile(5):
     gem "rails", "3.0.0.rc"
     gem "nokogiri"
 
-When you run [bundle install(1)][bundle-install(1)] the first time, bundler will resolve
+When you run [bundle install(1)](bundle-install.1.html) the first time, bundler will resolve
 all of the dependencies, all the way down, and install what you need:
 
     Fetching gem metadata from https://rubygems.org/.........
@@ -132,11 +132,11 @@ all of the dependencies, all the way down, and install what you need:
 
 As you can see, even though you have two gems in the Gemfile(5), your application
 needs 26 different gems in order to run. Bundler remembers the exact versions
-it installed in `Gemfile.lock`. The next time you run [bundle install(1)][bundle-install(1)], bundler skips
+it installed in `Gemfile.lock`. The next time you run [bundle install(1)](bundle-install.1.html), bundler skips
 the dependency resolution and installs the same gems as it installed last time.
 
 After checking in the `Gemfile.lock` into version control and cloning it on another
-machine, running [bundle install(1)][bundle-install(1)] will _still_ install the gems that you installed
+machine, running [bundle install(1)](bundle-install.1.html) will _still_ install the gems that you installed
 last time. You don't need to worry that a new release of `erubis` or `mail` changes
 the gems you use.
 
@@ -196,12 +196,12 @@ update all dependencies of that gem, including those that are also dependencies
 of another gem.
 
 To prevent updating shared dependencies, prior to version 1.14 the only option
-was the `CONSERVATIVE UPDATING` behavior in [bundle install(1)][bundle-install(1)]:
+was the `CONSERVATIVE UPDATING` behavior in [bundle install(1)](bundle-install.1.html):
 
 In this scenario, updating the `thin` version manually in the Gemfile(5),
-and then running [bundle install(1)][bundle-install(1)] will only update `daemons` and `eventmachine`,
+and then running [bundle install(1)](bundle-install.1.html) will only update `daemons` and `eventmachine`,
 but not `rack`. For more information, see the `CONSERVATIVE UPDATING` section
-of [bundle install(1)][bundle-install(1)].
+of [bundle install(1)](bundle-install.1.html).
 
 Starting with 1.14, specifying the `--conservative` option will also prevent shared
 dependencies from being updated.
@@ -339,7 +339,7 @@ use the following workflow:
 
     $ git add Gemfile.lock
 
-* If [bundle install(1)][bundle-install(1)] reports a conflict, manually update the specific
+* If [bundle install(1)](bundle-install.1.html) reports a conflict, manually update the specific
   gems that you changed in the Gemfile(5)
 
     $ bundle update rails thin