You can clone with
HTTPS or Subversion.
I need to test this, but I had the problem in production where Gitolite would let me push to the old remote, but nothing was actually push in the project if I cloned it. It's strange that the old repo was available.
I patched the problem for current repos by rebuilding the whole gitolite config. I still have no clue why exactly it happened, but it may be because Resque was unavailable during the namespace move?
as git / gitolite:
rm -rvf .gitolite repositories/gitolite-admin.git "repositories/*/*/gl-conf" "repositories/*/gl-conf"
gitolite setup -pk ./gitlab.pub
cp -v /home/gitlab/gitlabhq/lib/hooks/post-receive /home/git/.gitolite/hooks/common/post-receive ; chown -v gitolite.gitolite /home/git/.gitolite/hooks/common/post-receive
# stop gitlab
mv tmp tmp2
rm -rf tmp2 &
bundle exec rake tmp:create RAILS_ENV=production
RAILS_ENV=production bundle exec rake gitlab:gitolite:update_keys
RAILS_ENV=production bundle exec rake gitlab:gitolite:update_repos
bundle exec rake gitlab:enable_automerge RAILS_ENV=production
# restart gitlab
Same here, saw this behaviour after moving from 3.1 to 4.x. Also - when i rename a namespace the same thing happens, the old namespace is still on disk, the repositories are eventually duplicated.
Another way of fixing this is found on the new (now much better) help pages: my.gitlab.install/help/raketasks#cleanup. I executed all three in the order listed and now my repository folder is clean again.
bundle exec rake gitlab:cleanup:config RAILS_ENV=production
bundle exec rake gitlab:cleanup:dirs RAILS_ENV=production
bundle exec rake gitlab:cleanup:repos RAILS_ENV=production
Maybe this bug was supposed to be a feature, as security precaution in case anything goes kaboom when moving projects around on disk - however i feel this cleanup should be taken care of somehow in order not to litter the repository storage over time.
@mikkyhouse - Shouldn't those cleanup tasks at least be mentioned in the Migration Wiki? Or was this fixed in a commit?
Its not reproducable with current master. Also its mentioned in GitLab help page
Fair enough, thx for clarifying!