# Migrate your enzo-dev fork from Bitbucket to GitHub The Enzo project has moved from [bitbucket](https://bitbucket.org/enzo-project/) to [github](https://github.com/enzo-project). In doing so, we have also switched from Mercurial to Git for version control. ## Where is the new enzo-dev repo? The enzo-dev repo is now located at: https://github.com/enzo-project/enzo-dev To clone the repo, do: ``` git clone https://github.com/enzo-project/enzo-dev ``` ## Moving your fork to GitHub 1. Fork the new GitHub repo by clicking on the *Fork* button in the upper, right corner of the [main enzo-dev repo page](https://github.com/enzo-project/enzo-dev). If you don't have any changes to move over from Bitbucket, then you're done. 2. Install and enable the `hggit` extension. a. Note: `hggit` only works with version 4.7 of `mercurial` and earlier. You can install `mercurial` using Conda by doing the following: ``` # create a Python 2 environment $ conda create -n py27 python=2 $ source activate py27 $ conda install 'mercurial==4.7' $ conda install `hg-git` ``` b. Enable the `hggit` Mercurial extension. This will allow you to interact with Git repos using Mercurial. To do this, add `hggit=` under the `[extensions]` section of the file, `~/.hgrc`. If you don't have one, you can create one that looks like this: ``` [extensions] hggit= ``` 3. Clone your Bitbucket fork with Mercurial if you don't already have a local copy. For example, here's mine: ``` hg clone https://bitbucket.org/brittonsmith/enzo-dev ``` 4. Go into your Bitbucket fork and create a bookmark for every head that has changes you want to move to GitHub. These can be for open pull requests or any changes you've had that you want to hold onto. ``` cd enzo-dev # changeset to head of some PR hg update 4d3d3d3 hg bookmark my-feature ``` 5. Make a fork of the [main enzo-dev repo](https://github.com/enzo-project/enzo-dev) by clicking the *Fork* button in the top-right corner. 6. Clone your github fork using git: ``` git clone git@github.com:brittonsmith/enzo-dev /Users/britton/Desktop/enzo-dev-git ``` 7. Go back into your mercurial repository. Add a new path to the `.hg/hgrc` file of your Enzo-E repo that points to the local git repo you just made. ``` [paths] default = ssh://hg@bitbucket.org/brittonsmith/enzo-dev gitrepo = /Users/britton/Desktop/enzo-dev-git ``` 8. Use Mercurial to push your bookmarked heads to your git repo. ``` # from within your hg repo hg push -B my-feature gitrepo ``` 9. Go back to your git repo and push your new changes to your github fork. ``` git push origin my-feature ``` **Note:** You'll need to follow steps 4, 8, and 9 for every separate head in your mercurial fork. Each head must be bookmarked since that's how git will name the branch. **Note:** Before you'll be allowed to push, you'll need to set up your ssh key on GitHub. Documentation for that is available [here](https://help.github.com/articles/connecting-to-github-with-ssh/). These changes will now show up on your GitHub fork as a new branch with the same name. ## Working with your new GitHub fork Once you've moved your changes over to your new fork, the most straightforward thing is to clone your new fork with Git and work from that. ``` git clone git@github.com:brittonsmith/enzo-dev ``` If you've pushed changes from Bitbucket, it may be a good idea to sync them with changes that were made to the main enzo-dev repo on GitHub when it was moved. These changes include new documentation and testing configuration. This is not strictly necessary, but may be useful if you don't intend to merge your changes upstream for quite a while. 1. Add a remote for the main Enzo-E repo. This will allow you to pull in any new changes that end up there. I will call this remote `enzo-dev`. From within your Git repo: ``` git remote add enzo git@github.com:enzo-project/enzo-dev ``` 2. Change to the `master` branch in your repo and pull from the main repo. ``` git checkout master git pull enzo master ``` 3. If you want to update your branch with the latest changes from the master branch, then you have a couple options: a. **Rebase**: This rewinds all of your changes back to when they first diverged from the master branch and then attempts to reapply them to the tip of the master branch. This works fine if you know that your changes affect different parts of the code than the recent changes to master. Otherwise, the **merge** option is safer. For more information on what rebase does, see [here](https://git-scm.com/docs/git-rebase). **Note**, there are times when rebasing is not a great idea. Read [this](https://www.atlassian.com/git/tutorials/merging-vs-rebasing) for a discussion of the differences between **rebase** and **merge**. Ok, if you still want to do it, here's what to do: ``` git checkout my-feature git rebase master ``` b. **Merge**: This creates a new commit that merges all the changes between two branch, pretty much just how you were doing things with mercurial. You can do this like so: ``` git checkout my-feature git merge master ``` 4. Push your changes up to your github fork. Before doing this, take a moment to double-check where you'll be pushing by doing `git remote -v`. This shows all the places you are setup to push and pull from. ``` git remote -v ``` Here's what I get: ``` enzo git@github.com:enzo-project/enzo-dev (fetch) enzo git@github.com:enzo-project/enzo-dev (push) origin git@github.com:brittonsmith/enzo-dev (fetch) origin git@github.com:brittonsmith/enzo-dev (push) ``` I want to push to my fork, so that's `origin` for me. `origin` is typically the default name for the repository that you cloned from. ``` git push origin my-feature ``` If you've done a **rebase**, pushing your changes up to your GitHub fork may fail because you've reordered your change history and are freaking out the squares. If this is the case, you can add `-f` to the push command to force it. Try without the `-f ` first and only use it if you get an error.