On Thu, Oct 6, 2016 at 4:31 PM, Joseph Myers <jos...@codesourcery.com> wrote: > On Thu, 6 Oct 2016, Jason Merrill wrote: > >> After I ran into a couple of reposurgeon bugs and didn't hear back >> from you, I started investigating rewriting the existing git svn >> mirror with git filter-branch instead. That seems an attractive >> option, but not long afterward I needed to shift focus to front end > > I've used both git-svn (sometimes with git filter-branch) and reposurgeon > for repository conversions. My experience is that if there's anything at > all complicated or messy about the history, using git-svn for the > conversion is not a good idea, so I don't think that's an attractive > option at all.
But we're already using git-svn, and it's fine. Introducing another tool just adds opportunities to be affected by new and different bugs. Specifically, reposurgeon doesn't like subdirectory branches much more than git-svn does, though I was able to work around that with branchify (and some fixes in reposurgeon). It discards branches with no additional commits, and keeps other branches that were deleted in SVN, though I was able to work around this with a postprocessing script. Most significantly, it fails to handle some commits (I noticed r137307 and r131989), leading to incorrect file content at the top of the affected branches. This is the issue that I didn't hear back from Eric about, which led me to consider other approaches. Fortunately it marked them (as well as many others) with emptycommit tags for review. But if you want to do it with reposurgeon, I won't complain. I've pushed my WIP to https://github.com/jicama/gcc-reposurgeon Jason
