About a year ago a friend asked me why I chose the Ubercart/Drupal combo as the engine for Cool Cavemen’s online shop. He specifically asked me why not choose Magento or osCommerce. I never really took the time to answer him. Let’s fix this.

First, I selected a couple of web eCommerce solution based on the same requirements upon which I choose WordPress some years ago. Namely:

• Open-source free software
• Active project
• Healthy community

I excluded osCommerce right away. I quickly played with it in 2005 and in 2007 for projects that never came to fruition. And I keep a really bad memory of these experiences: both code and templates felt poorly designed and implemented. That’s why osCommerce is classified in my brain as a giant legacy code base, hard to maintain. Maybe the project has evolved a lot since then. I should have looked back at it, but was attracted by another project…

…which was Magento. So yes, I seriously considered to use Magento at some point. It looked great. And clean. But digging deeper I found that something was missing.

My shop was supposed to sell tee-shirts for the band. And a tee-shirt is a product that can have lots of variations:

• different colors (white, black, yellow, …),
• of different sizes (S, M, L, X, XL, …),
• in different shapes (teeshirt, hoodie, sweatshirt, …),
• for different peoples (guy, girl, baby, …).

I wanted to track stocks and prices for each combination. And this degree of complexity is not supported by Magento. To be fair, I remember to have heard of this feature, but was only available in a third party module (that I don’t remember the name). Alas, this module was proprietary. That is the main reason I discarded Magento.

And then I found Ubercart, which allowed me to do exactly what I wanted. Here is for example prices and stocks for a black Cool Cavemen tee-shirt:

I use Ubercart since 2008 and I’m really happy with it. The future is interesting, as Ubercart was forked as the Drupal Commerce project a year ago. I’m waiting for the 1.0 release of the latter to decide if it is worth switching to the fork or not. But having it based on Drupal 7 is good news, as Ubertcart still stick to the (old) Drupal 6.

This week I’ve decided to put my work on Cool Cavemen’s concert videos aside, and work instead on refreshing our online store. After all, fans are requesting this, so I can’t escape my duty…

The theme the store is based on is Drupify, an adaptation of the RokWebify Joomla theme. All these themes are licensed under the GPL, so I have to share all my modifications with the community. This is a great opportunity to seriously experiment with Git (at last !).

Here is my plan:

1. Make an exact copy of Drupify’s code base in my GitHub repository.
2. Hack it in this playground.
3. ???
4. Profit !

Problem: Drupify lives in a CVS repository.

Solution: Git features a cvsimportcommand.

Before going further, we need to install cvsps. For MacPorts users, this is as simple as:

Then we create a temporary copy of Drupify’s CVS repository:

The new Git repository automatically created is named drupify-copy. Here is how it looks like in GitX (notice tags and branches):

To keep things clean and tidy, I want to relocate all the content of this repository to a drupify-forkfolder. Inspired by Pedro Melo, we’ll use the git
filter-branchto do this job:

The command we just used alter all the commits, in a way that let Drupify act as if it was located, since the beginning of its history, in the drupify-forksub-directory.

By default, filter-branchcreates a backup of the tree using references prefixed by refs/original/:

We’re not the only ones to not see through this mess. GitX seems to be confused too:

But according Jakub Narębski on the Git mailing-list, we can safely removes Git’s backups:

After the cleaning, references are back to normal:

We can then fire up GitX to get the ultimate proof that the relocation operation didn’t change anything, but the base folder (and SHA hashes):

It’s time to import all this code in our main repository. First, get a local copy of our public GitHub code base:

Now let’s include our temporary drupify-copyas a tracked remote repository:

As you can see, all the little particularities of the remote repository are well tracked (HEAD, branches and tags are there):

Another way to check this is to list all tracked remote branches:

It’s time to merge all our tracked remote code (from drupify-copy) in our local repository (kev-code). The branch I’m interested in is DRUPAL-6--1, as it holds the latest Drupify code for Drupal 6.x:

We can remove the attached drupifyrepository and its local drupify-copysource:

At this stage, here is what our repository looks like:

To keep all the details that were created by git cvsimport, we can add by hand all the missing refs. The only difference with the original ones is that I unified the namespace with a drupify/prefix:

And finally, we can contemplate our work:

This let me work cleanly on the CVS branch I wanted to in the first place. But there is one missing thing: all other tracked remote branches were not merged properly. I really wanted to import all of them (especially the DRUPAL-5branch), to keep a perfect copy of the original CSV tree. But I failed to find a way. Does anyone have a clue ?