1

There is a project has been on GitHub for a while, but previously it was migrated from svn. When it was initially migrated, SVN history wasn't carried to Git. Is there a way that can copy/import/clone/move SVN history to Git after the project has been set up?

Improve this question
3
  • You could make a new clone based on the Subversion history, and then try to merge those changes into your existing Git repository. Note that you won’t be able to introduce that Subversion history as a base for the existing Git history, but you could have it as a parallel history which you will merge now. Commented Jul 15, 2016 at 7:12
  • @poke why should he not be able to? Of course he is. Of course he will rewrite published history with this and anyone using the repo must recover by rebasing all their branches manually like always with changed published history. Commented Jul 16, 2016 at 21:35
  • @Vampire He cannot without rewriting history, that's what I meant. If the project has been active for a while, it seems like a good idea to keep the history as it is. Commented Jul 16, 2016 at 21:38

2 Answers 2

Reset to default
1

git-svn is not the right tool for one-time conversions of repositories. It is a great tool if you want to use Git as frontend for an existing SVN server, but for one-time conversions you should not use git-svn, but svn2git which is much more suited for this use-case.

There are pleny tools called svn2git, the probably best one is the KDE one from https://github.com/svn-all-fast-export/svn2git. I strongly recommend using that svn2git tool. It is the best I know available out there and it is very flexible in what you can do with its rules files.

If you are not 100% about the history of your repository, svneverever from http://blog.hartwork.org/?p=763 is a great tool to investigate the history of an SVN repository when migrating it to Git.

After you converted your SVN repo to a proper Git repo, add your newly generated repo as remote to your existing repo and fetch the commits. Then use git replace to replace the first commit of your new history with the last commit of your old history. If you want to make this permanent, you can then use git filter-branch to make the replacement permanent.

Be aware that you will rewrite published history and that everyone having local branches based on the former history will have to recover from this history change like described in the documentation of git rebase. If you don't want this, you can also simply pull in the newly migrated repo into your Git repo and just create new branches from the SVN history. You will then have multiple root commits and independent histories which technically is ok, but you will still have a cut in the history of the files.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

1

That's possible but you will impact all the users that already cloned the repository. So you have to decide first if it worth it.

If it isn't, just clone with git-svn in another git repository and keep it there for the source code history...

If you want to go further, once the history is retrieved, add this new repository as a remote in your actual repository and fetch.

git fetch --all

Once that's done, you should have a disjoint history.

Then, use 'git replace' to replace the first commit of the new repository by the last of the branch you just fetched.

https://git-scm.com/docs/git-replace

And last, use 'git filter-branch', that will rewrite the history definitely.

You will have to push the new history, with something like :

git push origin --all

And all the other developers will have to clone or fetch all the history... And will complain ;-)

Improve this answer

2 Comments

Thanks for the advise. Currently there are only a few clones of the repo, so it's under control... I do plan to do something similar. My idea is to convert the svn into a git, then merge this repo as a branch of the existing repo, then rebase the master of the existing repo. Do you think that will work?
In spirit, the 2 solutions are the same (except if by merging you don't say fetching, like I describe. Otherwise you're going to straight to hell... :() but mine is easier....

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.