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.

  • How should I apply the git-flow paradigm to my project?
  • How to find the current git branch in detached HEAD state
  • Restore local master after making commits on it
  • Use 'pull' or 'merge' to merge local branches?
  • “if” versus “switch”
  • Where should I upload the built file of a github branch?
  • 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
    

  • Failed to lock refs/heads/master
  • Why does this merge produce a conflict
  • Github: Detecting pull requests and their size
  • Why git doesn't push tags by default?
  • Subdirectories in checked out directory of a previous revision not disappearing in Git?
  • Environment variables in .git/config
  • 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.