How To Convert Bazaar Repo to Git

This was way more difficult that I thought it would be, but I have conquered. I may be the only person in the world who even cares about doing this, but I'm writing it here so I don't forget.

I think it's hard because both the revision control tools, and the conversion tool are all still pretty new and in a state of flux. I finally got it to work using bzr version 0.15.0, git version 1.5.2.3, and tailor version 0.9.29. Both bzr and git are just what I had on my Ubuntu Feisty Fawn box that I keep up to date with backports and everything. Tailor version 0.9.26 is in the feisty repositories, but it most definitely didn't work for this. I grabbed the tarball for the latest source from here. You can just untar it and run it right from there.

OK, now, once you have tailor, to make this work, you need a tailor configuration file. Just put it anywhere and name it whatever you like. Mine looked a little like this:

[DEFAULT]
verbose = True
patch-name-format = ""

[project]
source = bzr:source
target = git:target
start-revision = INITIAL
root-directory = /homes/brmu/testing/fw_tests
state-file = tailor.state

[bzr:source]
repository = /homes/brmu/lnx/fw_tests
subdir = fw_tests-bzr


[git:target]
subdir = fw_tests-git

The paths for root-directory and the subdirs are just what I needed for my particular project. This tells tailor to grab the bzr repo from /homes/brmu/lnx/fw_tests, and then (I'm not sure exactly why it makes a copy) copy it to /homes/brmu/testing/fw_tests/fw_tests-bzr. Then it creates a git repository in /homes/brmu/testing/fw_tests-git and does the migration/conversion from bzr to git using these two new directories. I already had the /homes/brmu/testing/fw_tests directory created. Once you have this configuration file set up you can run tailor like this:

/path/to/latest/tailor -D -c tailor.conf

tailor.conf is the configuration file, of course. I found the best documentation for tailor in the README file with the source code. There is a wiki and a manpage, but those were both not as helpful.

Comments

Marian Schubert said…
Hi,
I'm having problems converting this simple bzr repo to git:

http://maio.cz/tmp/test.tgz

any idea what might be wrong?

http://git.pastebin.com/m7751bf5a

config:
http://maio.cz/tmp/test.conf
October 23, 2007 at 7:15 AM
Anonymous said…
tailor makes a copy of the bzr repository because it fetches one patch at a time, then rsyncs the bzr directory with the git repository then commits the changes, so the bzr copy will slowly evolve as the migration is taking place.
March 11, 2009 at 3:29 PM
homunq said…
Thanks.

I had some problems because my INITIAL revision was empty, so tailor gave me a funny "NoSuchId: The file id "None" is not present in the tree" error. So I had to set my start-revision to a later revision id, which I got from "bzr version-info -all"

(like you, I may be the only one with this problem, but I'm putting the solution out there because I wish someone else had).
June 18, 2010 at 3:04 AM
piyo said…
Inspired from your post, I wrote a bash script to help automate the process. It's generic and full of comments so it might be useful. Then again the source repo was very simple.

http://github.com/piyo/emacs-ahk-mode/blob/convert/convert.sh
August 15, 2010 at 9:22 PM
Eric said…
It is now easy to convert between Bazaar and Git (and Mercurial) using fast-export and fast-import. Example:

bzr fast-export --plain --rewrite-tag-names ../project_bzr | git fast-import

See the succinct example here or the detailed example
here.
November 19, 2013 at 2:23 AM
Eric said…
p.s. If your Bazaar repository has bug tracking metadata that you want to preserve in Git, that would be lost using --plain. However, Git's fast-import cannot normally handle the full content of Bazaar's fast-export with --no-plain.

One solution that filters the --no-plain output to make it acceptable to Git is described here.
November 19, 2013 at 2:35 AM
Post a Comment

Popular posts from this blog

SystemVerilog Fork Disable "Gotchas"

This is a long post with a lot of SystemVerilog code. The purpose of this entry is to hopefully save you from beating your head against the wall trying to figure out some of the subtleties of SystemVerilog processes (basically, threads). Subtleties like these are commonly referred to in the industry as "Gotchas" which makes them sound so playful and fun, but they really aren't either. I encourage you to run these examples with your simulator (if you have access to one) so that a) you can see the results first hand and better internalize what's going on, and b) you can tell me in the comments if this code works fine for you and I'll know I should go complain to my simulator vendor. OK, I'll start with a warm-up that everyone who writes any Verilog or SystemVerilog at all should be aware of, tasks are static by default. If you do this: module top; task do_stuff ( int wait_time); #wait_time $display ( "waited %0d, then did stuff" , wa
Read more

'git revert' Is Not Equivalent To 'svn revert'

I just learned that if you have some changes in your working tree that you want to get rid of, you don't type 'git revert' like you might guess. No, that's what cvs, subversion, mercurial, and bazaar (to name a few) use revert to mean, but not git. With git, revert is used to undo actual commits. Thankfully, you can undo your revert with another 'git revert', I just learned. So let me repeat to be clear, if you have changes to your working files that you want to abandon, DO NOT do this: git revert HEAD That will undo your last commit. Do this instead: git reset --hard HEAD I'm glad I have that straightened out now. I'm wondering if /etc was really a good place for me to start out playing with git. UPDATE: Nearly two years later and I'm still getting comments on this. I'm glad I've been able to help people out this way. The discussion in the comments is good, and one thing I'd like to point out is that I now always use
Read more

Put /etc Under Revision Control (with git)

UPDATE : There is a much easier way now : sudo aptitude install etckeeper There, now etc is under revision control and changes are automatically committed with a helpful message after you install new packages. Thanks for the tip, Marcelo! Read on for the original blog entry. --- I put my /etc directory under revision control. I used git. It's awesome. Not that I think I'm going to wholesale copy my /etc from one machine to another, nor because I'm going to branch my /etc directory and spend weeks developing some cool new feature (whatever that would look like...) and then merge it back into the main branch. No, it's mostly because I like the idea of having the big "undo" option that having things under revision control provides. Having to commit changes and write check-in comments when I make changes helps me stay more organized too. It's never good when I go in willy-nilly to make a "quick change" to some configuration file. I r
Read more