= Using Git to maintain GDAL workflow =

This article describes how to maintain GDAL development workflow with [http://git-scm.com/ Git] against GDAL Subversion repository.

Note, this is '''not a complete guide''' of how to use ''git-svn'', but a quick list of basic operations.

Requirements: [http://git-scm.com/ git] and [http://www.kernel.org/pub/software/scm/git/docs/git-svn.html git-svn]

== Git repository setup ==

First, initialize local Git repository for copy of trunk form Subversion:

{{{
$ git svn init --trunk https://svn.osgeo.org/gdal/trunk/
}}}

The option ''--trunk'' explicitly specifies intention of this operation.

It is also possible to copy complete repository, including trunk, branches and tags modules. Learn about ''--stdlayout'' option dedicated for this purpose. However, note that this initial fetch is a time consuming process. (fetching of SVN trunk takes nearly one hour).

Next, fetch complete copy of GDAL trunk:

{{{
$ git svn --authors-file=/path/to/gdal-git-authors.txt fetch
}}}

The file ''gdal-git-authors.txt'' (attached) is used by Git to translate names of SVN committers to Git names which uses format "Full name <e-mail>". Specifying the ''--authors-file'' option is optional, but recommended.

It may be a good idea to compress Git repository in order to save some space. For example, SVN trunk occupies nearly 140 MB of disk space. Git can compress it to about 100 MB. Git provides a dedicated command for this purpose [http://www.kernel.org/pub//software/scm/git-core/docs/git-gc.html git-gc]:

{{{
$ git gc
}}}

You can bring your local Git repository up to date against GDAL trunk any time. 

{{{
$ git svn --authors-file=/path/to/gdal-git-authors.txt rebase
}}}

The ''rebase'' command is equivalent to ''svn update''. Learn more about ''rebase'' in [http://www.kernel.org/pub/software/scm/git/docs/git-svn.html git-svn] manual.

== Development cycle ==

After this step, you maintain your own local repository of GDAL trunk. You can proceed with your own development, make changes and commit them to your local repository.

{{{
$ git commit -m "my big feature"
}}}

If you are GDAL committer, you can push your changes to GDAL Subversion repository directly from your local Git repository of GDAL trunk:

{{{
$ git svn dcommit --dry-run
$ git svn dcommit
}}}

You can also push the local copy to your own Git remote repository to share your development experiments, then others will be able to ''clone'' it. For example, you can push it to [http://github.com/ GitHub]:

{{{
$ git push --all git@github.com:mloskot/gdal.git
}}}

== Update cycle==

Once local clone of a ''git-svn'' enabled repository is ready for the cycle of ''svn update'' and ''git push'', the routine of updating mirror includes the following two commands only:

{{{
$ git svn --authors-file=/path/to/gdal-git-authors.txt rebase
$ git push git@github.com:mloskot/gdal.git
}}}

=> Note from user etiennesky: I had to use the following command after the initial fetch:

{{{
git reset --hard remotes/trunk
}}}

== GitHub Mirror ==

I try to maintain up-to-date Git repository with mirror of GDAL Subversion trunk. It is available as [https://github.com/mloskot/gdal gdal repository] maintained by [https://github.com/mloskot/ mloskot].

Note, if you are GDAL committer, clone of this repository will not allow you to issue ''git svn dcommit'' command to push your changes back to GDAL trunk. If you expect this functionality, you need to maintain Git repository of GDAL trunk on your own according to the steps described above. Quoting one of [http://stackoverflow.com/questions/1880405/can-different-git-svn-clones-of-the-same-svn-repository-expect-to-be-able-to-shar/1880487#1880487 best practices listed here]:

    ''For the sake of simplicity and interoperating with SVN, it is recommended that all git-svn users clone, fetch and dcommit directly from the SVN server (the remote SVN repository that is), and avoid all git-clone/pull/merge/push operations between git repositories and branches which are either retrieved via git svn clone and which are also used to push back changesets into the remote SVN repository.''

This process may be time consuming, so an alternative is to use ''rsync'' to copy existing GDAL tree enabled with ''git-svn'' from another committer.

== Resources ==

 * [http://help.github.com/svn-importing/ Importing from Subversion] on GitHub
 * [http://www.kernel.org/pub/software/scm/git/docs/git-svn.html git-svn] manual
 * [http://stackoverflow.com/questions/1880405/can-different-git-svn-clones-of-the-same-svn-repository-expect-to-be-able-to-shar/1880487#1880487 Can different git-svn clones of the same svn repository expect to be able to share changes then git svn dcommit?] on StackOverflow
 * [http://justaddwater.dk/2009/03/09/using-git-for-svn-repositories-workflow/ Using Git for SVN Repositories Workflow]
 * [http://flavio.castelli.name/howto_use_git_with_svn Howto use Git and svn together]
 * [http://trac.parrot.org/parrot/wiki/git-svn-tutorial Using git to maintain Subversion branches]
 * [http://michael-prokop.at/blog/2007/12/03/git-svn-in-30-minutes/ git-svn in 30 minutes]