Merge branch 'master' of gitlab.com:gitlab-org/gitaly into an-readme-update-2017-01-20

1 files changed, 1 insertions, 0 deletions

diff --git a/README.md b/README.md
index 1860cd7be..25d0abf44 100644
--- a/README.md
+++ b/README.md
@@ -112,6 +112,7 @@ All design decision should be added here.
 1. GitLab already has [logic so that the application servers know which file/git server contains what repository](https://docs.gitlab.com/ee/administration/repository_storages.html), this eliminates the need for a router.
 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.
 
 ## Iterate