Moving from Mercurial and BitBucket to Git and GitHub

While skeptical at first, after trying it out github has won my favor as my favorite version control. This post records steps made to transfer from Mercurial and BitBucket to Git and GigHub while keeping history

Step 1 – Set up Password caching following article ‘Set Up Git’

Step 2 – Install git-hg module. This allows to clone a mercurial repository from BitBucket and then converts it to git repository that you can push into the GitHub.com

Followed article ‘Moving Your Mercurial To Rep To Git’

Step 3 – Clone the existing GitHub repository and push it to GitHub as following:

git-hg clone http://bitbucket.org/some/repo name-git-repo
cd name-git-repo
git remote add origin http://github.com/some/repo.git
git push origin master

Potential Issues

1. “fatal: remote part of refspec is not a valid name in .”
This happens when you created new branch that you would like to push into github repo while the github repo doesn’t contain the new brach. Solutions:

git config push.default current

This will change default setting for ‘push’ to create new branch in the github repo if doesn’t exist before pushing. Here are other options:

  • nothing : Do not push anything
  • matching : Push all matching branches (default)
  • tracking : Push the current branch to whatever it is tracking
  • current : Push the current branch

Useful Links

No rollback information available…Strip It!

There may be time when you like to undo a commit. In my situation, i was on the wrong branch when made the commit. To solve problem i try to run mercurial command ‘hg rollback’ that rolls back single commit or pull,however. When run, it returned:

 >No rollback information available

Fortunately, i had my changes saved in the patch using shelving. In this post, about alternative if ‘hg rollback’ does do it.

Strip It!

An alternative to rollback there is command ‘hg strip [hashOfChangeset]’. This removes the said changeset including changesets that descend from it.

In order, to use this command you need to enable ‘mq’ extension that is part of mercurial package(version 2.3.1). To enable this extension, update global mercurial configurations -.hgrc file(usually home directory) the ‘extensions’ section as follows:

...
[extensions]
mq=
...

Afterwards, run the command with the change set you wish to strip (use ‘hg log -l10 will show you last 10 changesets)

 >hg strip someChangeSet
Useful Links

Shelving Uncommitted Changes in Mercurial

There may be a time when your realize that the changes you just made (uncommitted changes), need to be on separate branch. That happend to me in my new workplace few days ago. My new workplace use branching extensively to ensure code review process is taking place. Every feature or defect is done on separate branch. After work completed, the developer initiates a pull request via bitBucket so that there is another developer who approves the changes before merged into main trunk. So, for my first changes i forgot and i completed my changes on the main trunk just to later learn it has to be on a separate branch.  The Shelving feature in Mercurial came to rescue me. I was surprised to learn that a task that can become time consuming and challenging was accomplished so easy thanks to shelving feature. This post will cover how to install Shelve extension and then use this feature to move some uncommitted changes into a different branch.

Install Extension – hgshelve

You may not need this because some IDE like IntelliJ comes with the extention – hgshelve preinstalled and configured, however, if you are like me who likes command line mercurial hg then we have to install.

1. Clone the extension – hgshelve

>hg clone ssh://hg@bitbucket.org/tksoh/hgshelve

2. Configure the extension – hgshelve

To do so, update your global mercurial config .hgrc file section ‘extensions’ in your home directory as follows:

[extensions]
 hgshelve=/path_to_dir_cloned_above_step_1/hgshelve.py

This completes the installation and configuration of the extension – hgshelve. Now, you are able to take advantage of the power that shelving brings to you

Using Shelve

1. Shelve Uncommitted Changes

First, i shelve my uncommitted changes while on the main branch by executing command:

>hg shelve --name DE4653_DE3847_Shelved

Once started, mercurial will be asking to confirm each change that adding to shelve something like:

>$ hg shelve my_dir/my_file.ext
>examine changes to 'my_dir/my_file.ext'? [Ynsfdaq?]

The options – [Ynsfdaq?] stand for:

y - shelve this change
n - skip this change

s - skip remaining changes to this file
f - shelve remaining changes to this file

d - done, skip remaining changes and files
a - shelve all changes to all remaining files
q - quit, shelveing no changes

? - display help</pre>

If you like to see every change added to this shelve then select ‘Y’ or ‘a’ for shelving all of the changes without confirming each

This shelves the changes and i am safe to change branches

Verify Shelved Changes

1. To verify your changes has been shelved, run:

>hg shelve --list
DE4653_DE3847_Shelved

This would list all of the shelved changes. In our case, there is only one

2. Another way to ensure changes has been shelved is to run ‘hg status’. If changes shelved, this should return nothing

3. If you doing for the first time and you are afraid of losing, then look at .hg/shelve directory in application dir (precisely, mercurial working directory). There you should find text files containing the changes per each shelving. You can back those up. You can email to your friend developer to finish, perhaps,  in situations where you have shelved uncommitted changes and you are unable to complete because you going out town. Or email to yourself to finish at home. By putting these text files in your home computer .hg/shelve folder, makes those available to unshelve and finish

Unshelve Changes

2. Create New Branch. To create new branch, run command:

>hg branch DE4653_DE3847

