A Manual Staging Area (https://secure.phabricator.com/book/phabricator/article/harbormaster/#change-handoff) is easy to setup, but there's an issue when using it with large repositories.
Assuming you've copied this instance example of creating a single `rSTAGE` staging area repository, each time a user runs `arc diff`, they will implicitly run `git push <rSTAGE> HEAD:refs/tags/phabricator/diff/<ID>`, which will copy their state to a tag in the staging area.
However, because of the way `git push` works, they might be uploading the entire history of the repository each time; This is not often a problem, unless your history is very large, or the network connection is very slow.
This is a result of [[https://git-scm.com/book/en/v2/Git-Internals-Transfer-Protocols | git's transfer protocols]]:
# Git push runs `git-send-pack` on the client, which runs `git-receive-pack` on the server.
# `git-receive-pack` provides the client with a list of all references that exist on the server.
# `git-send-pack` uses this list to construct a set of objects that are missing from the server, and sends them on.
In `rSTAGE`, all the references are diffs, which are never committed to `master`; Therefore, the **client git repository doesn't know any of them**, and resorts to sending everything upstream.
Interestingly, the protocol for `git fetch` contains negotiation logic to find a minimal set of commits/objects that needs to be transferred.
== What to do ==
In the short-term, an easy work-around is to add more tags to `rSTAGE`, which point to a reasonably recent point in your `master`. Each `arc diff` will still still upload all the content starting at that location, but in normal conditions that would be small enough (And you can periodically update the ref).
In the long-term, Automatic Staging Areas will bypass the issue by reusing the refs from the real repository.