It's an orthogonal issue w.r.t whether the end user (i.e. the developer) should initiate a deploy by using "git push". Usually this is managed by some kind of CI server than then deploys the artifact. I understand that here the TFA was actually advocating to skip this step.
However, in both cases the size of the repository (which you called the index, which btw I'm not sure is the right name; the index in git is the place where you stage changes in preparation for a commit) could be an issue. My question was more like "did you ever encounter any problems due to the size of the git repository at the build server?"
> which you called the index
Not me, I'm just "helpfully" sticking my oar in :-) I've not found index size to be a significant problem myself, but then I don't tend to find myself into situations where it can become one.
>> fab push prod deploy
to push changes to my repo service, ssh to production servers, pull down changes via git, and restart necessary services/run associated tasks like symlinking to new static content.
Aside from "deploy" I have tasks to update the virtualenv etc, this has worked well for me for a few years.
EDIT: I should explain how this actually helps solve the problem. If I'm building a package locally, I can take advantage of all sorts of cached files which I can't assume are present on the production server. I can also use tools I don't want installed in production to speed up the process. Building a local package from cached gems is pretty quick, and will get much quicker once I've got precompiled gems sorted out. I haven't got a particularly good answer to speeding up `rake assets:precompile`, but having it fail locally is better than having it fail in production.