Remove Gitlab::Git::Repository#rugged and Gollum code

Cleanup code, and refactor tests that still use Rugged. After this, there should
be no Rugged code that access the instance's repositories on non-test
environments. There is still some rugged code for other tasks like the
repository import task, but since it doesn't access any repository storage path
it can stay.

3 files changed, 3 insertions, 61 deletions

diff --git a/doc/development/diffs.md b/doc/development/diffs.md
index 5e8e8cc7541..c8ced445027 100644
--- a/doc/development/diffs.md
+++ b/doc/development/diffs.md
@@ -2,13 +2,10 @@
 
 Currently we rely on different sources to present diffs, these include:
 
-- Rugged gem
 - Gitaly service
 - Database (through `merge_request_diff_files`)
 - Redis (cached highlighted diffs)
 
-We're constantly moving Rugged calls to Gitaly and the progress can be followed through [Gitaly repo](https://gitlab.com/gitlab-org/gitaly).
-
 ## Architecture overview
 
 ### Merge request diffs
diff --git a/doc/development/gitaly.md b/doc/development/gitaly.md
index f4784c19359..32beafad307 100644
--- a/doc/development/gitaly.md
+++ b/doc/development/gitaly.md
@@ -1,11 +1,7 @@
 # GitLab Developers Guide to Working with Gitaly
 
 [Gitaly](https://gitlab.com/gitlab-org/gitaly) is a high-level Git RPC service used by GitLab CE/EE,
-Workhorse and GitLab-Shell. All Rugged operations in GitLab CE/EE are currently being phased out to
-be replaced by Gitaly API calls.
-
-Visit the [Gitaly Migration Board](https://gitlab.com/gitlab-org/gitaly/boards/331341) for current
-status of the migration.
+Workhorse and GitLab-Shell.
 
 ## Developing new Git features
 
@@ -52,57 +48,6 @@ comfortable writing Go code.
 There is documentation for this approach in [the Gitaly
 repo](https://gitlab.com/gitlab-org/gitaly/blob/master/doc/ruby_endpoint.md).
 
-## Modifying existing Git features
-
-If you modify existing Git features in `lib/gitlab/git` you need to make
-sure the changes also work in Gitaly. Because we are still in the
-migration process there are a number of subtle pitfalls. Features that
-have been migrated have dual implementations (Gitaly and local). The
-Gitaly implementation may or may not use a vendored (and therefore
-possibly outdated) copy of the local implementation in `lib/gitlab/git`.
-
-To avoid unexpected problems and conflicts, all changes to
-`lib/gitlab/git` need to be approved by a member of the Gitaly team.
-
-For the time being, while the Gitaly migration is still in progress,
-there should be no Enterprise Edition-only Git code in
-`lib/gitlab/git`. Also no mixins.
-
-## Feature Flags
-
-Gitaly makes heavy use of [feature flags](feature_flags.md).
-
-Each Rugged-to-Gitaly migration goes through a [series of phases](https://gitlab.com/gitlab-org/gitaly/blob/master/doc/MIGRATION_PROCESS.md):
-
-* **Opt-In**: by default the Rugged implementation is used.
-  * Production instances can choose to enable the Gitaly endpoint by enabling the feature flag.
-  * For testing purposes, you may wish to enable all feature flags by default. This can be done by exporting the following
-    environment variable: `GITALY_FEATURE_DEFAULT_ON=1`.
-  * On developer instances (ie, when `Rails.env.development?` is true), the Gitaly endpoint
-    is enabled by default, but can be _disabled_ using feature flags.
-* **Opt-Out**: by default, the Gitaly endpoint is used, but the feature can be explicitly disabled using the feature flag.
-* **Mandatory**: The migration is complete and cannot be disabled. The old codepath is removed.
-
-### Enabling and Disabling Feature
-
-In the Rails console, type:
-
-```ruby
-Feature.enable(:gitaly_feature_name)
-Feature.disable(:gitaly_feature_name)
-```
-
-Where `gitaly_feature_name` is the name of the Gitaly feature. This can be determined by finding the appropriate
-`gitaly_migrate` code block, for example:
-
-```ruby
-gitaly_migrate(:tag_names) do
-...
-end
-```
-
-Since Gitaly features are always prefixed with `gitaly_`, the name of the feature flag in this case would be `gitaly_tag_names`.
-
 ## Gitaly-Related Test Failures
 
 If your test-suite is failing with Gitaly issues, as a first step, try running:
diff --git a/doc/development/instrumentation.md b/doc/development/instrumentation.md
index a14c0752366..7761f65d78a 100644
--- a/doc/development/instrumentation.md
+++ b/doc/development/instrumentation.md
@@ -69,7 +69,7 @@ The easiest way to check if a method has been instrumented is to check its
 source location. For example:
 
 ```ruby
-method = Rugged::TagCollection.instance_method(:[])
+method = Banzai::Renderer.method(:render)
 
 method.source_location
 ```
@@ -82,7 +82,7 @@ method (along with its source location), this is easier than running the above
 Ruby code. In case of the above snippet you'd run the following:
 
 ```
-$ Rugged::TagCollection#[]
+$ Banzai::Renderer.render
 ```
 
 This will print out something along the lines of: