Removed git execution cache as a design decision as it’s a task,

not a design decision

1 files changed, 0 insertions, 2 deletions

diff --git a/README.md b/README.md
index d7259e290..2ef1276cd 100644
--- a/README.md
+++ b/README.md
@@ -104,8 +104,6 @@ All design decision should be added here.
 1. Use [gRPC](http://www.grpc.io/) instead of HTTP+JSON. Not so much for performance reasons (Protobuf is faster than JSON) but because gRPC is an RPC framework. With HTTP+JSON we have to invent our own framework; with gRPC we get a set of conventions to work with. This will allow us to move faster once we have learned how to use gRPC.
 1. All protocol definitions and auto-generated gRPC client code will be in the gitaly repo. We can include the client code from the rest of the application as a Ruby gem / Go package / client executable as needed. This will make cross-repo versioning easier.
 1. Gitaly will expose high-level Git operations, not low-level Git object/ref storage lookups. Many interesting Git operations involve an unbounded number of Git object lookups. For example, the number of Git object lookups needed to generate a diff depends on the number of changed files and how deep those files are in the repository directory structure. It is not feasible to make each of those Git object lookups a remote procedure call.
-1. We would also like to cache git executions (as a `git clone --depth=1` or even `git fetch`) that end up being pure git transfer protocol.
-> This makes sense because when a CI execution gets spawned we will have multiple clones happening with the same result as they are going for a specific branch/commit. These operations are expensive and can be easily cached.
 
 ## Iterate