project

Upon taking over maintainership of the Performance project, once started by kbahey, I was asked to migrate the Performance module from the Devel project in such a way that all development history regarding the Performance submodule was preserved.

kbahey figured there had to be a way to do this and, of course, git wouldn't be git if it was possible.

Since it's such a powerful git thing git can quite easily do, I decided to document the process using the above situation as an example. You can easily adjust (and improve please if possible ;-) the process for your own situation.

1. Clone all branches of devel (tell you later why not just the master :-s):

//
Gather concepts about releases, review processes, and other meta-project info... use the child pages for the HowTo. These are still, in general not specific about the git tool in use.
//

Full project overview

Full projects are typical modules, themes, and installation profiles you download from the download and extend section of Drupal.org.

In contrast to sandbox projects, full projects offer the following benefits:

• Human-readable shortname in the URL rather than numeric ID (for example, /project/projectname rather than /sandbox/username/node-id)
• Downloadable releases for end users
• Usage statistics
• Increased ranking in search results
• No Experimental Project warning message on project page
• Project appears in the Main project issue drop-down
• Full support for Drupal Translations

Once you have both obtained basic Git access on Drupal.org and completed a one-time approval process, you have two ways of creating a full project:

The Features module follows the standard installation process – download the module from its project page, put it in your sites/all/modules folder, and activate it from your modules administration page.

The Features module will automatically find compatible modules to work with – no further installations or settings are necessary.