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.

1 files changed, 1 insertions, 56 deletions

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: