Wednesday, May 30, 2012

Moving git houses

Lately I've realised (or better, this has been bugging me for months now) that the repository I'm using on repo.or.cz is messed up a little bit. Some branches are merged back to master, some are not, then branched again, etc etc. And the at same time, making these creations more public I'd like to make it more user-friendly and while repo.or.cz provides a nice, stable service, github on the other hand is armed with an issue tracker, a wiki and some more. Yes, it is more shiney and glittery :)

With these two reasons on my mind, I've started 'migrating' the git repository from A to B. The following is a summary what I've done:

Moving houses from repo.or.cz to github, also means cleaning up the repos

  • create github_repo on github website with the web interface: http://github.com/kgkilo/tracks
  • cd ~/WORK
  • git clone github_repo tracks
  • git clone repo.or.cz/myrepo.git oldtracks
so at this point we have 2 directories, one for the new repo and one for the old one
  • cd oldtracks
  • git remote rm origin (just to play safe)

cleaning up what we want to import


  • git filter-branch --subdirectory-filter trackname -- --all
  • mkdir trackname
  • mv * trackname
  • git add .
  • git commit

importing


  • cd ../tracks
  • git remote add old-repo ../oldtracks
  • git co -b trackname
  • git pull old-repo trackname
  • git remote rm old-repo
  • mkdir trackname
  • mv * trackname
  • git add -f trackname
  • git commit -a

cleaning up the new repo


  • git rebase -i origin
  • squash, reword or delete commits (time to remove all the unwanted signs you've left behind earlier...)

final steps


  • git log, git st, git do_everything_to_check_for_sanity.
  • repeat the above... really!
  • git co master
  • git push origin trackname

And now... I can do this for all the branches... :)
NB: the filter-branch step proved to be the most problematic one. It is not git's mistake, it is the result of my own careless, unwanted merges back to master sometimes. Something to get rid of, for sure.

refs:
http://gbayer.com/development/moving-files-from-one-git-repository-to-another-preserving-history/
http://effectif.com/git/move-commit-from-one-branch-to-another
http://zenoga.tumblr.com/post/6751990283/til-convenient-cherry-picking-from-another-git
http://stackoverflow.com/questions/1365541/how-to-move-files-from-one-git-repo-to-another-not-a-clone-preserving-history
also:
http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
http://stackoverflow.com/questions/67699/how-do-i-clone-all-remote-branches-with-git
http://www.zorched.net/2008/04/14/start-a-new-branch-on-your-remote-git-repository/