Almost exactly one year ago today, the Drupal community reached consensus to migrate our version control system from CVS to Git. Today, the Git migration team is extremely pleased to announce that we are officially open for community testing in advance of our proposed launch date, February 17 February 24! Just in time for DrupalCon Chicago!

All of our work is hosted at http://git-dev.drupal.org/, our staging environment for the CVS -> Git migration! Here's how YOU can help test.

Important: READ ME FIRST!

Because during this pre-launch period we're also going to be doing performance optimization and integrating new code to fix bugs, here are some important things to be aware of:

  • Watch a screencast explaining how the new infrastructure works.
  • Testing will only be open during certain hours of the day. The Git Migration Community Testing Wiki contains the current status of the system as well as rebuild schedules, and a calendar which tells the times during which testing is open. When testing is open, you'll see an Apache password prompt (which prevents Google from indexing the site) that looks something like this:
    Apache password prompt indicates we're open for testing!
  • To log in to http://git-dev.drupal.org/, you must first reset your password.. This is a basic security precaution for our development sites. You can do this from the Request new password page. You’ll need to do this anytime git-dev has been rebuilt.
    Request new password screen.
  • All users, including current CVS account holders, need to agree to terms of use in order to obtain Git access. There are instructions for doing this at http://drupal.org/node/1047190. You'll also need to do this any time the server is rebuilt. Note: Click on the "Logged in as username" link to see the choices below.
    Navigate to the Git access tab.
  • The server will be rebuilt every two days. Each time that happens, you'll lose any projects and code changes you made, and also need to repeat the "reset password" and "agree to git terms" steps again in order to continue testing.
  • If you find problems, please log them against the Git Migration Community Testing issue queue. Make sure whatever you're reporting doesn't show up in our list of known issues first. One of our team members will receive reports and then push them into the correct issue queue, if necessary. There is also a #drupal-gitsupport channel on irc.freenode.net for new Git users (and experienced Git users who want to help make the transition as smooth as possible :)).

Got all that? Great. Here's what you can do on our new shiny Git architecture.

Getting started

Before starting, you must reset your password on git-dev.drupal.org, since the passwords have been masked there.

  1. Visit http://git-dev.drupal.org/user/password and submit the form.
  2. Check your e-mail for the link, log in, reset your password.

