Tweak language, remove lock info from Gemfile doc.

After reviewing, I think the question and answer is a bad fit for the
`gemfile` man page. It does seem like a good fit for the FAQ page on the
Bundler documentation site, though, and I'll add it over there.

2 files changed, 8 insertions, 17 deletions

diff --git a/man/bundle-install.ronn b/man/bundle-install.ronn
index 36144bf4d5..3945371cce 100644
--- a/man/bundle-install.ronn
+++ b/man/bundle-install.ronn
@@ -301,13 +301,14 @@ dependencies again, which will result in different versions of
 third-party code being used if `any` of the gems in the Gemfile(5)
 or any of their dependencies have been updated.
 
-When Bundler first shipped, the `Gemfile.lock` was gitignored inside gems.
-Over time, however, it became clear that this practice forces the pain of
-broken dependencies onto new contributors, while leaving existing contributors
-potentially unaware of the problem. Since `bundle install` is usually the
-first step towards a contribution, the pain of broken dependencies would
-discourage new contributors from contributing. As a result, we have revised our
-guidance for gem authors to now recommend checking in the lock for gems.
+When Bundler first shipped, the `Gemfile.lock` was included in the `.gitignore`
+file included with generated gems.  Over time, however, it became clear that
+this practice forces the pain of broken dependencies onto new contributors,
+while leaving existing contributors potentially unaware of the problem. Since
+`bundle install` is usually the first step towards a contribution, the pain of
+broken dependencies would discourage new contributors from contributing. As a
+result, we have revised our guidance for gem authors to now recommend checking
+in the lock for gems.
 
 ## CONSERVATIVE UPDATING
 
diff --git a/man/gemfile.5.ronn b/man/gemfile.5.ronn
index d8c03b33b6..9baa7f8e3e 100644
--- a/man/gemfile.5.ronn
+++ b/man/gemfile.5.ronn
@@ -504,13 +504,3 @@ bundler uses the following priority order:
      `rubygems.org`
   3. The sources specified via global `source` lines, searching each source in
      your `Gemfile` from last added to first added.
-
-## Should I check my `Gemfile.lock` into version control?
-
-When Bundler first shipped, the `Gemfile.lock` was gitignored inside gems.
-Over time, however, it became clear that this practice forces the pain of
-broken dependencies onto new contributors, while leaving existing contributors
-potentially unaware of the problem. Since `bundle install` is usually the
-first step towards a contribution, the pain of broken dependencies would
-discourage new contributors from contributing. As a result, we have revised our
-guidance for gem authors to now recommend checking in the lock for gems.