9.2 Git and other systems-migrating to Git

Migrating to Git

If you now have a code base that is using another VCS, but you have decided to start using git, you must somehow migrate your project to git. This section introduces some of the generic system's importers and then shows you how to develop your own custom importer. You will learn how to import data from the SCM systems of several large professional applications, not only because they are the systems that most of the users who want to convert are using, but also because it is easy to get high-quality tools for them. Subversion

If you read the previous chapters on Git svn, you can easily use those instructions to git a repository of SVN clones, stop using Subversion servers, push to a new Git server, and then start using. If you want history, you can pull data from the Subversion server as quickly as possible to accomplish this (it may take some time).

However, the import is not perfect; because it takes too long, you may have already done the import in other ways. The first problem that the import produces is the author information. In Subversion, each person commits a user in the system, which is recorded in the commit message. In the examples in the previous chapters, Schacon are shown in several places, such as the blame output and git svn log. If you want to map the subversion user above to a better git author's data, you need a subversion user mapping to a git user. Create a Users.txt file that contains a mapping like this in the following format:

Schacon = Scott Chacon <schacon@geemail.com>
selse = Someo nelse <selse@geemail.com>

To get the list of author names that SVN uses, you can run this:

$ svn Log--xml | grep Author | Sort-u | \
  perl-pe ' s/.*> (. *?) <.*/$1 =/'

This outputs the log as an XML format, and then preserves the author information rows, removes duplicates, and strips out XML tags. (Obviously this will only run on machines with grep, sort and perl installed.) Then, redirect the output to your Users.txt file so that you can add the corresponding Git user data after each record.

You can make this file available to git svn to help it map author data more accurately. You can also tell Git svn not to include metadata that Subversion typically imports by passing--no-metadata to the clone and INIT commands. This will make your import command look like this:

$ git svn clone http://my-project.googlecode.com/svn/\
      --authors-file=users.txt--no-metadata-s my_project

Now there should be a better Subversion import in the My_project directory. It's not like the following commits:

Commit 37efa680e8473b615de980fa935944215428a35a
Author:schacon < Schacon@4c93b258-373f-11de-be05-5f7a86268029>
Date:   Sun May 3 00:12:22 +0000

    fixed install-go to Trunk

    git-svn-id:https://my-project.googlecode.com/svn/trunk@94 4c93b258-373f-11de-
    be05-5f7a86268029

Instead, they look something like this:

Commit 03a8785f44c8ea5cdb0e8834b7c8e6c469be2ff2
Author:scott Chacon <schacon@geemail.com>
Date:   Sun 3 00:12:22 +0000

    fixed install-go to trunk

Not only is the Author field better to look at, Git-svn-id is not.

After that, you should do some clean-up work after import. In the first step, you should clean up the strange references to Git svn settings. First move the labels so that they are labels instead of strange remote references, and then you move the remaining branches so that they are local.

To turn the label into a suitable Git tag, run

$ cp-rf. git/refs/remotes/origin/tags/*. git/refs/tags/
$ rm-rf. git/refs/remotes/origin/tags

This causes the remote branch reference in the remotes/origin/tags/to become a true (lightweight) label.

Next, move the remaining references under Refs/remotes to the local branch:

$ cp-rf. git/refs/remotes/*. git/refs/heads/
$ rm-rf. git/refs/remotes

Now all the old branches are real git branches, and all the old tags are real git tags. The last thing to do is to add your new Git server as a remote repository and push it to the top. Here's an example of adding your server as a remote repository:

$ git Remote add Origin git@my-git-server:myrepository.git

Because you want to upload all the branches and tags, you can now run:

$ GIT push origin--all

All of your branches and tags should be on a new Git server through the beautiful, clean import operation above. Mercurial

Because Mercurial and git have very similar models when it comes to expressing versions, and because Git has more flexibility, it's quite straightforward to convert a repository from Mercurial to git, using a tool called "Hg-fast-export". You need to copy one from here:

$ git clone http://repo.or.cz/r/fast-export.git/tmp/fast-export

The first step in the transformation is to get the full clone of the Mercurial repository you want to convert:

$ HG Clone <remote repo url>/tmp/hg-repo

The next step is to create an author mapping file. Mercurial is more tolerant of the content put into the changeset author field than Git, so this is a good opportunity to clean up. You only need to use one line of commands under the bash Terminal:

$ cd/tmp/hg-repo
$ hg Log | grep User: | sort | uniq | sed ' s/user: *//' >. /authors

