6 files changed, 23 insertions, 147 deletions
diff --git a/googlemock/docs/CheatSheet.md b/googlemock/docs/CheatSheet.md
index ef4451b8..c6367fdd 100644
--- a/googlemock/docs/CheatSheet.md
+++ b/googlemock/docs/CheatSheet.md
@@ -65,7 +65,7 @@ can specify it by appending `_WITH_CALLTYPE` to any of the macros
 described in the previous two sections and supplying the calling
 convention as the first argument to the macro. For example,
 ```
-  MOCK_METHOD_1_WITH_CALLTYPE(STDMETHODCALLTYPE, Foo, bool(int n));
+  MOCK_METHOD1_WITH_CALLTYPE(STDMETHODCALLTYPE, Foo, bool(int n));
   MOCK_CONST_METHOD2_WITH_CALLTYPE(STDMETHODCALLTYPE, Bar, int(double x, double y));
 ```
 where `STDMETHODCALLTYPE` is defined by `<objbase.h>` on Windows.
@@ -249,7 +249,7 @@ match them more flexibly, or get more informative messages, you can use:
 | `SizeIs(m)`              | `argument` is a container whose size matches `m`. E.g. `SizeIs(2)` or `SizeIs(Lt(2))`.                                           |
 | `UnorderedElementsAre(e0, e1, ..., en)` | `argument` has `n + 1` elements, and under some permutation each element matches an `ei` (for a different `i`), which can be a value or a matcher. 0 to 10 arguments are allowed. |
 | `UnorderedElementsAreArray({ e0, e1, ..., en })`, `UnorderedElementsAreArray(array)`, or `UnorderedElementsAreArray(array, count)` | The same as `UnorderedElementsAre()` except that the expected element values/matchers come from an initializer list, STL-style container, or C-style array. |
-| `WhenSorted(m)`          | When `argument` is sorted using the `<` operator, it matches container matcher `m`. E.g. `WhenSorted(UnorderedElementsAre(1, 2, 3))` verifies that `argument` contains elements `1`, `2`, and `3`, ignoring order. |
+| `WhenSorted(m)`          | When `argument` is sorted using the `<` operator, it matches container matcher `m`. E.g. `WhenSorted(ElementsAre(1, 2, 3))` verifies that `argument` contains elements `1`, `2`, and `3`, ignoring order. |
 | `WhenSortedBy(comparator, m)` | The same as `WhenSorted(m)`, except that the given comparator instead of `<` is used to sort `argument`. E.g. `WhenSortedBy(std::greater<int>(), ElementsAre(3, 2, 1))`. |
 
 Notes:
diff --git a/googlemock/docs/CookBook.md b/googlemock/docs/CookBook.md
index 6ea7f3a9..3d07e68b 100644
--- a/googlemock/docs/CookBook.md
+++ b/googlemock/docs/CookBook.md
@@ -148,7 +148,7 @@ Note that the mock class doesn't define `AppendPacket()`, unlike the
 real class. That's fine as long as the test doesn't need to call it.
 
 Next, you need a way to say that you want to use
-`ConcretePacketStream` in production code, and use `MockPacketStream`
+`ConcretePacketStream` in production code and to use `MockPacketStream`
 in tests.  Since the functions are not virtual and the two classes are
 unrelated, you must specify your choice at _compile time_ (as opposed
 to run time).
@@ -227,7 +227,7 @@ If a mock method has no `EXPECT_CALL` spec but is called, Google Mock
 will print a warning about the "uninteresting call". The rationale is:
 
   * New methods may be added to an interface after a test is written. We shouldn't fail a test just because a method it doesn't know about is called.
-  * However, this may also mean there's a bug in the test, so Google Mock shouldn't be silent either. If the user believes these calls are harmless, he can add an `EXPECT_CALL()` to suppress the warning.
+  * However, this may also mean there's a bug in the test, so Google Mock shouldn't be silent either. If the user believes these calls are harmless, they can add an `EXPECT_CALL()` to suppress the warning.
 
 However, sometimes you may want to suppress all "uninteresting call"
 warnings, while sometimes you may want the opposite, i.e. to treat all
