Update 19 December 2010: Our git.drupal.org repositories are now updated within 5 minutes after a commit, making this workflow far more usable. All thanks to @neclimdul who bulldogged this to the ground.
Even though the Drupal CVS to Git migration will take a few more months, it's possible to start using git now for nearly everything you used to do. sirkitree challenged me to write down my workflow the other day so we could compare and contrast.
I write this not because it's the only way to do it, but to encourage people to start the git migration and to start a conversation about transitional workflow. And maybe I can get some hints about how to do it better! But I'm quite happy with how this works. When you comment and suggest your alternate approach, please try to point people toward things that will work in the long term in the Git migration.
I encourage you to start migrating to git now. It will make the migration so much easier if you already have the basics working before we get there.
First of all, we already have a git mirror at git.drupal.org. There are lawyer-notices on the web-view at http://git.drupalcode.org that say that it might go away (or more likely, have its hashes invalidated) but in my opinion, the risk that this will hurt you or me if it happens is not very high.
The git repositories at git.drupal.org are at git.drupal.org/project/whatever. So if you want to clone the Examples project, it's
git clone git://git.drupal.org/project/examples. Cloning core (the drupal project) would be
git clone git://git.drupal.org/project/drupal.
So how do I use this for real work on core and contrib? Easy. Everything but committing works, and committing is something I do less often than all the other parts of the workflow.
I'm not going to show every detail or nuance, just the basics of what I might do on an ordinary day.
Contrib or core patch workflow as non-maintainer (not committing via CVS)
I'll use devel module as a working example:
- One time only: cd into sites/all/modules and
git clone git://git.drupal.org/project/devel
- cd into devel and (if you're not working with CVS HEAD) switch to the correct branch. I'll find out what branches are available and then create a tracking branch (one that can be updated with git pull) for 6.x:
git branch -r
git checkout --track origin/6.x-1.x
- Now let's say that I have an issue I want to work on, maybe #866608 about a devel_generate fatal in a particular situation. Let's assume there's already a patch in #4 of that issue (by somebody else) that I'm going to work from. I'll create a branch for that, off of my 6.x-1.x branch.
git checkout -b devel_generate_866608/04(There's no magic in the name of that branch. It's for me to figure out why I made the branch.)
- Now I'll download and apply the patch. We'll say it's at http://drupal.org/files/dummy_demo.patch (I always right-click to copy the link, then
wget --directory ~/tmp http://drupal.org/files/dummy_demo.patch). In the devel directory, I now
patch -p0 <~/tmp/dummy_demo.patch
- Now I'll commit the patch:
git add .
git commit -m "Moshe's #4"
- I might now create a new branch for the work I'm about to do on #15:
git checkout -b devel_generate_866608/15
- And now I'll do some work on the module, fixing whatever I need to fix.
- Now commit the work I've done:
git add .
git commit -m "Fixed up the problem, will upload this as #15"
- Now create a patch:
git diff --no-prefix 6.x-1.x >~/tmp/devel.fatal_866608_15.patch
- And upload the patch into the issue queue
Now when I need to do this again and take up work on it, because something has happened in the issue queue, I can either start with my existing branch (or branch from it) or I can do the same basic steps again to use somebody else's patch:
- Create a branch off of 6.x-1.x (maybe named
devel_generate_866608/22for #22 of that issue).
- Apply and commit the patch
Everything else is the same. I can compare branches to see exactly what changed:
git diff devel_generate_866608/15
(Note that if other things had been committed to devel in the meantime I might have to go to devel_generate_866608/15 and
git merge 6.x-1.x first, so that only the things actually moving in this issue show up)
Maintainer patch workflow
As a module maintainer, it's all the same, except that when the time has come to commit a patch, I make a patch and instead of uploading it in the queue, I apply it to a CVS workarea and commit it using whatever CVS tools. That's the only exposure I have to CVS these days.
I have to confess there's one thing about using git.drupal.org as a module maintainer (committer) that doesn't quite work for me yet. The two-hour update of the git repo isn't fast enough when I'm trying to solve some kinds of problems, and I end up using a private git mirror that has a 5-minute refresh. (I use sdboyer's drupal-git-scripts still on a private mirror.). There is an issue open to make updates of git.drupal.org much faster and hopefully I can then completely ditch my private mirror.
Lots of smart people have already written on Drupal.org about how to use git in various ways, and there's lots to learn from these articles: