Alex Riesen writes: > Michael Poole, Fri, Dec 07, 2007 04:01:04 +0100: >> It seems like using the current submodule code would mean that this >> kind of import would need two passes over the foreign repository, >> rather than one if the branch could be created after the parent tree >> is initially imported. I can live with that -- it is a rather unusual >> case -- but maybe there is a better way.) > > Import the core module in a branch all by itself, and merge it in > every support branch? > > > Supp1: o-o-o-----o-o-o-o-o-o-o > / > Core: o-o-o-o-o > \ > Supp2: o-o-------o-o-o-o Yes, that's the obvious way to do it with submodules. Teaching git-svn to use that is the hard part. Since the core code was first branched independently at r734 in the existing repository, the import (either automated or manual) would need to go through once to identify what subdirectories are actually submodules in git terminology, and make a second pass to actually perform the imports. If the submodule creation could happen after the fact, it would only need one pass. Maybe the right question to ask is whether having a partial-tree branch can be reasonably handled by git (in particular, detecting a rename of the core subtree to the top-level tree in the new branch's first commit). If git understand that operation, then what I would like to do would be reasonably straightforward. If it does not make sense, then I'll think about how to teach git-svn that certain subdirectories should be promoted to submodules. Michael Poole - 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
