Mikkel Høgh

[HTML_REMOVED]Excellent[HTML_REMOVED]

Thanks a lot for this! I am just learning Git, and am about to replace my SVN repository with this superior system.

Like Jakob said in the dev list, this is a good test case for the new Git backend for the Version Control API (http://drupal.org/project/versioncontrol_git) as well :)

Wow!

I use git to mantain any drupal module I change, especially my organization [HTML_REMOVED]specific API dependent[HTML_REMOVED] ones.

I like git a lot, and it's awesome you make available a git repository of the Drupal CVS repository. Thanks.

I've shocked after: $ git checkout start

PD: sorry about my bad english

OMG

This is cool, thanks.

Running the command : git checkout dccf64caa5b490dfa314d7dbbad067842ee65865 gets the current 5.7 release, add your favorite modules commit it, clone it for a new site. Repeat for Drupal 6.2.

Is it possible to get use the Drupal CVS tree for contributed modules and themes? How would you go about pulling in the changes for them? I'd assume you would need a GIT repository for every module within the main Drupal Repo? Would it be a git-cvsimport for each module and theme?

Is there a specific command for getting the latest stable release of a branch eg 5.7 or 6.2? Do you host the whole repository on a live site so that you can 'git push' changes to them, or is it better to keep the Repo local and sync manually?

Sorry for so many questions, this seems better than the mess of SVN & CVS.

Thanks for the info

I was considering creating a repo for each of the contributed modules I regularly use (there is about 20 of them). My version of GIT is installed from the Google code package for Mac OS. It seems to be lacking the cvsps tool, so I cannot do a cvs import, assuming the command & url I tried were correct …

git-cvsimport -v -d:pserver:anonymous@cvs.drupal.org:/cvs/drupal -r /contributions/modules/admin_menu -o upstream admin_menu

I should try the manual install again, but I don't seem to get far with them.

I was thinking I could use something along the same lines as posted here http://www.aidanf.net/node/133, but by using the actual git-cvs imports for each module/theme I could automate the task of updating the modules by a simple. git fetch and git checkout origin/VERSION within the correct repo. Then pull that into the repos for the actual sites. It sounds like it could be a way to manage multiple site upgrades.

There is also a base Drupal repo that is setup prior to all of the above so that Drupal updates can be done cleanly and pulled into the other repos. Maybe it's all insane, but manually managing more than one site gets time consuming.

You would end up with something like this…

Drupal base repo (Pristine install of latest Drupal)

Drupal and Modules repo (stuff you use on every site)

Production site repo (Just the site specific modules & files)

It could all be done with git branches, but its better if you separate them since the directories containing the repos can be set in the apache vhosts and given clean urls to do any testing, eg to run update status module on the Drupal & Modules repo site.

Perhaps I have to much time on my hands :)

PS The GeSHi library show a (nicely pulsing) error when previewing comments, I suspect permissions :)

Permissions indeed…

I didn't check properly when last fiddling around with the Geshi tarball. Which for some reason have some pretty draconic permissions built in. sigh.

Thanks for the input :)

When it comes to playing with Git on the Mac, I can recommend MacPorts which conveniently have a package for cvsps.

I have a cron-script

I have a cron-script that does the work for me – it looks like me:

[HTML_REMOVED] cd ~/git/drupal.git git-cvsimport -v -d:pserver:anonymous@cvs.drupal.org:/cvs/drupal -o upstream drupal git-push --mirror /var/www/lion47/git/drupal.git/ cd /var/www/lion47/git/drupal.git git-update-server-info --force [HTML_REMOVED]

Only the first two lines actually deal with the original import – the rest takes care of pushing it to my public Git mirror.

I concur…

Yeah, unless you really have to, I suggest you get your Drupal-git from me. I suppose the Drupal CVS server is hard pressed as it is.

As an aside, I've just moved git.lion47.com to another server, since I'm moving away from my current webhost. You shouldn't notice it, but in case anyone wondered about the new IP-address, here's why.

Yeah, it’s a bit

Yeah, it's a bit confusing, but the branches are namespaced in Git, as to indicate where they are coming from. Thus, if you want the DRUPAL-5 branch, do a [HTML_REMOVED]git checkout origin/DRUPAL-5[HTML_REMOVED].

If you want a specific version, tags have no prefix, so checking out a tag is like [HTML_REMOVED]git checkout DRUPAL-5-10[HTML_REMOVED].

happen in a hurry

Yeah, I can't help be exited about distributed SCM's. I've only recently started to use Git, but I think it rocks. I only hope we could convince the Drupal community to switch, but that probably won't happen in a hurry.

added to drupal.org handbook

I listed your git repository on a page I added to the drupal.org handbooks on [HTML_REMOVED]Alternative VCS mirrors of cvs.drupal.org[HTML_REMOVED]. It lists mirrors for Bazaar and Subversion as well.

Proper technique for upgrading?

I started by cloning the aforementioned repo. Then created a branch called production:

git checkout -b production DRUPAL-6-12

Going to 6.14 was easy.

git merge DRUPAL-6-14

But if I got to DRUPAL-7-WHATEVER, I get a ton of conflicts. I am not an expert with git, i have pulled off similar feats with subversion doing vendor drops, but that is a lot more effort if I can make this work.

Any thoughts? Additionally I am working on including contributions of submodules into the mix which might require a lot of sub merging.