I have a question about the best approach to take for refactoring a large svn project into git. The project, boost.org, is a collection of C++ libraries (>100) that are mostly independent. (There may be cross-library dependencies, but we plan to handle that at a higher level.) After the move to git, we'd like each library to be in its own git repository. Boost can then be a stitching-together of these, using submodules or something (opinions welcome). It's an old project with lots of history that we don't want to lose. The naive approach of simply forking into N repositories for the N libraries and deleting the unwanted files in each is unworkable because we'll end up with all the history duplicated everywhere ... >100 repositories, each larger than 100Mb. So, what are the options? Can I somehow delete from each repository the history that is irrelevant? Is these some feature of git I don't know about that can solve this problem for us? (Caveat: I'm new to git and still getting up to speed. An acceptable answer is: go off an learn about feature X and come back to us.) At boost, We've already discussed a few possible approaches. Feel free to comment and/or criticize any of the solutions suggested here: http://github.com/ryppl/ryppl/issues#issue/4 -- Eric Niebler BoostPro Computing http://www.boostpro.com -- 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