! [remote rejected] refs/pull/1/head -> refs/pull/1/head (deny updating a hidden ref)
! [remote rejected] refs/pull/1/merge -> refs/pull/1/merge (deny updating a hidden ref)
What are these errors? Can I assume the repository was mirrored ?
As mentioned in this issue, that happens when you mirror a GitHub repo which has pull requests made to it.
The refs beginning 'refs/pull' are synthetic read-only refs created by GitHub - you can't update (and therefore 'clean') them, because they reflect branches that may well actually come from other repositories - ones that submitted pull-requests to you.
So, while you've pushed all your real refs, the pull requests don't get updated
You would need to mirror a GitHub repo without their pull requests.
Simply replace the catch-all refspec above with two more specific specs to just include all heads and tags, but not the pulls, and all the remote pull refs will no longer make it into your bare mirror:
fetch = +refs/heads/*:refs/heads/*
fetch = +refs/tags/*:refs/tags/*
fetch = +refs/change/*:refs/change/*
If push still fails, as commented by Ofek Shilon, add the push entries:
push = +refs/heads/*:refs/heads/*
push = +refs/tags/*:refs/tags/*
push = +refs/change/*:refs/change/*
As mention in Git Refspec:
The + tells Git to update the reference even if it isn’t a fast-forward.
This change is to be done on the bare repository folder repository-to-mirror.git, using git config --local --edit.
The named remote to modify is the default "origin" one.
The goal is to not fetch the unwanted references, and push only the ones we need.
–
Full steps:
git clone --bare https://github.com/exampleuser/old-repository.git
cd old-repository
git push --mirror https://github.com/exampleuser/new-repository.git
Found working and simple solutions there https://www.metaltoad.com/blog/git-push-all-branches-new-remote
git push newremote refs/remotes/oldremote/*:refs/heads/*
git push newremote refs/remotes/oldremote/features/*:refs/heads/features/*
(I wanted this to be a comment, but not enough reputation)
Based on @VonC's answer, this sounds like a non-problem.
So, while you've pushed all your real refs, the pull requests don't get updated
I see two scenarios in which you want to duplicate your repository.
You want a backup/copy of a repo that you have full control over.
You're modifying the history of a repo and you need a backup locally in case you need to undo your changes.
In either case, it seems like git clone --mirror is your safest option because even if you see errors in your push, all of the non-pull request related content was successfully pushed, which takes care of scenario 1. For scenario 2, you'd want those pull request references as part of your backup.
–
Adding these three lines to the git config file after the fetch = +refs/:refs/ line fixed it for me:
push = +refs/heads/*:refs/heads/*
push = +refs/tags/*:refs/tags/*
push = +refs/change/*:refs/change/*
I faced a similar issuer when trying to delete some big files from gitlab by rewriting the history, following the procedure here: https://docs.gitlab.com/ee/user/project/repository/reducing_the_repo_size_using_git.html
IMPORTANT: Before starting use gitlab export function to export your project, these steps went wrong for me many time before I figured it out.
The issue I faced as mentioned by others is that you can not rewrite read-only refs specifically does for PRs (merge requests as they are called in gitlab)
The obvious idea that come then is to create a new repo, but this would loose all the issues, releases...
Fortunately, gitlab allows to export you repo with all this metadata unto a zip file, that contains all the git bundled, (more info here about git bundle).
A bundle is basically a full archive of the repo, and ou can clone form it:
git clone --mirror ./project.bundle
Not you have a mirror of your project (the same way if you have mirror cloned form the server), and you can use git filter-repo or (BFG)[https://rtyley.github.io/bfg-repo-cleaner/] as explaind in the docs, to find the biggest files and delete them from history.
use du -h before and after to make sure that the size of your repo is really smaller, now you can create a new git bundle with:
git bundle create --progress project.bundle --tags --branches master
although I recommend handling all branches before this procedure to avoid messing up branches.
You can replace project.build in the export downloaded from gitlab (ie create a new tar.gz with exact same structure, be careful of prefix...)
this can be done by:
tar -xvzf project_name...export.tar.gz
replace the project.bundle
cd project_name...export
tar -cvzf updated.tar.gz . # important to avoid messing up tar structure
And the re-importing the project.
You can rename you project to PROJECT_NAME-bkp in gitlab, and reimport with same name as before.
Hope it save someone else the time.
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
