Jonathan, First off, thanks very much for the quick and thorough response. Sadly, this is outside the norm for me and I'm just not understanding all the steps. As a result I've successfully mangled my poor git repo. Good thing I followed step 0. :) I'll continue to read up on some of the steps you listed to try and figure out where I went wrong, but I'm wondering if there might be an easier way to get back to a stable repo. The alternative I'd like to try is to simply clone the new svn location. What I'm not understanding is why git will not traverse the svn history properly. If you remember my old project's trunk has been copied to a subdirectory of the new project's trunk. So, oldproj/trunk is now newproj/trunk/oldproj. When I do a git svn clone of the newproj I would expect it to follow the svn copy that created newproj/trunk/oldproj but it doesn't. I'm simply left with a couple of commits and none of the original oldproj history. If I view the svn repo using some other tool (e.g. kdesvn) I can see all the history as expected. I'm not coming up with anything in my searches that would give me a reason why git would stop searching history. Thanks again for the help, On Mon, Oct 4, 2010 at 2:54 PM, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: > Hi Chris, > > Christopher Snapp wrote: > >> # If I try to start from scratch by using git svn clone --stdlayout >> the "newproj" location I lose all of the revision history associated >> with "oldproj/trunk" that has been copied to newproj/trunk/oldproj. >> How can I have git understand the history for the >> newproj/trunk/oldproj location? > > If I were in your situation I would do the following: > > 0. Make backups! > 1. git svn init -Rnew ...newproj info... > 2. Edit .git/config to put the new project in a separate > refs/remotes/newproj/ hierarchy. > 3. git svn -Rnew fetch > 4. gitk --all. Look around. > 5. For each "tip" of the old history: > git replace <corresponding new commit> <old branch tip> > 6. gitk --all. Make sure it looks right. > 7. git filter-branch -- --all > 8. rm -fr .git/svn. This is destructive, but only of information > you're probably not using. (It forgets old properties, for > example.) > 9. Edit .git/config and use "git branch -r -d" to get rid of references > to oldproj. Rename the newproj svn-remote to "svn" again. > 10. git svn fetch. > 11. gitk --all. Everything good? Push. > >> # An alternative would be if I could somehow reconfigure my already >> checked out oldproj git repo so I retain all of the version history >> and my local branches and can move forward checking code into the >> newproj/trunk/oldproj location? > > If your history in each branch is not published and is linear, you > could also try just putting the old and new histories in one temporary > repo and rebasing your private branches. > > Or you can export your own work with "git format-patch" or "git > fast-export" and reimport it with "git am" or "git fast-import". > > Hope that helps, > Jonathan > -- Chris -- 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