Now we start the actual Git setup.

  1. Visit http://git-dev.drupal.org/user
  2. Click the Edit tab
  3. Visit the "Git access" secondary tab
  4. Read and agree to the Git Access Agreement
  5. If you did not already have a CVS account you'll be asked to accept or change your desired git username. (If you already did have a CVS username and want to change it, see https://drupal.org/node/1036140)
  6. Optional: Visit the "SSH Keys" tab and add a new key by pasting your public key into it. (If you don't already have an ssh keypair, instructions are at http://help.github.com/key-setup-redirect)

Creating projects

With that we have enough set up to create a sandbox project.

  1. Visit the "Your Projects" tab, which will have have projects only if you're the owner of projects on Drupal.org.
  2. Click the Add a new project link (http://git-dev.drupal.org/node/add/project-project)
  3. Fill in the requested information making sure that the "sandbox" checkbox is checked. (If you didn't have the "Git vetted user" role, equivalent to CVS access permission, it would be checked and disabled.)
  4. You now have a sandbox project.

Now we can add files into the repository.

  1. Visit the "Git instructions" tab and follow the instructions there.
  2. Do and push additional commits as you see fit.
  3. View your commits on the project page "View commits".

Note: It's not possible to create releases on a sandbox. To create releases during testing, you must have an existing CVS account.

For those who have existing CVS accounts, you can now repeat the same process with a full project.

  1. Click the Add a new project link (http://git-dev.drupal.org/node/add/project-project)
  2. Fill in the requested information making sure that the "sandbox" checkbox is not checked.
  3. Use the "Git instructions" tab to help you create some files for the repository and commit them.

Create a project release:

  1. Tag the commit: git tag 7.x-1.0
  2. Push the tag: git push origin 7.x-1.0
  3. On the project page, click "Add new release" and choose the 7.x-1.0 tag as the base for the release
  4. Wait for the new release to be created
  5. Download the tarball or zipball and view the contents

And that's about it! Pretty spiffy, eh? :)

Of course, if everyone tested the above steps we wouldn't find any launch-busting bugs. ;) So please, also help us find edge cases. Remember to think outside the box as you go through, particularly if you're a more advanced CVS/Git user. Experiment. Try creating a feature branch that doesn't follow naming conventions. Try pushing multiple commits at once. Try to think of weird places we use version control data that might still have issues. Test your own projects and ensure their logs were parsed properly, and tarballs contain what they should.

FAQs

Are my code changes going to be saved when we migrate over?
Nope. All code changes will be wiped every 48 hours or so. Feel free to practice as much as you'd like, there's no fear of screwing something up!

I pushed a commit and it's not showing up. What gives?
Check http://git-dev.drupalcode.org/ to see if it's a bug with the Drupal.org log parser or a bug with Git.

Also, make sure that you've set your global git config variables to an e-mail address that's associated with your Drupal.org account. Otherwise, your commits will not be credited to you.

I checked the "I agree" box, but I still can't create projects. Why does it hate me?
The form under the "Git access" sub-tab is actually a two-step form; one step is agreeing to the terms of use, and another is specifying your desired Git username (which defaults to your drupal.org username). Submit the form a second time and you should be good to go!

Help us!

If you know Git well, please hang out in #drupal-gitsupport to help new users. Please help review issues in the git community testing queue, help solve support issue, clean up duplicates, improve the reports, write or improve the documentation, etc. We need all the help we can get in order to make this as smooth a transition as possible! Once Git goes live, CVS is dead, dead, dead. Hooray!

Comments

Upgraded my CVS account and committed some things to my existing projects including new branches and releases. All works really well.

Will have a go a creating some sandbox projects and 'upgrading' them.

Smashing job fellas. Long live GIT

Now time to take up that once in a lifetime offer...

Jordan

So I don't have a drupal cvs account but I submit patches and it would be a lot easier for me to do this if I can clone someone's project and make my changes there.

I noticed that the drupal git server is open for user testing.

Will these repositories be open to people like me?

As far as I'm aware you'll able to clone any project. You just won't be able to commit back until you have privileges. So you'll have submit patches as usual once you have your desired tweak pinned down.

Jordan

The goal as I understand it is that anyone can fork any project (but their fork will be a "sandbox" unless it gets upgraded later) and there will be Github-style integration between issues and branches so there's no more messing around with patch files.

Initial launch is a straight CVS -> Git migration of our existing tools. So we still need to upload patches for the testbot, patch reviewers, etc. There are instructions for how to do this on each project on the "Git instructions" tab.

After launch, though, we'd like to roll out additional collaboration tools, including per-issue repositories, better source browser / issue queue integration, etc. Some initial plans are brewing under the git phase 3 tag. Feel free to propose your own. :)

Cool. I think this will definitely be a substantial improvement over the current process.

While this is all correct, note that thanks to the distributed nature of git, you can still implement some other workflows than using patches.

Everyone will be able to clone the project, which downloads the history to your local computer and then do local commits, branches and whatever you want. But You will not be able to push these changes back to d.o unless the maintainer gives you the rights to do so.

However, you could for example push your changes to github (or any other place you want to) and inform the maintainer about that. Then, he could add that as a remote to his own local repository and directly import your changes, preserving the commit history if he wants to.

Of course, that's not perfect solution, there is no automated testing integration for example and you can't review the changes directly on d.o. But it might be a viable solution for some stuff like a large refactoring, or porting a project to another core version until phase 3 is here.

We're actually recommending using sandbox projects for this sort of "major refactoring" use case. See the Sandbox collaboration guide (still heavily in progress).

Actually GIT doesn't work with privileges like CVS, you just have read-only access to any project, project maintainer can pull your work but you can't push untill he gives you read+write url.

I think this is a bit misleading, so let me clarify:

  • Git does have a very, very different permission model than CVS, but the workflow on d.o is almost the same as its ever been for getting access - add someone as a maintainer, and they can send in code.
  • Thus, the barrier isn't "getting the read+write url" - the write URIs (which are just the ssh uri, e.g., sdboyer@git.drupal.org:project/drupal.git) are in no way secret. In fact, you can use them to make anonymous clones over ssh even if you're not a maintainer. They'll only become writable if & when you're granted maintainership (and "Write to VCS" privileges) on the project.

and... s/GIT/Git/ :)

> click the "Edit" tab, and the "Git access" sub-tab.

There is no subtab for that on my account.

Where do we file bugs for this process? I've filed http://drupal.org/node/1050470 but no idea if that's the right place!

From the post:

If you find problems, please log them against the Git Migration Community Testing issue queue.

So yep, that's the right place.

Boring normal test case - successful! You don't know how awesome it is to finally have that nagging CVS thing out of the equation. Now I can just push straight from Git instead of having to git drupalcommit blah blah blah, git cvsexportcommit something something on the Git repo that is a clone of the CVS repo, git reset --hard HEAD~1 on the cloned Git repo of THAT one (my working copy) and then finally git pull to re-sync the working copy.

Now it's like...pull...work...commit...push...git awesome, basically.

Looking forward to this going live!

- Signed: A module maintainer

WizOne Solutions - http://www.wizonesolutions.com - Drupal module development, theme implementation, and more
Fill PDF Service - http://fillpdf-service.com - Hosted solution for Fill PDF

lol...I must admit, I don't think I've ever been happier to have my work called boring in my life :)

And yeah, I've invested so much work in a functional local git workflow I'm almost going to miss my git commit; drupal-git-cvsexportcommit; git pull --rebase solution.

...right until the moment I push my first topic branch to d.o. HOT DAMN!

Haha, nah, the work you guys did was awesome. I was more saying that I didn't really do much edge case testing myself.

I for one won't miss CVS at all. And somebody can finally edit that handbook page everyone's probably using to simply say, "CVS? No CVS here."

:)

WizOne Solutions - http://www.wizonesolutions.com - Drupal module development, theme implementation, and more
Fill PDF Service - http://fillpdf-service.com - Hosted solution for Fill PDF

I just want to register my pleasure at seeing this stuff in action- it's *awesome*. Huge thanks to all members of the Git migration team for all the hard work moving this process along. From a brief round of testing this morning (will do more when testing re-opens), everything looks great, and I'm very excited to be (almost) completely rid of CVS :)

I'm a little bummed though that I can't find an issue. The whole process seems to work so smooth. Thanks to the migration team for a great product.

Just to let folks know, the Git Migration Team has decided to delay launch for another week. The new date is February 24.

Read more here: http://groups.drupal.org/node/127394

Where is the code running all of this (git-dev.drupalcode.org)? Or up to date docs on the server stack?
I can't seem to find anything authoritative. I'm assuming its all still GPL'd (like previous drupal.org stack)

Wow great work Git team - I'd just like to thank you all for the amazing work you have done, really really great stuff, so I lost some commit history from my projects but frankly I don't care (and probably my own error) - its just so good to be using Git - its already making my like easier. Thank-you again, I really take my hat of to you super smart peeps.