Removed references to gitosis.

Author: mboersma

README.md

@@ -60,7 +60,6 @@ Deis stands on the shoulders of leading open source technologies:
   * [Celery](http://www.celeryproject.org/)
   * [Heroku Buildpacks](https://devcenter.heroku.com/articles/buildpacks)
   * [Slugbuilder](https://github.com/flynn/slugbuilder) and [slugrunner](https://github.com/flynn/slugrunner)
-  * [Gitosis](https://github.com/opdemand/gitosis)
 
 ## License
 

cm/mock.py

@@ -59,7 +59,6 @@ def run_node(node, command):
 drwx------  2 deis deis 4096 Dec 21 10:08 .cache
 drwx------  2 deis deis 4096 Dec 21 10:00 .chef
 drwxr-xr-x 15 deis deis 4096 Dec 21 10:09 controller
-drwxr-xr-x  8 git  git  4096 Dec 21 10:14 gitosis
 -rw-r--r--  1 root root    0 Dec 21 10:00 prevent-apt-update
 -rw-r--r--  1 deis deis  675 Mar 28  2013 .profile
 drwxr-xr-x  2 deis deis 4096 Dec 21 10:07 .ssh

docs/components/controller.rst

@@ -9,10 +9,10 @@ Controller
 The controller is the "brains" of the Deis platform.
 The controller manages container :ref:`Formations <formation>`,
 comprised of clusters of nodes providing proxy and runtime services for
-the application platform.  A single controller manages multiple 
+the application platform.  A single controller manages multiple
 container formations.
 
-Controllers are tied to a configuration management backend (typically a 
+Controllers are tied to a configuration management backend (typically a
 Chef Server) where data about users, applications and formations is stored.
 
 The controller is in charge of:
@@ -28,8 +28,8 @@ The controller stack includes:
 * Django API Server for handling API calls
 * PostgreSQL database as a backing store for Django
 * Celery / RabbitMQ for dispatching tasks
-* Gitosis to handle access control for Git Push over SSH
+* A lightweight *gitreceive* hook for ``git push`` access control
 * Docker and Buildstep to process Heroku Buildpacks
 
 Follow the :ref:`Operations Guide <operations>` to setup your own private
-Deis controller.
+Deis controller.

docs/contributing/releases.rst

@@ -21,10 +21,7 @@ GitHub Issues
 Other Repos
 -----------
 
-- tag the opdemand/gitosis repo
-    * ``git checkout master``
-    * ``git tag vX.Y.Z``
-    * ``git push --tags origin vX.Y.Z``
+- TBD
 
 
 Chef Repo

docs/gettingstarted/concepts.rst

@@ -7,7 +7,7 @@
 Concepts
 ========
 
-Deis is an application platform that deploys and scales `Twelve Factor`_ apps 
+Deis is an application platform that deploys and scales `Twelve Factor`_ apps
 using formations of `Chef`_ nodes, `Docker`_ containers and `Nginx`_ proxies.
 
 Formations
@@ -18,69 +18,69 @@ that provide different services to the formation.
 
 Layers
 ------
-:ref:`Layers <layer>` are homogeneous groups of :ref:`Nodes <node>` that 
-perform work on behalf of a formation.  Each node in a layer has 
+:ref:`Layers <layer>` are homogeneous groups of :ref:`Nodes <node>` that
+perform work on behalf of a formation.  Each node in a layer has
 the same :ref:`Flavor` and configuration, allowing them to be scaled
 easily.  Formations have two primary types of layers.
 
 Runtime Layers
 ^^^^^^^^^^^^^^
 Runtime layers host :ref:`Containers <container>` for a formation.
-Nodes in a runtime layer use a `Chef Databag`_ to deploy containers for 
+Nodes in a runtime layer use a `Chef Databag`_ to deploy containers for
 each :ref:`application` in the formation.
 
 Proxy Layers
 ^^^^^^^^^^^^
 Proxy layers expose :ref:`Applications <application>` to the outside world.
-Nodes in a proxy layer use a `Chef Databag`_ to configure routing of 
+Nodes in a proxy layer use a `Chef Databag`_ to configure routing of
 inbound requests to :ref:`Containers <container>` hosted on runtime layers.
 
 Applications
 ------------
-An :ref:`application` lives on a :ref:`formation` where it uses 
+An :ref:`application` lives on a :ref:`formation` where it uses
 :ref:`Containers <container>` to process requests and run background jobs
 for a deployed git repository.
 Developers use :ref:`Applications <application>` to push code, change config,
 scale containers, view logs, or run admin commands --
-regardless of the formation's underlying infrastructure. 
+regardless of the formation's underlying infrastructure.
 
 Build, Release, Run
-------------------- 
+-------------------
 Deis enforces strict separation between Build and Run stages
 following the `Twelve Factor model`_.
 
 Build Stage
 ^^^^^^^^^^^
-The :ref:`Controller` includes a `Gitosis Server`_ that receives
+The :ref:`Controller` includes a *gitreceive* hook that receives
 incoming git push requests over SSH and builds applications
-inside ephemeral Docker containers. 
-Tarballs of the /app directory are extracted into a slug and exposed 
-on the Controller using an Nginx static file server. 
+inside ephemeral Docker containers.
+Tarballs of the /app directory are extracted into a slug and exposed
+on the Controller using an Nginx static file server.
 The slug is later downloaded by the runtime layer and bind-mounted
 into a Docker container for execution.
 
 Release Stage
 ^^^^^^^^^^^^^
 During the release stage, a :ref:`build` is combined with :ref:`config`
 to create a new numbered :ref:`release`.
-The release stage is triggered any time a new build is created or 
+The release stage is triggered any time a new build is created or
 config is changed, making it easy to rollback code and configuration.
 
 Run Stage
 ^^^^^^^^^
 The run stage updates Chef databags and `converges`_ all nodes in the formation.
-The databag specifies the current application releases, 
-the placement of containers across the runtime layer, 
+The databag specifies the current application releases,
+the placement of containers across the runtime layer,
 and the configuration of the proxy layer.
-SSH is used to converge nodes in runtime layers followed 
+SSH is used to converge nodes in runtime layers followed
 by nodes in proxy layers, making zero downtime deployment possible.
 
 Backing Services
 ----------------
 In keeping with `Twelve Factor`_ methodology, `backing services`_ like
 databases, queues and storage are decoupled and attached using `environment
 variables`_.  This allows applications to use backing services provided by
-other applications, or external/third-party services accessible over the network.  
+other applications, or external/third-party services accessible over the network.
 The use of environment variables makes it easy to swap backing services
 when necessary.
 
@@ -98,6 +98,5 @@ See Also
 .. _`Twelve Factor model`: http://12factor.net/build-release-run
 .. _`backing services`: http://12factor.net/backing-services
 .. _`environment variables`: http://12factor.net/config
-.. _`Gitosis Server`: https://github.com/opdemand/gitosis
 .. _`Buildstep`: https://github.com/opdemand/buildstep
 .. _`converges`: http://docs.opscode.com/essentials_nodes_chef_run.html