This page details the required actions to migrating a repo to Eclipse Foundation GitHub.
- 1 Migrating a GitHub repo to Eclipse Foundation GitHub organization
- 2 End User required actions
- 3 Forked repositories
Migrating a GitHub repo to Eclipse Foundation GitHub organization
Step 0 - Transfer repo from original location to Eclipse Organization
$ git --git-dir=new.git init $ git --git-dir=new.git fetch URL refs/heads/*:refs/heads/_old/* refs/tags/*:refs/tags/_old/* $ git --git-dir=new.git push --all URL
Replace URL with the repository location on GitHub.
$ git branch -r | grep -v HEAD | cut -d/ -f2 | while read line; do git push origin :$line; done; $ git tag | cut -d/ -f2 | while read line; do git push origin :$line; done;
Deleting master branch will fail because it's the current branch.
- NOTE: we should probably not delete branch gh-pages... it's a github special page.... "grep -v gh-pages"?
- NOTE: should verify that we aren't deleting the new "_old" prefix branches during this process
Step 3 - Push a new Eclipse Approved master
$ git update-ref -d refs/heads/master $ git commit -m "New initial commit" $ git push origin master $ git push eclipse master
Step 4 - refs replace
$ git replace new_initial_commit old_history_last_commit $ git push origin refs/replace/commit_hash
- NOTE: End user mush additionally run (If they want the history): git fetch origin '+refs/replace/*:refs/replace/*'
End User required actions
If a user had previously cloned the repository before it was moved to the Eclipse Foundation GitHub organization. The move will have caused a few issues to the user’s local repository. The easiest option to resolve the issues is to just do a brand new git clone of the repository from the new location. If however this is not an option below outlines issues that the user will run into and steps to resolve the issues.
Update repository URLs
The origin remote will need to be updated to point to the new URL.
$ git remote set-url origin email@example.com:Eclipse/project.git
Fix master branch
The user’s master branch will still be based on the old master branch and needs to be changed to the new master.
The following commands will rename the local master to “old_master” and create a new master based on the new upstream master:
$ git checkout origin/master $ git branch -m master old_master $ git checkout -b master
Repeat these steps for any other additional branches that may have conflict.
(Optional) Git Replace history
If the user would like to see the old history attached to the new Initial Commit they can checkout the refs/replace/* refspec.
$ git fetch origin refs/replace/*:refs/replace/*
Forked repositories will have branches that no longer match with upstream due to upstream renaming all the branches to /_old/ prefix. The easiest way to resolve this issue is to refork upstream. However if this is not an option below lists the tasks that will need to be considered in each fork of the project.
Fix master branch
The fork’s master branch and upstream master branches will be different. To fix this the fork owner can rename their original master branch and push a new master branch based on the upstream project’s master.
$ git branch -m master old_master $ git push origin old_master $ git checkout upstream/master $ git checkout -b master $ git push --force origin master
WARNING: These command will backup master to old_master and then force pushes a brand new master to your GitHub repository.