This will take a few seconds, depending on how much of the project commit history, and the final/tmp/authors file will look like this:

Bob
bob@localhost
Bob <bob@company.com>
Bob Jones <bob <AT> company <DOT> com>
Bob Jones <bob@company.com>
Joe Smith <joe@company.com>

In this example, the same person (BOB) creates a changeset with a different name, one of which is actually correct and the other is completely incompatible with the Git commit specification. Hg-fast-export Fix the problem by adding ={new name and email address} to the end of the line that we want to modify, removing any row of the user name that we want to keep. If all the user names seem to be correct, then we don't need this file at all. In this case, we'll make the file look like this:

Bob=bob Jones <bob@company.com>
Bob@localhost=bob Jones <bob@company.com>
Bob Jones <bob < At> company <DOT> Com>=bob Jones <bob@company.com>
Bob <bob@company.com>=bob Jones < Bob@company.com>

The next step is to create a new Git repository and then run the export script:

$ git init/tmp/converted
$ cd/tmp/converted
$/tmp/fast-export/hg-fast-export.sh-r/tmp/hg-repo-a/tmp/ Authors

The-r option tells Hg-fast-export where to look for the Mercurial repository we want to convert, and the-a flag tells it where to find the author mapping file. This script parses the Mercurial changesets and then translates them into the scripts that are needed for the Git "Fast-import" feature (which we'll discuss later in detail). This will take a little time (although it is faster than passing through the grid) and the output is quite lengthy:

$/tmp/fast-export/hg-fast-export.sh-r/tmp/hg-repo-a/tmp/authors Loaded 4 authors master:exporting full revision 1/22 208 with 13/0/0 added/changed/removed files master:exporting-Delta revision 2/22208 with 1/1/0 Added/changed/remov Ed files master:exporting Simple Delta revision 3/22208 with 0/1/0 added/changed/removed files [...] master:exporting simp Le Delta revision 22206/22208 with 0/4/0 added/changed/removed files master:exporting Simple Delta revision 22207/22208 W ith 0/2/0 added/changed/removed files master:exporting thorough delta revision 22208/22208 with 3/213/0 Added/changed/rem
oved files exporting tag [0.4c] at [HG R9] [git:10] exporting tags [0.4d] at [HG R16] [git:17] [...] exporting tag [3.1-RC] at [HG r21926] [git:21927] Exporting tags [3.1] at [HG r21973] [git:21974] Issued 22315 commands g     It-fast-import statistics:---------------------------------------------------------------------Alloc ' d objects: 120000 Total objects:115032 (208171 duplicates) blobs:40504 (205320 duplicates 26117 deltas of 39602 attempts)         trees:52320 (2851 duplicates 47467 deltas of 47599 attempts) commits:22208 (          0 Duplicates 0 Deltas of 0 attempts) tags:0 (0 duplicates 0 Deltas of 0 attempts) total branches:109 (2 loads) marks:1048576 (222          atoms:1952 Memory total:7860 KiB pools:2235 KiB objects:            5625 KiB---------------------------------------------------------------------pack_report:getpagesize () = 4096 Pack_report:core.packedGitWindowSize = 1073741824 Pack_report:core.packedGitLimit = 8589934592 Pack _report:pack_used_ctr = 90430 Pack_report:pack_mmap_calls = 46771 pack_report:pack_open_w         indows = 1/1 pack_report:pack_mapped = 340852700/340852700------------------------------------------ ---------------------------$ git shortlog-sn 369 Bob Jones 365 Joe Smith

That looks very good. All Mercurial tags have been converted to git tags, and Mercurial branches and bookmarks are converted to git branches. You are now ready to push the warehouse to the new server:

$ git Remote add origin git@my-git-server:myrepository.git
$ Git push origin--all

Perforce

The next system to see Imports is Perforce. As we discussed before, there are two ways to get git to communicate with Perforce: Git-p4 and Perforce git Fusion. Perforce Git Fusion

Git Fusion makes this process painless. Just use the configuration files discussed in Git Fusion to configure your project settings, user mappings and branches, and then clone the entire repository. Git Fusion lets you in an environment that looks like a native git repository, and you can push it to a native git host at any time if you want. You can even use Perforce as your Git host if you like. GIT-P4

GIT-P4 can also be used as an import tool. As an example, we will import the JAM project from the Perforce public repository. In order to set up the client, you must export the P4PORT environment variable to point to the Perforce warehouse: