I'm leading a subversion to git migration retaining history effort for a small team. The SVN repo has branches under APP/branches/dev, APP/branches/uat, and APP/trunk. **EDIT** the issue seems to have been the clone command needed a second argument, the gitProjectName at the end of the command as shown in the following.

git svn clone --no-minimize-url --authors-file=../authors-transform.txt --branches=APP/branches/dev  myGitProject

produces a directory structure with .git in the same directory as the parent project folder

.git MyProject

instead of

MyProject/ .git src etc

How can I either get git-svn to put the .git folder in the same directory as the project files, or move the .git folder after cloning and before pushing to the remote git repo?

We're only migrating, not using bi-directional workflow.

I'm leading a subversion to git migration retaining history effort for a small team. The SVN repo has branches under APP/branches/dev, APP/branches/uat, and APP/trunk. **EDIT** the issue seems to have been the clone command needed a second argument, the gitProjectName at the end of the command as shown in the following.

git svn clone --no-minimize-url --authors-file=../authors-transform.txt --branches=APP/branches/dev https://the./svn/myProject myGitProject

produces a directory structure with .git in the same directory as the parent project folder

.git MyProject

instead of

MyProject/ .git src etc

How can I either get git-svn to put the .git folder in the same directory as the project files, or move the .git folder after cloning and before pushing to the remote git repo?

We're only migrating, not using bi-directional workflow.

• git
• svn
• git-svn

• The git svn is a bad choice to migrate in first place, unless you have no choice and already using it and have cloned hundreds or thousands of revisions. If you just at the beginning of a clone, then better choice would be use something else. For example: SubGit. It much faster at import, but less fit for back commit from Git into SVN. So if you want a one time migrate, then better use it. Another problem here, is that the git svn is ending support: github/git-for-windows/git/issues/5405 – Andry Commented Mar 21 at 0:32
• will look into SubGit. – Neill Commented Mar 21 at 12:04
• for now, the issue seems to have been it needed a second argument, the gitProjectName at the end of the clone command, edited above. – Neill Commented Mar 21 at 12:07
• @Neill If that answers your question write your own answer and accept it yourself. – phd Commented Mar 23 at 21:24

1 Answer 1

In case if you would like to use the SubGit, here is some additional instructions important to know before the import.

1. You have to prepare the authors file to convert a name from SVN into name+mail in the Git.
2. You have to edit the config file before the import.

Here is example for a Sourcefe project.

This must be carefully reviewed. Sometimes the generated variant is not enough.

[svn]
    trunk = trunk:refs/heads/master
    branches = branches/*:refs/heads/*
    tags = tags/*:refs/tags/*
    shelves = shelves/*:refs/shelves/*

This adds the text into each commit message to link the Git commit with the SVN commit:

[svn]
    gitCommitMessage = %message\\n\\ngit-svn-id: svn+ssh://svn.code.sf/p/PROJECT/REPO/%branch@%revision SVN-REPO-GUID

If you have SSH enabled:

[auth "default"]
    passwords = subgit/passwd
    sshKeyFile = PATH-TO-SSH-FILE
    sshKeyFilePassphrase = "PASSWORD"

To translate externals:

[translate]
    externals = true

Steps:

1.

subgit configure --layout auto svn+ssh://[email protected]/p/PROJECT/REPO WORKING-COPY-DIRECTORY-TO-IMPORT

subgit import WORKING-COPY-DIRECTORY-TO-IMPORT

Better to name each Git branch like subgit--SVNBRANCH-rXXX to remember the last imported SVN revision of a branch. Because in the Git you likely would use a different structure and so branch naming.

git push origin master:subgit--trunk-rXXX --follow-tags

I would recommend to start over in the Git and just copy the last SVN revision into first Git commit of a new branch. Later you can just purge the SVN history from the Git repo without destructive rewriting. Or split into Git repo with SVN history only and Git repo without SVN history. It will have sense when you come into hundreds or thousands of revisions in the Git and it started to consume the disk space. At that point the SVN history in the Git will be a trash.

To translate externals read this: svn to git migration with nested svn:externals