Git operations on /vagrant/mediawiki are a bit slow, and the cloning (when running 'vagrant up' takes several minutes. Also, the size of the repo is 0.5GB.
This is probably because the full history is cloned; I doubt many developers need that. By default, mediawiki-vagrant should do a shallow clone (possibly with a configuration parameter to change it).
Version: unspecified
Severity: normal
git-clone was in fact shallow prior to Gerrit change I9742facc6, and the setting was parametrized prior to I4c475126a.
One issue with shallow clones is that git-review will pull the entire history anyway, except it will do so silently, and at point in time where the user is not expecting it (that is, upon patch submission).
Another thing to consider is the reason Git is so slow. Network costs are only a part of the story. Until the user runs 'update-guest-additions', the VM will run with an old version of VirtualBox Guest Additions, and thus an older implementation of VirtualBox Shared Folders, the filesystem driver used to share a path between guest and host; its performance is abysmal, especially when creating lots of small files.
It'd probably be good to re-parametrize the clone depth; I'm not sure why I removed the parameter, to be honest.
I guess this should be a git-review bug then (or maybe I just don't understand how it works; but I would expect that as long as the closest parent commit which is already merged can be found locally, git-review has no need of the rest).
Re: VirtualBox Shared Folders, couldn't mediawiki-vagrant just use NFS on linux hosts? If the filesystem is indeed a problem, that would speed up HTTP response times as well as git speed.
(In reply to Tisza Gergő from comment #2)
Re: VirtualBox Shared Folders, couldn't mediawiki-vagrant just use NFS on
linux hosts? If the filesystem is indeed a problem, that would speed up HTTP
response times as well as git speed.
Done, as of Ia9214dcd5