@@ -706,7 +706,7 @@ type `m` accepts):
   1. When both `T` and `U` are built-in arithmetic types (`bool`, integers, and floating-point numbers), the conversion from `T` to `U` is not lossy (in other words, any value representable by `T` can also be represented by `U`); and
   1. When `U` is a reference, `T` must also be a reference (as the underlying matcher may be interested in the address of the `U` value).
 
-The code won't compile if any of these conditions isn't met.
+The code won't compile if any of these conditions aren't met.
 
 Here's one example:
 
diff --git a/googlemock/docs/DevGuide.md b/googlemock/docs/DevGuide.md
deleted file mode 100644
index adb74fe1..00000000
--- a/googlemock/docs/DevGuide.md
+++ /dev/null
@@ -1,132 +0,0 @@
-
-
-If you are interested in understanding the internals of Google Mock,
-building from source, or contributing ideas or modifications to the
-project, then this document is for you.
-
-# Introduction #
-
-First, let's give you some background of the project.
-
-## Licensing ##
-
-All Google Mock source and pre-built packages are provided under the [New BSD License](http://www.opensource.org/licenses/bsd-license.php).
-
-## The Google Mock Community ##
-
-The Google Mock community exists primarily through the [discussion group](http://groups.google.com/group/googlemock), the
-[issue tracker](https://github.com/google/googletest/issues) and, to a lesser extent, the [source control repository](../). You are definitely encouraged to contribute to the
-discussion and you can also help us to keep the effectiveness of the
-group high by following and promoting the guidelines listed here.
-
-### Please Be Friendly ###
-
-Showing courtesy and respect to others is a vital part of the Google
-culture, and we strongly encourage everyone participating in Google
-Mock development to join us in accepting nothing less. Of course,
-being courteous is not the same as failing to constructively disagree
-with each other, but it does mean that we should be respectful of each
-other when enumerating the 42 technical reasons that a particular
-proposal may not be the best choice. There's never a reason to be
-antagonistic or dismissive toward anyone who is sincerely trying to
-contribute to a discussion.
-
-Sure, C++ testing is serious business and all that, but it's also
-a lot of fun. Let's keep it that way. Let's strive to be one of the
-friendliest communities in all of open source.
-
-### Where to Discuss Google Mock ###
-
-As always, discuss Google Mock in the official [Google C++ Mocking Framework discussion group](http://groups.google.com/group/googlemock).  You don't have to actually submit
-code in order to sign up. Your participation itself is a valuable
-contribution.
-
-# Working with the Code #
-
-If you want to get your hands dirty with the code inside Google Mock,
-this is the section for you.
-
-## Checking Out the Source from Subversion ##
-
-Checking out the Google Mock source is most useful if you plan to
-tweak it yourself.  You check out the source for Google Mock using a
-[Subversion](http://subversion.tigris.org/) client as you would for any
-other project hosted on Google Code.  Please see the instruction on
-the [source code access page](../) for how to do it.
-
-## Compiling from Source ##
-
-Once you check out the code, you can find instructions on how to
-compile it in the [README](../README.md) file.
-
-## Testing ##
-
-A mocking framework is of no good if itself is not thoroughly tested.
-Tests should be written for any new code, and changes should be
-verified to not break existing tests before they are submitted for
-review. To perform the tests, follow the instructions in [README](http://code.google.com/p/googlemock/source/browse/trunk/README) and
-verify that there are no failures.
-
-# Contributing Code #
-
-We are excited that Google Mock is now open source, and hope to get
-great patches from the community. Before you fire up your favorite IDE
-and begin hammering away at that new feature, though, please take the
-time to read this section and understand the process. While it seems
-rigorous, we want to keep a high standard of quality in the code
-base.
-
-## Contributor License Agreements ##
-
-You must sign a Contributor License Agreement (CLA) before we can
-accept any code.  The CLA protects you and us.
-
-  * If you are an individual writing original source code and you're sure you own the intellectual property, then you'll need to sign an [individual CLA](http://code.google.com/legal/individual-cla-v1.0.html).
-  * If you work for a company that wants to allow you to contribute your work to Google Mock, then you'll need to sign a [corporate CLA](http://code.google.com/legal/corporate-cla-v1.0.html).
-
-Follow either of the two links above to access the appropriate CLA and
-instructions for how to sign and return it.
-
-## Coding Style ##
-
-To keep the source consistent, readable, diffable and easy to merge,
-we use a fairly rigid coding style, as defined by the [google-styleguide](https://github.com/google/styleguide) project.  All patches will be expected
-to conform to the style outlined [here](https://google.github.io/styleguide/cppguide.html).
-
-## Submitting Patches ##
-
-Please do submit code. Here's what you need to do:
-
-  1. Normally you should make your change against the SVN trunk instead of a branch or a tag, as the latter two are for release control and should be treated mostly as read-only.
-  1. Decide which code you want to submit. A submission should be a set of changes that addresses one issue in the [Google Mock issue tracker](http://code.google.com/p/googlemock/issues/list). Please don't mix more than one logical change per submittal, because it makes the history hard to follow. If you want to make a change that doesn't have a corresponding issue in the issue tracker, please create one.
-  1. Also, coordinate with team members that are listed on the issue in question. This ensures that work isn't being duplicated and communicating your plan early also generally leads to better patches.
-  1. Ensure that your code adheres to the [Google Mock source code style](#Coding_Style.md).
-  1. Ensure that there are unit tests for your code.
-  1. Sign a Contributor License Agreement.
-  1. Create a patch file using `svn diff`.
-  1. We use [Rietveld](http://codereview.appspot.com/) to do web-based code reviews.  You can read about the tool [here](https://github.com/rietveld-codereview/rietveld/wiki).  When you are ready, upload your patch via Rietveld and notify `googlemock@googlegroups.com` to review it.  There are several ways to upload the patch.  We recommend using the [upload\_gmock.py](../scripts/upload_gmock.py) script, which you can find in the `scripts/` folder in the SVN trunk.
-
-## Google Mock Committers ##
-
-The current members of the Google Mock engineering team are the only
-committers at present. In the great tradition of eating one's own
-dogfood, we will be requiring each new Google Mock engineering team
-member to earn the right to become a committer by following the
-procedures in this document, writing consistently great code, and
-demonstrating repeatedly that he or she truly gets the zen of Google
-Mock.
-
-# Release Process #
-
-We follow the typical release process for Subversion-based projects:
-
-  1. A release branch named `release-X.Y` is created.
-  1. Bugs are fixed and features are added in trunk; those individual patches are merged into the release branch until it's stable.
-  1. An individual point release (the `Z` in `X.Y.Z`) is made by creating a tag from the branch.
-  1. Repeat steps 2 and 3 throughout one release cycle (as determined by features or time).
-  1. Go back to step 1 to create another release branch and so on.
-
-
----
-
-This page is based on the [Making GWT Better](http://code.google.com/webtoolkit/makinggwtbetter.html) guide from the [Google Web Toolkit](http://code.google.com/webtoolkit/) project.  Except as otherwise [noted](http://code.google.com/policies.html#restrictions), the content of this page is licensed under the [Creative Commons Attribution 2.5 License](http://creativecommons.org/licenses/by/2.5/).
diff --git a/googlemock/docs/Documentation.md b/googlemock/docs/Documentation.md
index a0311871..16083e70 100644
--- a/googlemock/docs/Documentation.md
+++ b/googlemock/docs/Documentation.md
@@ -11,5 +11,5 @@ the respective git branch/tag).**
 
 To contribute code to Google Mock, read:
 
-  * [DevGuide](DevGuide.md) -- read this _before_ writing your first patch.
+  * [CONTRIBUTING](../CONTRIBUTING.md) -- read this _before_ writing your first patch.
   * [Pump Manual](../../googletest/docs/PumpManual.md) -- how we generate some of Google Mock's source files.
diff --git a/googlemock/docs/ForDummies.md b/googlemock/docs/ForDummies.md
index 0bf528e9..76910569 100644
--- a/googlemock/docs/ForDummies.md
+++ b/googlemock/docs/ForDummies.md
@@ -217,7 +217,8 @@ The macro can be followed by some optional _clauses_ that provide more informati
 This syntax is designed to make an expectation read like English. For example, you can probably guess that
 
 ```
-using ::testing::Return;...
+using ::testing::Return;
+...
 EXPECT_CALL(turtle, GetX())
     .Times(5)
     .WillOnce(Return(100))
@@ -251,7 +252,8 @@ EXPECT_CALL(turtle, Forward(_));
 A list of built-in matchers can be found in the [CheatSheet](CheatSheet.md). For example, here's the `Ge` (greater than or equal) matcher:
 
 ```
-using ::testing::Ge;...
+using ::testing::Ge;
+...
 EXPECT_CALL(turtle, Forward(Ge(100)));
 ```
 
@@ -280,7 +282,8 @@ First, if the return type of a mock function is a built-in type or a pointer, th
 Second, if a mock function doesn't have a default action, or the default action doesn't suit you, you can specify the action to be taken each time the expectation matches using a series of `WillOnce()` clauses followed by an optional `WillRepeatedly()`. For example,
 
 ```
-using ::testing::Return;...
+using ::testing::Return;
+...
 EXPECT_CALL(turtle, GetX())
     .WillOnce(Return(100))
     .WillOnce(Return(200))
@@ -290,7 +293,8 @@ EXPECT_CALL(turtle, GetX())
 This says that `turtle.GetX()` will be called _exactly three times_ (Google Mock inferred this from how many `WillOnce()` clauses we've written, since we didn't explicitly write `Times()`), and will return 100, 200, and 300 respectively.
 
 ```
-using ::testing::Return;...
+using ::testing::Return;
+...
 EXPECT_CALL(turtle, GetY())
     .WillOnce(Return(100))
     .WillOnce(Return(200))
@@ -317,7 +321,8 @@ Instead of returning 100, 101, 102, ..., consecutively, this mock function will
 Time for another quiz! What do you think the following means?
 
 ```
-using ::testing::Return;...
+using ::testing::Return;
+...
 EXPECT_CALL(turtle, GetY())
 .Times(4)
 .WillOnce(Return(100));
@@ -331,7 +336,8 @@ So far we've only shown examples where you have a single expectation. More reali
 By default, when a mock method is invoked, Google Mock will search the expectations in the **reverse order** they are defined, and stop when an active expectation that matches the arguments is found (you can think of it as "newer rules override older ones."). If the matching expectation cannot take any more calls, you will get an upper-bound-violated failure. Here's an example:
 
 ```
-using ::testing::_;...
+using ::testing::_;
+...
 EXPECT_CALL(turtle, Forward(_));  // #1
 EXPECT_CALL(turtle, Forward(10))  // #2
     .Times(2);
@@ -347,7 +353,8 @@ By default, an expectation can match a call even though an earlier expectation h
 Sometimes, you may want all the expected calls to occur in a strict order. To say this in Google Mock is easy:
 
 ```
-using ::testing::InSequence;...
+using ::testing::InSequence;
+...
 TEST(FooTest, DrawsLineSegment) {
   ...
   {
@@ -373,7 +380,8 @@ Now let's do a quick quiz to see how well you can use this mock stuff already. H
 After you've come up with your answer, take a look at ours and compare notes (solve it yourself first - don't cheat!):
 
 ```
-using ::testing::_;...
+using ::testing::_;
+...
 EXPECT_CALL(turtle, GoTo(_, _))  // #1
     .Times(AnyNumber());
 EXPECT_CALL(turtle, GoTo(0, 0))  // #2
diff --git a/googlemock/docs/FrequentlyAskedQuestions.md b/googlemock/docs/FrequentlyAskedQuestions.md
index 5eac83f4..ccaa3d7a 100644
--- a/googlemock/docs/FrequentlyAskedQuestions.md
+++ b/googlemock/docs/FrequentlyAskedQuestions.md
@@ -240,7 +240,7 @@ You cannot mock a variadic function (i.e. a function taking ellipsis
 The problem is that in general, there is _no way_ for a mock object to
 know how many arguments are passed to the variadic method, and what
 the arguments' types are.  Only the _author of the base class_ knows
-the protocol, and we cannot look into his head.
+the protocol, and we cannot look into their head.
 
 Therefore, to mock such a function, the _user_ must teach the mock
 object how to figure out the number of arguments and their types.  One