My GitHub Page

Project maintained by lgatto Hosted on GitHub Pages — Theme by mattgraham

About me and this page

Laurent Gatto, working in the Computational Proteomics Unit. More info about my work here. This page is a central gateway to my github projects (under construction, though).

The list of repositories can (obviously) be found where you would expect it. Nothing more to say for now.

Git(hub) notes

git and svn

Github and git and cool, but svn is still around and much used. Since some projects are hosted by third parties using svn, but I still want to use Github, I tried to initialise git and checkout svn in the same directory. I does work very well (you are probably wondering why it would it not). The only little tweaks are to ignore the respective .git and .svn directories. The latter in easy with the .gitignore file. Ignoring files in svn is not that straightforward. One needs to set properties on the files/dirs to be ignores and, what was confusing to me, commit these to the server. Here are three posts [1, 2, 3] that helped me to realise how to this and will hopefully prove helpful next time I have to repeat this.


This is obviously the cooler solution, but was a bit tricky for me to set up - I have an existing/active svn and an older github repo. But in the end, I managed to properly merge both and retail all commit messages in the git repo. These [1, 2] were the most helpful ressources. There is also of course the Pro Git book with a git-svm section.

In the end, the svn-remote entry in the .git/config file ended up like this

  [svn-remote "svn-devel"]
  url = https://https://svn/path/to/svn/project
  fetch = :refs/remotes/git-svn

At some point, I struggled with the Unable to determine upstream SVN information from working tree history error. In the end, commiting changes in the svn and git repositories fixed it. Not very elegant, but worked out.

I have expanded the above on a dedicated the Bioconductor BiocGithubHelp wiki page.

Bitbucket to Github migration

Moving code from Bitbucket to Github is straightforward. But there is much more than just code in such a project. In my case, I had issues I really wanted to preserve, and I could not find any easy way to do it (as of the time of writing). There were scripts to migrate issues and bug tracking between different providers, but not exactly what I needed. Had to read about the respective APIs to do it manually, which was not too difficult. Briefly, here is a summary of what I did, more or less:

  1. Download issues locally as described here. The issues need to be public, though.

     curl https://api.bitbucket.org/1.0/repositories/:user/:repo/issues/1/ > myissue1.json

(where :user and repo are my/your user and repository names respectively).

  1. Unfortunately, the json issues are not compatible: Bitbucket's content is called body by Github (there might be more...). A bit of perl magic did the trick here.

      perl -pi -e 's/\"content\":/\"body\":/' issue*.json
  2. Post the issues on Github following the API docs:

      curl -u ":user:password" -X POST -d @issue1.json ttps://api.github.com/repos/:user/:repo/issues

It is far from perfect; comment were missing! Fortunately, there were only very few issues with relevant comments (most closing comments were fixed in version x.y.z), so I did not dig deeper. The above steps were embedded in a short shell script to automate the 30ish issues to be moved. Hope that next time I need to do this, somebody will have a great script ready, or at least this will prove helpful.