Svn to git: How to deal with our not-standard, probably wrongly branched svn

Our current svn structure looks like this:

trunk
-- project
-- projectDao
-- projectResources
branches
-- project-1.0
-- projectDao-1.0
-- projectResources-1.0
-- project-2.0
-- projectDao-2.0
-- projectResources-2.0
tags
-- project-1.0.0
-- ...

To make things worse project-1.0 was branched from project projectDao-1.0 from projectDao (each in seperate move commits). Idealy it would have been like this.

  • Git undo local branch delete
  • Show git branch in file explorer
  • How to change the default branch to push in mercurial?
  • Your configuration specifies to merge with the <branch name> from the remote, but no such ref was fetched.?
  • How to determine branch name from batch file
  • git: Merge Branches but Keep Commit History
  • This is the commit log:

    trunk
    -- project
    -- projectDao
    -- projectResources
    branches
    -- 1.0
    ---- project
    ---- projectDao
    ---- projectResources
    -- 2.0
    ---- project
    ---- projectDao
    ---- projectResources
    tags
    --1.0.0
    ----project
    ---- ...
    

    And this is the way it makes sense. And we should then have branched from trunk to 1.0 instead of 2 different commits.

    We however want to switch to git now (permanently) and I am at a loss how i should start with this.

    I don’t really get how i should do this. When i just git clone my repository with standard layout I get something this.

    * master
      remotes/project-1.0
      remotes/project-1.0@3
      remotes/project-2.0
      remotes/project-2.0@10
      remotes/projectDao-1.0
      remotes/projectDao-1.0@4
      remotes/projectDao-2.0
      remotes/projectDao-2.0@11
      remotes/projectResources-1.0
      remotes/projectResources-1.0@5
      remotes/projectResources-2.0
      remotes/projectResources-2.0@12
      remotes/tags/project-1.0.0
      remotes/tags/projectDao-1.0.0
      remotes/tags/projectResources-1.0.0
      remotes/trunk
    

    This is what gitg generates

    This is what gitg generates

    I don’t know how I can use rebase to get this right like:

    * master
      remotes/1.0
      remotes/2.0
      remotes/tags/1.0.0
      remotes/trunk
    

  • git mergetool reports “No files need merging”
  • Code review of a branch in GitHub
  • converting git branch to git tag
  • Git log for only part of a file?
  • Git SSH client for windows and wrong path for .ssh/config file
  • How to deploy gulp on production server
  • 2 Solutions collect form web for “Svn to git: How to deal with our not-standard, probably wrongly branched svn”

    If I understand correctly, you want to change the imported branches to directories in a 1.0 branch. Furtheron you don’t mention if this is a permanent migration or a git-svn checkout while you maintain your svn repository.

    In case this is just a git-svn checkout and the goal is to keep working with the original SVN as central repository, I would just do a checkout without using the standard layout switch and work in the directories of SVN. It’s a bit dirtier, but you don’t have problems while pushing back to SVN.

    In case you want to transform your repository, add a commit to all branches putting the contents of that branch into a directory in the root, to merge the branches together afterwards. You won’t loose the SVN history with the old branch structure in your GIT history, but the future will be new-style.

    Only in case you want to transform all of the history you will have to create directories and rebase.

    You should be able to rebase these branches as you see fit with git. As long as you can get the complete history from svn to git it’s a piece of cake to create branch 1.0 and 2.0 from any commit you see fit and continue from there to build up any structure you want.

    Git Baby is a git and github fan, let's start git clone.