I am planning svn for git repository group migration. Two of them are in a certain condition.
A project was developed in svn repo. Due to various restrictions, the project was forked at some point. The fork was made by duplicating the svn repository. After that, two projects developed separately. There are no branches or tags in the repo except the trunk.
Significant functionality was developed for the original project and should be transferred to the plug. In the current situation, this can be done by creating a patch from various versions and applying it to a forked project. This has the advantage of short-term simplicity in the current situation, but has a number of cumbersome consequences in the long run.
We could have two different git repositories and cross-migrate through pull requests, but that might be a loss of convenience (we don't use github). In addition, it may take time when we want to reintegrate the plug into the parent project due to the modular reorganization of the design. Another approach would be to merge the two svn repositories into one git repository as different branches and manage subsequent merges from there (with all the benefits it gives).
Ideally, I would like to recreate the true history of the project, i.e. have a git repository with:
- one branch consisting of commits to the fork
- two different branches, consisting of a parent and a fork, commit to HEADs
An interesting fact that may help, the following command creates identical SHA1 for shared commits:
git svn clone -s -A svn.authors --no-metadata http://subversion.foo.local/repo/path git_migration
I don't care --no-metadata , because it's one-way migration.
How can I achieve such a result, if possible?
source share