Problem exporting to git

Frits Jalvingh jal at
Thu Mar 6 10:43:22 UTC 2014

To everyone that jumped in to help, thanks again. In the meanwhile it seems
I have found a fix for this particular problem. I looked at all Launchpad
bugs for fast-export and applied the patches/solutions found one by one.
The set of changes that works for now is:

=== modified file ''
--- 2012-02-28 16:16:13 +0000
+++ 2014-03-04 20:10:38 +0000
@@ -365,14 +365,7 @@

     def _get_name_email(self, user):
-        if user.find('<') == -1:
-            # If the email isn't inside <>, we need to use it as the name
-            # in order for things to round-trip correctly.
-            # (note: parseaddr('a at') => name:'', email: 'a at')
-            name = user
-            email = ''
-        else:
-            name, email = parseaddr(user)
+        name, email = parseaddr(user)
         return name.encode("utf-8"), email.encode("utf-8")

     def _get_commit_command(self, git_ref, mark, revobj, file_cmds):
@@ -529,7 +522,9 @@

         must_be_renamed = {}
         old_to_new = {}
-        deleted_paths = set([p for p, _, _ in deletes])
+# jal fix from launchpad
+#        deleted_paths = set([p for p, _, _ in deletes])
+ deleted_paths = set([p for (p, _, kind) in deletes if kind != 'directory'
or not self.plain_format])
         for (oldpath, newpath, id_, kind,
                 text_modified, meta_modified) in renames:
             emit = kind != 'directory' or not self.plain_format
@@ -572,6 +567,8 @@

+                if new_child_path in deleted_paths:
+                  deleted_paths.remove(new_child_path)

         # Record remaining deletes
         for path, id_, kind in deletes:

Adding this allowed me to at least have a successful conversion of all 50
related branches to Git - at least at this moment..

I am seeing this whole thing as a warning though. When I started work on
migrating to Git the idea was to keep bzr as long as possible, as it's
clearly better in many ways, and why move away as long as it works, right?
I planned to take this year to leisurely fix all our tools to support git
too. But to me this shows there is a real risk; git moves and changes, this
in turn has effects on how it handles imports which might cause bzr's
export to break more and more. And what is exceedingly clear here is that
no one is maintaining it at all. As seems to be the case with the other
tools that were mentioned in here. So the real risk is not bzr: it is the
risk of losing your repository or having to do substantial work on
fast-export if you postpone migration. Which is sad news; I have to speed
up moving to git. And boy, the more I use it the more I hate it 8-/ I think
it's the first time I've seen an actively user-hostile user interface..

> This probably doesn't help you, but when I switched from svn to bzr, ....
Well, sharing pain does help ;-), and I fear that you are right. But I was
under the impression that the whole fast-export toolset was quite well
defined and supported, considering I'll not the only one that needs to
migrate from bzr to something else 8-/.

Anyway, again thanks everyone for your help!

On Thu, Mar 6, 2014 at 5:24 AM, Stephen J. Turnbull <stephen at>wrote:

> Chris Hecker writes:
>  >
>  > This probably doesn't help you, but when I switched from svn to bzr, I
>  > had to write a bunch of filters and hack existing scripts and whatnot to
>  > get everything to import, and my repo was relatively simple.  I think
>  > there's no robust tool for this because nobody does it often,
> Come to think of it, Eric Raymond has been advertising a new (?) tool
> of his own called "reposurgeon".  Like everything ESR does, it's the
> best ever and no improvement is possible. ;-)  Author's well-known ego
> notwithstanding, I bet it's pretty good -- if you haven't tried it yet
> it's probably worth a shot.
> Caveat: untested (by me). :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the bazaar mailing list