This means you can use the Drupal Git repository (sounds like a fun place) as the pristine version and clone or branch it into other sites. I’m not to sure if having the entire Drupal tree is a good idea though, since Git will pass the whole history from clone to clone. It makes it ridiculously easy to switch drupal versions for testing.

The best thing about this method is that it doesn’t break the update status module like working with a cvs checkout does.

fixed! stupid wordpress.

results in this error:
tar: You may not specify more than one `-Acdtrux’ option

Urgh. That’s the line that’s supposed to make all of this worthwhile :-P

(I have read the tar man page more times than — ah, I got it. It needs to be doule-dash for a long-form command!)

Needs to be:

$ tar --strip-components=1 -C drupal -zxv -f drupal-5.2.tar.gz

in short: merging will be much more tedious and error-prone.

In Git, merging really works like a charm.

In Subversion — wait for 1.5 where repeated merging will be much more integrated.

I believe that for tutorial my approach of multiple clones is much more accessible.

First, it’s easy to “screw up” the repository if you’re doing heavy branches here. My target audience is not Git experts, so they will have trouble if mental model is out of sync with the repository state.

Second, you will usually have several sites under this scheme, and it’s easier to just rsync the directory without worrying which branch is currently checked out there.

Third, I have to admit with a shame that I do not completely understand how branches work in Git — I just didn’t have the chance to use it in production.

thank you for bug reports — I’ve fixed them all.

I believe you should use the new submodules features in Git 1.5.3. You would create ordinary Git repository with your development module, using git-cvsimport for tracking the CVS repository.

Then you would use this repository as a submodule of your drupal-and-modules repository.

Tutorial is available: http://git.or.cz/gitwiki/GitSubmoduleTutorial

So, the changes will flow 1. from Drupal CVS to your module repo; 2. from your module repo to the drupal-and-modules. When you’ll commit something of your work to the Drupal CVS, I guess everything will just merge automatically.

I think using branches, instead of repository clones, for drupal, drupal-and-modules and drupal-production would be more natural to git. For example, you would create the original git repository exactly the same way, but instead of “git-clone drupal drupal-and-modules” you would simply stain in your “drupal” repository and create a “drupal-and-modules” branch:

git checkout -b drupal-and-modules

You would then branch off again for drupal production:

# from your drupal repository on the drupal-and-modules branch
git checkout -b drupal-production

Then, when you need to upgrade drupal, you just checkout the master branch

git checkout master

Perform the same upgrade steps, then merge to the other branches when you’re ready.

The commit command doesn’t seem to repeat the directory just added, but should just be:

git-commit -m “Adsense 5.x-1.6 imported”

First, the directory ‘modules’ must be created (in Drupal 5)

mkdir sites/all/modules

Second, it is ’sites’ not ’site’

cd sites/all/modules