Comment 3 for bug 219042

Actually, the whole IRC conversation provides more info ...

(18:29:00) dato: igc: though if you prefer to look into this one, I'm happy to. the problem seems to be that we're instructing git-fast-import to rename a directory, when we shouldn't be doing that.
(18:31:26) mwhudson left the room (quit: Read error: 104 (Connection reset by peer)).
(18:31:48) james_w: hi dato
(18:32:13) dato: hello james_w
(18:32:22) james_w: if that is the issue then it may be worth talking to Shawn, as it seems that possibly should be allowed.
(18:32:53) james_w: well, git should just ignore it, but I don't see why it should reject it.
(18:35:32) mwhudson [n=mwh@118-92-12-123.dsl.dyn.ihug.co.nz] entered the room.
(18:36:33) dato: uhm, no, I'm mistaken
(18:36:59) dato: path/dir1 was renamed to path/dir2, and it seems that was accepted (of course)
(18:37:38) dato: and then path/dir1/fileX was renamed to path/dir2/fileY, and that boomed
(18:38:30) james_w: so a directory rename is recursive to git-fastimport?
(18:39:51) dato: well, it is to bzr as well, ain't it?
(18:40:42) james_w: I'm not sure how it's represented internally
(18:40:52) james_w: I would expect bzr-fastimport to do that though
(18:44:12) dato: maybe bzr-fast-export should do some ordering, I'm not sure