Hi! I've been pulling my hair trying to figure out what happened to the merge-request branches that gitlab is supposed to be adding to the tor repo whenever a merge-request is opened.
I had them working for a few minutes -- but then they seem to have disappeared.
My best guess of what happened is that torproject-pusher is deleting all branches that aren't present on our gitolite git instances ... and that's deleting our merge-request branches on gitlab.
Personally I think making sure to use personal repositories and using git push --mirror is the best option.
I like that idea.
It seems much simpler than hacking at git refs, which would be much harder to understand both for maintainers (in the long run) and the users (from the outside, who possibly have no idea how git works).
I tried to figure out what is happening here as this is a major PITA for maintainers during the transition period where we still use Gitolite together with Gitlab. After reading a bit of the source code for Git's push function, I think we want to avoid using prune as that is the option causing us trouble.
What we have now behaves like this:
The maintainer pushes to Gitolite.
Gitolite does a git push --mirror to Gitlab.
Since Gitolite DOES NOT have the merge-request ref's locally, they are deleted at the Gitlab destination.
By skipping the "prune step" at the push to the Gitlabdestination, we open up for one mistake from the maintainers, which is minor compared to the current problems: if a person pushes to Gitlab a branch that does not not exist on Gitolite, the branch will remain on Gitlab until it's manually deleted. This is fine IMO. If the branch does exist, it will simply be overwritten next time Gitolite pushes to Gitlab.
Here's what I think is happening with git push --mirror (the way we do it today) with an "ordinary" non-bare git clone'd repository with a small change on that can fast-forward on master:
This is exactly what we want to avoid: it correctly moves the master branch forward, but the mirroring deletes the refs/merge-requests/* content at the destination.
Email sent to tor-dev@ about this change. Let's see if people discover anything strange with this and then let's close this issue sometime next week if everything is going fine.