git svn project shuffle

I have used git to interface with an svn repo for some time quite successfully, but today I've run into a scenario that I'm not sure how to solve.

The situation is this:
* I have a project (let's call it "oldproj") that has its own
branches, tags, and trunk svn structure
* oldproj is checked out using git svn clone --stdlayout and all has been swell
* due to a CM shuffle oldproj's svn trunk has been copied to a new svn
project (let's call it newproj), so oldproj/trunk has been copied to
newproj/trunk/oldproj
* oldproj's branches and tags directories have been "archived",
meaning it isn't CM guy's intention to bring them over to the newproj
structure.  I don't mind losing the contents of the oldproj's branches
and tags, but I'm not sure how to transition to newproj using my
already checked out git svn clone

My questions are: # 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?

# 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?

Regarding the second question, I'd be concerned that the loss of the branches and tags from the oldproj would confuse things in the future as the newproj branches and tags are new.

This is probably a simple scenario that many have bumped into but my searches have so far come up blank.

Thanks very much for any guidance or pointers to previous discussions regarding this scenario.

-- Chris

Hi Chris,

Christopher Snapp wrote:

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.

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

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@gmail.com> wrote:

Hi again,

Christopher Snapp wrote:

Yeah, I was ignoring this part. :) git svn is not really wired for it.

The instructions were meant to also be usable in a case where oldproj and newproj are entirely independent repositories.

If the layout has been relatively stable before, maybe "git svn --no-follow-parent" would give some joy.

Still I would be interested in hearing where the grafting procedure went wrong. If you end up tracking it down to a single step, do please let us know.

Regards, Jonathan