> Thanks for the very interesting read. It seems like a (very) long > pipeline though, I wonder how we can make this not only easier, but > also more streamlined for git-remote-svn. The process can certainly be streamlined. As is often the case, this process was created via the "just make it work" mentality (and a barely passable knowledge of git). Now that I'm a little more comfortable with git and it's basic objects, I think I could probably create a new process that does a single pass through the svn-fe created repository and creates a new repository with the correct history (and some other nice features that come with any 2.0). But I'm also looking at this from a one-time conversion view. I had a couple of conversations with Ram that showed me my point of view is very narrow compared to the larger git-remote-svn effort... > Do you have any suggestions > on how you would prefer this to be done in git-remote-svn? (Main > advantage for git-remote-svn might be that we can use git notes to > store commit conversion information, instead of having to mine commit > messages.) I think using notes is a better way to associate conversion information with commits, but I would probably still end up mining the notes to create some sort of svn to git mapping... Correct me if I'm wrong, but I don't see how notes would help me get from an svn rev to a git sha (a common practice for tickets and wiki links in our organization). The latter is more a job for tags, and while that would be possible, that more than doubles the number of objects in the repository (I have a good percentage of SVN revs that turned into multiple git commit objects). But otherwise, my suggestions are (unfortunately) rather naive. "Make it work like git-svn, but faster" :) I can offer the warning to watch out for cross-branch (subdirectory/file) copies; we had a lot of those in our SVN repository, and I still don't know if there's anyway in Git to represent that operation... And obviously even if I did have/use the svn merge information, svn merges don't map directly to git merges... but I'm guessing I'm not saying anything you haven't already thought about. I guess after that I should add that I'm happy to help, I'm just not sure where my experience maps to the on going effort. Thanks, Stephen -- 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