Git is new at Eclipse.org, and some of our existing tooling may not yet support Git. However, we expect that most of these issues will be resolved in time.

Git is new at Eclipse.org, and some of our existing tooling may not yet support Git. However, we expect that most of these issues will be resolved in time.

* The Web front-end to Git is not, and will not be hosted on [http://dev.eclipse.org/viewcvs ViewVC]. Git is hosted at http://git.eclipse.org/.

* The Web front-end to Git is not, and will not be hosted on [http://dev.eclipse.org/viewcvs ViewVC]. Git is hosted at http://git.eclipse.org/.

−

* Git is not yet included in the Dash tools, such as the [http://dash.eclipse.org Commits explorer].

* Git may not be fully integrated into the [https://build.eclipse.org/hudson/ Eclipse build infrastructure].

* Git may not be fully integrated into the [https://build.eclipse.org/hudson/ Eclipse build infrastructure].

* Due to our rigorous IP process, the Eclipse.org use-case for a [http://en.wikipedia.org/wiki/Distributed_revision_control_system DVCS] is different than that of other Open Source organizations. For this reason, an update hook is installed on all Git repositories to ensure a clean IP provenance. See [[Git#Committing_and_pushing]] for more information.

* Due to our rigorous IP process, the Eclipse.org use-case for a [http://en.wikipedia.org/wiki/Distributed_revision_control_system DVCS] is different than that of other Open Source organizations. For this reason, an update hook is installed on all Git repositories to ensure a clean IP provenance. See [[Git#Committing_and_pushing]] for more information.

* Webmaster will create a directory on git.eclipse.org to store your Git repositories. Although Webmaster can create your Git repos for you, you are free to do this yourself.

* Webmaster will create a directory on git.eclipse.org to store your Git repositories. Although Webmaster can create your Git repos for you, you are free to do this yourself.

* Decide on a timeline: webmaster needs exclusive access to your CVS/SVN repo to import it (if that is what is decided). This will disrupt project operations. Choose a timeline to minimize impact.

* Decide on a timeline: webmaster needs exclusive access to your CVS/SVN repo to import it (if that is what is decided). This will disrupt project operations. Choose a timeline to minimize impact.

−

* Now is a great time to refactor your code structure. Map the current CVS/SVN directories, modules, plugins, etc. to their new home in Git. Typically, one Git repository (.git) is created for each logical unit, or grouping of code -- a plugin, a connector, a component, and so on. For instance, the Babel project ([http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.babel/?root=Technology_Project ViewCVS]) has one CVS repository which contains a server component and a plugin component which, in turn, contains several modules. Here is one example:

+

* Now is a great time to refactor your code structure. Map the current CVS/SVN directories, modules, plugins, etc. to their new home in Git. Typically, one Git repository (.git) is created for each logical grouping of code -- a project, a component, and so on. The trade-off here is that each additional Git repository adds extra overhead to your development process - all Git commands and operations happen at the level of a single Git repository. On the flip side, each repository user will have an entire copy of the repository history, making very large repositories cumbersome to work with for casual contributors.

+

+

For instance, the Babel project ([http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.babel/?root=Technology_Project ViewCVS]) has one CVS repository which contains a server component and a plugin component which, in turn, contains several modules. Here is one example:

'''Warning:''' The import may be imperfect. Tags and branches may be missing entirely or contain missing / corrupted files. For a correct one-time conversion cvs2git should be preferred (or the import should be verified using a script like: verify-cvs2svn.py)

Trunk of cvs2git contains a number of bugfixes and should be preferred to the now old release version.

+

+

The CDT team is migrating to git using cvs2git, see: https://bugs.eclipse.org/316208 for more info.

+

+

== Convert .cvsignore to .gitignore ==

+

+

There are subtle differences in semantics between

+

[http://ximbiot.com/cvs/manual/stable/cvs_18.html#SEC191 .cvsignore] and

+

[http://www.kernel.org/pub/software/scm/git/docs/gitignore.html .gitignore], so you shouldn't just rename these files when moving to Git.

+

At least prepend a "/" to each line in .gitignore, to ensure a pattern doesn't match in all subfolders.

+

+

Good practice is to create a .gitignore directly in the top-level folder of the Git repository and add <tt>/*/bin/</tt> or <tt>/*/*/bin/</tt> (depending on repo layout). Then, you can remove the <tt>bin</tt> entry from project-level ignore files (and also remove the ignore file if that was the only entry).

+

+

==Git Team Provider==

+

+

The [http://eclipse.org/egit/ EGit project] is responsible for providing a Git Team Provider.

+

+

EGit can be installed via the [http://eclipse.org/mpc/ Eclipse Marketplace Client] or directly from the project's [http://eclipse.org/egit/download/ distribution repository].

To help with moving to Git, a team of experienced eclipse.org committers lead by Chris Aniszczyk and Dave Carver are monitoring the [https://dev.eclipse.org/mailman/listinfo/git git-dev] mailing list. If you have trouble moving or have any questions, please send an email to this list and these people will help you. These folks will be available for you to help you with the migration, from migrating your repository to setting up your new build.

+

+

==Migrating Your Project Website==

+

+

There are a few odd 'gotchas' when migrating project websites: it's just easier to let the Webmaster do it for you. Starting in August, we are looking for projects to volunteer to migrate. Starting in September, we will work our way through all projects and compel them to move.

+

+

To request migration of your website, open a bug that blocks {{Bug|324116}} (under Community/Website, or add webmaster@eclipse.org to the cc list) and the Webmaster team will add your migration to their busy schedule.

Revision as of 15:31, 14 December 2012

Eclipse projects currently using CVS or SVN may migrate their repository to Git. Here is an outline of the steps:

Due to our rigorous IP process, the Eclipse.org use-case for a DVCS is different than that of other Open Source organizations. For this reason, an update hook is installed on all Git repositories to ensure a clean IP provenance. See Git#Committing_and_pushing for more information.

Plan and structure your Git space

Webmaster will create a directory on git.eclipse.org to store your Git repositories. Although Webmaster can create your Git repos for you, you are free to do this yourself.

Decide on a timeline: webmaster needs exclusive access to your CVS/SVN repo to import it (if that is what is decided). This will disrupt project operations. Choose a timeline to minimize impact.

Now is a great time to refactor your code structure. Map the current CVS/SVN directories, modules, plugins, etc. to their new home in Git. Typically, one Git repository (.git) is created for each logical grouping of code -- a project, a component, and so on. The trade-off here is that each additional Git repository adds extra overhead to your development process - all Git commands and operations happen at the level of a single Git repository. On the flip side, each repository user will have an entire copy of the repository history, making very large repositories cumbersome to work with for casual contributors.

For instance, the Babel project (ViewCVS) has one CVS repository which contains a server component and a plugin component which, in turn, contains several modules. Here is one example:

Using git-cvsimport

Warning: The import may be imperfect. Tags and branches may be missing entirely or contain missing / corrupted files. For a correct one-time conversion cvs2git should be preferred (or the import should be verified using a script like: verify-cvs2svn.py)

Convert .cvsignore to .gitignore

There are subtle differences in semantics between
.cvsignore and
.gitignore, so you shouldn't just rename these files when moving to Git.
At least prepend a "/" to each line in .gitignore, to ensure a pattern doesn't match in all subfolders.

Good practice is to create a .gitignore directly in the top-level folder of the Git repository and add /*/bin/ or /*/*/bin/ (depending on repo layout). Then, you can remove the bin entry from project-level ignore files (and also remove the ignore file if that was the only entry).

Git Resources

Git Task Force

To help with moving to Git, a team of experienced eclipse.org committers lead by Chris Aniszczyk and Dave Carver are monitoring the git-dev mailing list. If you have trouble moving or have any questions, please send an email to this list and these people will help you. These folks will be available for you to help you with the migration, from migrating your repository to setting up your new build.

Migrating Your Project Website

There are a few odd 'gotchas' when migrating project websites: it's just easier to let the Webmaster do it for you. Starting in August, we are looking for projects to volunteer to migrate. Starting in September, we will work our way through all projects and compel them to move.

To request migration of your website, open a bug that blocks bug 324116 (under Community/Website, or add webmaster@eclipse.org to the cc list) and the Webmaster team will add your migration to their busy schedule.