[wp-hackers] Using Git for tracking multiple disparate sites
Scott R. Godin
scottg.wp-hackers at mhg2.com
Wed Jan 27 16:28:30 UTC 2010
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:
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:
> * 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
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
Fedora 11's git came with the following:
which I copied over to
and then made the following changes to the hooks (as outlined inside
that perl file): post-merge, post-checkout,
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
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
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)
More information about the wp-hackers