This is the current list of things a project must consider before making the switch to Git. Expect this list to grow.

Destination for Git commit emails

Commit summary emails need a mailing list destination.

Commit email subject format

Everyone has their own ideas on what goes in a email subject line. Instead of trying to pick a format that everyone is happy with, each project can customize their own subject lines. Variables available to this formatting so far are:

  • Full git hash - %(hash)s
  • Short git hash - %(shash)s
  • Repository name - %(repo_name)s
  • Commit subject - %(subject)s
  • Files changed - %(files)s

Each project must provide a subject line formatting before being switched to Git. An example subject line definition might look like:

git commit [%(repo_name)s]: %(shash)s - %(subject)s

This uses Python string formatting so you can repeat variables at will. If you have ideas for more variables feel free to suggest them on

Tag rearrangement

Obviously, SVN is not Git. During the process of cloning a Git repository from the SVN repository, commits for tags and branches can get a bit confused. Each project is responsible for providing a list of ref updates that they would like to have applied to their repository before accepting it as writable.

Common cases where this is used are in moving tags to point at the correct Git commit.

Updates should be specified in a three column format of:

oldsha newsha ref-name

Protected ref lists

ASF wide policy prevents rewriting history on the main development branch of every project. This same check can also be configured to protect other refs as well.

A common configuration is to prevent non-fast-forward updates on any ref that matches the following patterns:


If you then name your release branches and tags as "rel/1.0.x" this will prevent people from accidentally modifying them.

User name spaces for branches

A proposed feature is to maintain a per-user branch namespace. This will allow each committer to have their own assigned set of branches for development work and prevent others from accidentally overwriting work in progress.

There is nothing fancy or official about such branches. They merely exist as a safe guard as a possibly large number of users maybe be sharing the branch namespace.

Any project interested in this feature should mention it.

Review of git history

It is the responsibility of each project to review the Git history in their new repository before it is made the official repository. In the event that a project has to revert to SVN due to a bad Git clone, it is the project's responsibility to reapply writes made to Git back to SVN. It is in the project's best interest to make sure that the history is correct before starting to use it as an official repository.