Marcus Brinkmann <m.brinkmann@xxxxxxxxxxxx> writes: >> Are you still able to do a re-roll on this? > > I have to admit that my interest has declined steeply since > discovering that subtree-split and filter-branch --subtree-filter give > different results from "git svn" on the subdirectory. The reason is > that git-svn includes all commits for revisions that regular "svn log" > gives on that directory, which includes commits that serve as branch > points only or that are empty except for unhandled properties. What do you mean by "branch points only?" It's ok if you can't do a reroll. I can't work on it right now but perhaps when I get back to cleaning up the split code I can take what you have and incoporate it. I do very much appreciate your work on this! > While empty commits for unhandled properties wouldn't be fatal, > missing branch points make "git svn" really unhappy when asked to > rebuild .git/svn. [ I may have misunderstood your intent, see below. ] I just want to make sure I understand your situation. You used git-svn to mirror a project to git and then used git-subtree to incorporate that mirror into a larger project? Why is the split being done? If there's an active Subversion repository being mirrors it's much better to commit changes back to the Subversion repository than to the git mirror. > As migration from SVN is my main motivation at this point to use a > subtree filter at this point (git-svn is just very slow - about one > week on our repository), I am somewhat stuck and back to using > git-svn. Although hacking up something with filter-branch seems like a > remote option, it's probably nothing that generalizes. Ok, maybe I misunderstood your situation. Are you converting one big repository via git-svn and then trying to break out individual directories into smaller projects? git-svn + git-subtree/git-filter-branch is not the best way to do that. svn-all-fast-export is far superior for a one-off conversion and makes splitting repositories a breeze. It happens during conversion rather than as a post-processing step. https://techbase.kde.org/Projects/MoveToGit/UsingSvn2Git > It didn't help that "make test" in contrib/subtree gives me 27 out of > 29 failed tests (with no indication how to figure out what exactly > failed). Huh. I don't know why that would happen. Did you build the git tools first? A testing run using --debug and --verbose (see the Makefile in contrib/subtree/t) would be informative. I understand if you don't have time to do that. I haven't seen such failures before so I'm curious as to what happened. -David -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html