Updated broken and outdated URLs

4 files changed, 18 insertions, 18 deletions

diff --git a/googletest/docs/XcodeGuide.md b/googletest/docs/XcodeGuide.md
index 117265c..1c60a33 100644
--- a/googletest/docs/XcodeGuide.md
+++ b/googletest/docs/XcodeGuide.md
@@ -6,7 +6,7 @@ This guide will explain how to use the Google Testing Framework in your Xcode pr
 
 Here is the quick guide for using Google Test in your Xcode project.
 
-  1. Download the source from the [website](http://code.google.com/p/googletest) using this command: `svn checkout http://googletest.googlecode.com/svn/trunk/ googletest-read-only`.
+  1. Download the source from the [website](https://github.com/google/googletest) using this command: `svn checkout http://googletest.googlecode.com/svn/trunk/ googletest-read-only`.
   1. Open up the `gtest.xcodeproj` in the `googletest-read-only/xcode/` directory and build the gtest.framework.
   1. Create a new "Shell Tool" target in your Xcode project called something like "UnitTests".
   1. Add the gtest.framework to your project and add it to the "Link Binary with Libraries" build phase of "UnitTests".
@@ -18,7 +18,7 @@ The following sections further explain each of the steps listed above in depth,
 
 # Get the Source #
 
-Currently, the gtest.framework discussed here isn't available in a tagged release of Google Test, it is only available in the trunk. As explained at the Google Test [site](http://code.google.com/p/googletest/source/checkout">svn), you can get the code from anonymous SVN with this command:
+Currently, the gtest.framework discussed here isn't available in a tagged release of Google Test, it is only available in the trunk. As explained at the Google Test [site](https://github.com/google/googletest), you can get the code from anonymous SVN with this command:
 
 ```
 svn checkout http://googletest.googlecode.com/svn/trunk/ googletest-read-only
@@ -28,7 +28,7 @@ Alternatively, if you are working with Subversion in your own code base, you can
 
 To use `svn:externals`, decide where you would like to have the external source reside. You might choose to put the external source inside the trunk, because you want it to be part of the branch when you make a release. However, keeping it outside the trunk in a version-tagged directory called something like `third-party/googletest/1.0.1`, is another option. Once the location is established, use `svn propedit svn:externals _directory_` to set the svn:externals property on a directory in your repository. This directory won't contain the code, but be its versioned parent directory.
 
-The command `svn propedit` will bring up your Subversion editor, making editing the long, (potentially multi-line) property simpler. This same method can be used to check out a tagged branch, by using the appropriate URL (e.g. `http://googletest.googlecode.com/svn/tags/release-1.0.1`). Additionally, the svn:externals property allows the specification of a particular revision of the trunk with the `-r_##_` option (e.g. `externals/src/googletest -r60 http://googletest.googlecode.com/svn/trunk`).
+The command `svn propedit` will bring up your Subversion editor, making editing the long, (potentially multi-line) property simpler. This same method can be used to check out a tagged branch, by using the appropriate URL (e.g. `https://github.com/google/googletest/releases/tag/release-1.0.1`). Additionally, the svn:externals property allows the specification of a particular revision of the trunk with the `-r_##_` option (e.g. `externals/src/googletest -r60 http://googletest.googlecode.com/svn/trunk`).
 
 Here is an example of using the svn:externals properties on a trunk (read via `svn propget`) of a project. This value checks out a copy of Google Test into the `trunk/externals/src/googletest/` directory.
 
@@ -90,4 +90,4 @@ The Debugger has exited with status 0.
 
 # Summary #
 
-Unit testing is a valuable way to ensure your data model stays valid even during rapid development or refactoring. The Google Testing Framework is a great unit testing framework for C and C++ which integrates well with an Xcode development environment.
\ No newline at end of file
+Unit testing is a valuable way to ensure your data model stays valid even during rapid development or refactoring. The Google Testing Framework is a great unit testing framework for C and C++ which integrates well with an Xcode development environment.
diff --git a/googletest/docs/advanced.md b/googletest/docs/advanced.md
index 6883784..feb8ad6 100644
--- a/googletest/docs/advanced.md
+++ b/googletest/docs/advanced.md
@@ -154,7 +154,7 @@ c is 10
 >     `ASSERT_PRED*` or `EXPECT_PRED*`, please see
 >     [this](faq#OverloadedPredicate) for how to resolve it.
 > 1.  Currently we only provide predicate assertions of arity <= 5. If you need
->     a higher-arity assertion, let [us](http://g/opensource-gtest) know.
+>     a higher-arity assertion, let [us](https://github.com/google/googletest/issues) know.
 
 **Availability**: Linux, Windows, Mac.
 
@@ -382,7 +382,7 @@ Verifies that `val1` is less than, or almost equal to, `val2`. You can replace
 
 ### Asserting Using gMock Matchers
 
-Google-developed C++ mocking framework [gMock](http://go/gmock) comes with a
+Google-developed C++ mocking framework [gMock](../../googlemock) comes with a
 library of matchers for validating arguments passed to mock objects. A gMock
 *matcher* is basically a predicate that knows how to describe itself. It can be
 used in these assertion macros:
@@ -402,17 +402,17 @@ using ::testing::StartsWith;
     EXPECT_THAT(Foo(), StartsWith("Hello"));
 ```
 
-Read this [recipe](http://go/gmockguide#using-matchers-in-gunit-assertions) in
+Read this [recipe](../../googlemock/docs/CookBook.md#using-matchers-in-google-test-assertions) in
 the gMock Cookbook for more details.
 
 gMock has a rich set of matchers. You can do many things googletest cannot do
 alone with them. For a list of matchers gMock provides, read
-[this](http://go/gmockguide#using-matchers). Especially useful among them are
-some [protocol buffer matchers](http://go/protomatchers). It's easy to write
-your [own matchers](http://go/gmockguide#NewMatchers) too.
+[this](../../googlemock/docs/CookBook.md#using-matchers). Especially useful among them are
+some [protocol buffer matchers](https://github.com/google/nucleus/blob/master/nucleus/testing/protocol-buffer-matchers.h). It's easy to write
+your [own matchers](../../googlemock/docs/CookBook.md#writing-new-matchers-quickly) too.
 
 For example, you can use gMock's
-[EqualsProto](http://cs/#piper///depot/google3/testing/base/public/gmock_utils/protocol-buffer-matchers.h)
+[EqualsProto](https://github.com/google/nucleus/blob/master/nucleus/testing/protocol-buffer-matchers.h)
 to compare protos in your tests:
 
 ```c++
@@ -433,7 +433,7 @@ and you're ready to go.
 
 (Please read the [previous](#AssertThat) section first if you haven't.)
 
-You can use the gMock [string matchers](http://go/gmockguide#string-matchers)
+You can use the gMock [string matchers](../../googlemock/docs/CheatSheet.md#string-matchers)
 with `EXPECT_THAT()` or `ASSERT_THAT()` to do more string comparison tricks
 (sub-string, prefix, suffix, regular expression, and etc). For example,
 
diff --git a/googletest/docs/faq.md b/googletest/docs/faq.md
index dad2836..d613f7b 100644
--- a/googletest/docs/faq.md
+++ b/googletest/docs/faq.md
@@ -162,7 +162,7 @@ result, any in-memory side effects they incur are observable in their respective
 sub-processes, but not in the parent process. You can think of them as running
 in a parallel universe, more or less.
 
-In particular, if you use [gMock](http://go/gmock) and the death test statement
+In particular, if you use [gMock](../../googlemock) and the death test statement
 invokes some mock methods, the parent process will think the calls have never
 occurred. Therefore, you may want to move your `EXPECT_CALL` statements inside
 the `EXPECT_DEATH` macro.
@@ -289,7 +289,7 @@ Please make sure you have read [this](advanced.md#how-it-works).
 
 In particular, death tests don't like having multiple threads in the parent
 process. So the first thing you can try is to eliminate creating threads outside
-of `EXPECT_DEATH()`. For example, you may want to use [mocks](http://go/gmock)
+of `EXPECT_DEATH()`. For example, you may want to use [mocks](../../googlemock)
 or fake objects instead of real ones in your tests.
 
 Sometimes this is impossible as some library you must use may be creating
@@ -704,7 +704,7 @@ mistake in production. Such cleverness also leads to
 advise against the practice, and googletest doesn't provide a way to do it.
 
 In general, the recommended way to cause the code to behave differently under
-test is [Dependency Injection](http://go/dependency-injection). You can inject
+test is [Dependency Injection](https://en.wikipedia.org/wiki/Dependency_injection). You can inject
 different functionality from the test and from the production code. Since your
 production code doesn't link in the for-test logic at all (the
 [`testonly`](http://go/testonly) attribute for BUILD targets helps to ensure
diff --git a/googletest/docs/primer.md b/googletest/docs/primer.md
index 260d50b..02dea42 100644
--- a/googletest/docs/primer.md
+++ b/googletest/docs/primer.md
@@ -5,8 +5,8 @@
 
 *googletest* helps you write better C++ tests.
 
-googletest is a testing framework developed by the [Testing
-Technology](http://engdoc/eng/testing/TT/) team with Google's specific
+googletest is a testing framework developed by the Testing
+Technology team with Google's specific
 requirements and constraints in mind. No matter whether you work on Linux,
 Windows, or a Mac, if you write C++ code, googletest can help you. And it
 supports *any* kind of tests, not just unit tests.
@@ -75,7 +75,7 @@ the terms:
 Meaning                                                                              | googletest Term                                                                                            | [ISTQB](http://www.istqb.org/) Term
 :----------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------- | :----------------------------------
 Exercise a particular program path with specific input values and verify the results | [TEST()](#simple-tests)                                                                                    | [Test Case](http://glossary.istqb.org/search/test%20case)
-A set of several tests related to one component                                      | [TestCase](https://g3doc.corp.google.com/third_party/googletest/googletest/g3doc/primer.md#basic-concepts) | [TestSuite](http://glossary.istqb.org/search/test%20suite)
+A set of several tests related to one component                                      | [TestCase](#basic-concepts) | [TestSuite](http://glossary.istqb.org/search/test%20suite)
 
 ## Basic Concepts