This not only creates new branch, it also automatically puts you in the new branch. To verify what branch you are at any time, run ‘hg branch’

3. Unshelve Changes

When ready, to unshelve your changes, run:

>hg unshelve --name DE4653_DE3847_Shelved

This takes our uncomitted changes shelved previously and adds to our working directory. To verify you can run ‘hg st’ or ‘hg shelve –list’. The latter will return nothing in our case because after unshelving the shelvDE4653_DE3847_Shelved is destroyed.

Now, we are able to commit the new changes in the separate appropriate branch, so we can create pull request , thus, accomplishing our goal.

4. Nudge Changes

Not related  shelving, however part of the exercise – putting your changes on separate branch. The last step after unshelleving the changes and committing, perhaps, is to push your branch with the unshelled changes into the central repo. This allows others to code review and approve pull request(i.e. bitbucket)

The general ‘hg push’ method will push all branches in your local repo that you may not want. You only need to push your new branch. For that purpose, use ‘hg nudge’ that is a push command but only for the branch you are on at the given moment. Before that works you need to update .hgrc – mercurial global configuration in home directory as follows:

...
[alias]
nudge = push --rev .

Afterwards, make sure you are in the proper branch and call method:

>hg nudge

This pushes just unshelved changes as separate branch into centra repo

Bug – Added Files Unable Shelve

It turns out that for newest current version of the ‘hgshelve’ extension there is bug which prevents to shelve any files that has been added to working directory and has status ‘A’.

The best solution i found is to use a different mercurial extension – hgattic that contains the shelve feature but does not have the bug. Make sure you grab it from the repo version that works with the newest version of mercurial https://bitbucket.org/sinbad/hgattic/

Everything applies the same way except the commands are named slight different. It also add some extra goodies about all of which you can learn from hgattic wiki

Useful Links:

Someone Has Already Registered That SSH key

You may have been using SSH key to login, retrieve code on BitBucket.org for some account. Perhaps, then you wished to do the same for another account but when adding your public ssh key for the another account you got the error – Someone has already registered that SSH key. This post is how to automatically push, pull and connect to any of Repo’s from your machine on any of the accounts hosted by BitBucket.org

We found our solution to this limitation in mercurial extension – mercurial_keyring. In this post we will cover how to install the extensions and then how to configure mercurial to remember credentials for different repos on different accounts in BitBucket.org

About The Extension – mercurial_keyring

Here description from http://pypi.python.org/:

mercurial_keyring is a Mercurial extension used to securely save HTTP and SMTP authentication passwords in password databases (Gnome Keyring, KDE KWallet, OSXKeyChain, specific solutions for Win32 and command line). This extension uses and wraps services of thekeyring library.

The extension prompts for the password on the first pull/push (in case of HTTP) or first email (in case of SMTP), just like it is done by default, but saves the password. On successive runs it checks for the username in .hg/hgrc, then for suitable password in the password database, and uses those credentials (if found).

In case password turns out to be incorrect (either because it was invalid, or because it was changed on the server) or missing it just prompts the user again.

Passwords are identified by the combination of username and remote address, so they can be reused between repositories if they access the same remote repository (or the same SMTP server).

Installing The Extensions – mercurial_keyring

1. Clone The Project

>hg clone https://bitbucket.org/Mekk/mercurial_keyring

2. Configure Extension. To do so update .hgrc config file ‘extensions’ section in your home directory(the global mercurial config) as following:

[extensions]
mercurial_keyring = /path_To_dir_cloned_step_1/mercurial_keyking.py

This will enable the extension – mercurial_keyring for mercurial hg

Configuring For Multiple BitBucket Accounts

In the global mercurial config (.hgrc in home directory) you can config each Repo on different BitBucket accounts as follows:

[auth]
 minnehaha.prefix = https://minnehahalofts@bitbucket.org/minnehahalofts
 minnehaha.username = minnehahalofts
 minnehaha.schemes = http https
 kapasoft.prefix = https://kapasoft@bitbucket.org/kapasoft
 kapasoft.username = kapasoft
 kapasoft.shcemes = http https

In above, we created two aliases – minnehaha and kapasoft each referencing two different BitBucket accounts. The good thing this works for clone  command as well, so now i can quickly clone three different repos on two different BitBucket accounts:

>hg clone https://minnehahalofts@bitbucket.org/minnehahalofts/repo1
http authorization required
realm: Bitbucket.org HTTP
user: minnehahalofts
password:xxxx
>hg clone https://kapasoft@bitbucket.org/kapasoft/repo2
http authorization required
 realm: Bitbucket.org HTTP
 user: kapasoft
 password:xxxx
>hg clone https://kapasoft@bitbucket.org/kapasoft/repo3
http authorization required
 realm: Bitbucket.org HTTP
 user: kapasoft
 password:xxxx

Each time it will prompt for password for the appropriate username. It is only for the first time since we connecting for the first time. Afterwards, the extension save the passwords making it very convenient to push, pull or any other way connect to the Repos

Issues

1. ‘abort: No module named keyring!’

Issue: keyring library missing on your machine. To install, run ‘easy_install keyring’ from command line

Useful Links