A Groovy DSL to migrate from ClearCase to Git
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Type Name Latest commit message Commit time
Failed to load latest commit information.
config/codenarc #145 Start cleaning up according to CodeNarc Jul 30, 2018
docs Replace Map with HashMap in method signatures Nov 14, 2018
gradle/wrapper Fix #137. Update Gradle wrapper to 4.7 May 18, 2018
libs Add COOL as a local lib Jul 5, 2018
src Removed ExceptionHelper Nov 14, 2018
.gitignore Related to #144 Summer cleaning before fixing context shenanigans Jul 30, 2018
CONTRIBUTING.md Fix typo Jul 31, 2018
Jenkinsfile Update publishing token Jul 5, 2018
Jenkinsfile.dsl Fix #138. Add seed job to DSL, fix casing issues in DSL script May 18, 2018
build.gradle Fix #145 Added Codenarc, fixed most issues Jul 31, 2018
gradlew Updated Gradle Wrapper, cleaned up Jenkinsfile Jan 30, 2018
gradlew.bat Updated Gradle Wrapper, cleaned up Jenkinsfile Jan 30, 2018
settings.gradle Rebranding to 2Git May 12, 2016




The 2git project is an SCM migration engine allowing you to migrate to git through a Groovy DSL. Script your migration and execute it by passing it to the 2git engine. If you don't like what you see, tweak your recipe and run it again, until you get the perfect migration.

Getting started

Currently, 2git supports migrating from ClearCase and ClearCase UCM. The current quickstart guide is found at 2git.io/getting-started.

User documentation

For detailed information and docs, please refer to 2git.io.

Workflow and concepts

Independent of the source VCS, 2git follows a simple, but flexible, migration workflow. The 2git DSL is used to build up a migration plan, which is then executed by the migration engine.

  • Build a migration plan
    1. Select source snapshots matching defined criteria
    2. Assign actions to selected snapshots
  • Execute the migration plan
    1. Checkout the next source snapshot
    2. Execute the snapshot's assigned actions
    3. Repeat

The migration plan

The migration plan is built by defining filters in the 2git DSL.

Filters are used to structure your migration plan, they can contain criteria, extractions, actions and child filters.

Criteria are used to select your source's snapshots (commits, baselines, etc.). Snapshots that match a filter's criteria will have that filter's extractions and actions mapped to it in the migration plan.

Ex.: Created after a certain date, commit message matches a regex, etc.

Extractions are executed per snapshot during the actual migration to extract metadata which can be used in the actions.

Ex.: Read a file's contents from your workspace, read certain commit attributes, etc.

Actions are executed per snapshot during the migration to perform various actions. This is where the bulk of the actual migration will take place

Ex.: Commit files to git, delete some files, execute a script, etc.

Example migration

The following hypothetical repository contains some commits, tagged with metadata.


We'll define an example filter structure to build up our migration plan:

filter {
    criteria {
    actions {
    filter {
        criteria {
        extractions {
            custom {
                return  [myVersion: readFile('version.txt')]
        actions {

The first filter selects all snapshots created past the defined date and assigns the 'commit' action to them. The second filter, being a child of the first, further filters on the selected snapshots. It selects those with 'x' at 5 or above and assigns the custom extraction and 'tag' action to them.

The resulting migration plan that will be executed is the following:

Snapshot Extractions Actions
C readFile commit, tag
D N/A commit
E readFile commit, tag

CodeScene Analysis results

codescene Get more details at codescene.io.


Feel like chipping in? Check our contribution guidelines for more information!