setup_git_package did the same check as pkgdb_sync did [1].
Also, if gitolite already came by, it will have created an update hook, which blocks us from pushing the initial commit (since gitolite has no idea who we are).
So in that case, we will just remove the update hook: gitolite will recreate it when it comes by the repo with genacls.sh.
The change to mkdir -p is just synto make it not print an error in case the directory already existed.
[1]: https://lists.fedoraproject.org/pipermail/infrastructure/2015-February/015600.html
Signed-off-by: Patrick Uiterwijk <puiterwijk@redhat.com>
This should make it recover in case there are any repos in a weird state (aka, no master branch).
This could for example happen if the package was created in pkgdb after pkgdb_sync ran, but before
genacls.pkgdb runs, because then gitolite will see it as a new repo, and create a totally blank repo.
Especially since pkgdb_sync will abort after the first error, it would then leave all later created
repos broken as well.
Calling setup_git_package in a repo without master branch has no ill effect:
- Running git init on a pre-initialized repo is a no-op (or at least doesn't destroy current git data)
- Since it doesn't have master, it didn't run the script, so adding the first commit and hooks etc are
what we want the script to do
Signed-off-by: Patrick Uiterwijk <puiterwijk@redhat.com>
Some repos have multiple first master commits due to force-pushes.
Without this, that would crash upon branching for those packages.
Signed-off-by: Patrick Uiterwijk <puiterwijk@redhat.com>
gitolite compile creates empty git repos during compile for repos in its acl that don't exist.
Since this is automagically run by fedmsg, it triggers before scm-admins can run pkgdb_sync_git_branches.py
Because of this, pkgdb_sync_git_branches sees a git repo, thus does not execute setup_git_package.
But since setup_git_package creates master, and pkgdb_sync_git_branches later on tries to create new branches from master....
Aka, this broke process-git-requests.
Signed-off-by: Patrick Uiterwijk <puiterwijk@redhat.com>
