[wp-hackers] Using Git for tracking multiple disparate sites

[Scott R. Godin]

On 01/27/2010 03:06 AM, Eric Marden wrote:
> Since WP is hosted in SVN, the cleanest way is pulling WordPress and
> plugins via svn:externals and custom wp-config.php settings (see:
> http://codex.wordpress.org/Editing_wp-config.php). This makes it
> possible to update everything via an "svn up".

This was good, as it led me to this: 
<http://codex.wordpress.org/Converting_Database_Character_Sets> which 
was _extremely_ useful to know about so as to avoid problems.

> I've started to switch to git last year myself but haven't found a
> 'great' way of emulating this process in this SCM. A couple of things
> I've tried:
>
> * Layering the git working copy over the svn working copy (using
> .gitignore & svn:ignore to keep the SCM files out of each other's
> respositories). I blogged about shared working copies here:
> http://wp.me/pgTiu-8h
>
> * Pulling in WordPress core via SVN, which is stored in the git
> repository (similar to above, but less 'global')
>
> Both of these approaches paled in comparison to a full SVN set-up. You
> may also want to investigate git submodules (which I believe are
> similiar to svn:externals) as well as taking a look at git-svn, which
> has some tools for using git as front-end to an SVN repos.
>
> I love git, but mixing SCMs adds overhead to the workflow that may prove
> more cumbersome than beneficial.

one presumes you've seen this? <http://git.or.cz/course/svn.html>
the git - svn crash course for people used to svn and how to leverage 
your familiarity with svn to get you familiar with git's way of doing 
things.

I was somewhat lucky in that I'd not really worked with any other VCS's 
before so I didn't have a whole lot to unlearn.

there was one thing that I felt I needed to set up with git before 
working with a website's pile of files that needed to preserve certain 
permissions on files and/or directories that needed to remain writeable. 
Fortunately someone had already laid the groundwork and it shipped with 
git.

Fedora 11's git came with the following:
/usr/share/doc/git-1.6.2.5/contrib/hooks/setgitperms.perl
which I copied over to
/usr/share/git-core/templates/hooks/setgitperms.perl

and then made the following changes to the hooks (as outlined inside 
that perl file): post-merge, post-checkout,
	$GIT_DIR/hooks/setgitperms.perl -w
and pre-commit
	$GIT_DIR/hooks/setgitperms.perl -r

This will preserve file permissions on the directories that need to 
remain writeable without having to set up a Makefile to reset all these 
whenever you rsync the files to the server

Additionally making git ignore linefeed changes made it simpler to 
compare various files between versions and the client files:

add the following to your ~/.gitconfig

[core]
     	autocrlf = input

after which you can git init, to set up your repos.

the permissions stuff is necessary due to the fact that git is designed 
to work more with program source code and thus only tracks +x/-x and not 
rwxrwxrwx

Nothing like killing a commit and backing up a step only to find that 
all the files in the directory have reverted to match the umask setting 
in your shell, rendering the development install useless for testing. 
This prevents that problem from happening.

-- 
(please respond to the list as opposed to my email box directly,
unless you are supplying private information you don't want public
on the list)