Smokes your problems, coughs fresh air.

Tag: Git

Git and Tig config base

Here’s just a quick .gitconfig:

        commentchar = %
[tig "color"]
        date = cyan black bold
        diff-header = cyan black
        ignore-case = yes

The colors are to make it readable on Windows Git Bash, because the dark blue is impossible to read.

And yes, I still have to set up my dotfiles github stuff.

Converting a Subversion repository to Git

I just used the instructions in this article by John Albin to archive an old svn project on my private machine.

A shell summary (see the John’s article for details):

svn log -q | awk -F '|' '/^r/ {sub("^ ", "", $2); sub(" $", "", $2); print $2" = "$2" <"$2">"}' | sort -u > authors-transform.txt
vim authors-transform.txt
# Make changes
git svn clone [SVN repo URL] --no-metadata -A authors-transform.txt --stdlayout ~/temp
git svn show-ignore > .gitignore
git add .gitignore
git commit -m 'Convert svn:ignore properties to .gitignore.'
git init --bare ~/new-bare.git ~/new-bare.git
git symbolic-ref HEAD refs/heads/trunk
git remote add bare ~/new-bare.git
git config remote.bare.push 'refs/remotes/*:refs/heads/*'
git push bare
rm -rf ~/temp
git branch -m trunk master
git for-each-ref --format='%(refname)' refs/heads/tags |
cut -d / -f 4 | ref
  git tag "$ref" "refs/heads/tags/$ref";
  git branch -D "tags/$ref";

John has also put all this into a number of scripts published on GitHub.

Tracking /etc/ updates with Git

During my recent Gentoo update session, I was once again confronted with the inconvenience of not having my /etc/ directory under version management. This time, I thought I had the ideal SCM for this job: Git.

I found a blog post of a chap who has done the same. It includes a few notes I might not have thought about on my own and also a few very cool Debian tricks.

One of the steps that I might have overlooked myself is that it’s essential to make the .git directory group/world inaccessible with chmod go-rwx. If I would have forgotten this, a smart attacker might use my Git repo to access forbidden file contents.

The author also describes a cool Post-Invoke for Debian’s dpkg that will automatically stage and commit configuration changes made by apt/dpkg (although, later, he mentions that Debian has gotten a package could etckeeper that does this automatically.

Now I would like to learn how I can let Gentoo’s etc-update do as much. In its /etc/dispatch-conf.conf I can only find the option to use (of all things) RCS to track replaced configuration files in a special directory (/etc/config-archive/ by default). Hopefully, there is some drop-in replacement for etc-update which does this and which can rid me of etc-update’s awkward interface at once.

Untangling WordPress’ core files from your local customizations

Since version 2.6, WordPress can be installed in its own directory, separate from your customizations and everthing. Needless to say, this makes upgrading a whole lot easier.

If, in the pre-2.6 days, you wanted to fetch your WordPress updates through SVN, the docs would advice you to do an svn checkout from the official WP SVN repo in your working dir and then do an svn update whenever you want to update WordPress. This works because svn update leaves local modifcations alone. However, this means that you’ll be unable to commit your local changes (configuration, themes, plugins, etc.) if you choose this route.

I used my own subversion repository for my blogs and thus had to upgrade the old fashioned way with each release (although I prefer diff/patch over rm/cp). (I could have used vendor branches, but, clearly, I hadn’t thought about that at the time.) This was pretty much a royal pain in the ass, so I was glad when I could move WordPress into a separate directory with its 2.6 release.

This process consisted of removing everything except wp-content/, wp-config.php, .htaccess. (I also kept robots.txt, favicon.ico and some other personal files.) Then, I added the current WordPress release as an svn:external.

svn propset svn:externals 'wp-factory' .

.htaccess changes

In the WordPress codex, it is then suggested to copy index.php to the root dir and to change it to require wp-factory/wp-blog-header.php instead of ./wp-blog-header.php. I preferred adding some mod_rewrite voodoo of my own to .htaccess, so I did:

<IfModule mod_rewrite.c>
# This way I don't need directory indices
RewriteRule ^$ /wp-factory/index.php [L]
# This way WordPress can manage its own block without doing any harm
RewriteRule ^index.php /wp-factory/index.php [L]
# Allow easier access to /wp-factory/wp-admin/
RewriteRule ^wp-admin http://%{HTTP_HOST}/wp-factory/wp-admin/ [L,R=301]

The middle rule performs most of the magic. It redirects all the requests to /index.php to the factory default index.php. This means that I can let WordPress pretend that index.php does live in the root, so I don’t have to modify the rewrite rules that are managed by WordPress itself:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress 

wp-config.php changes

In Giving WordPress Its Own Directory in the WordPress Codex, it is suggested to change the “siteurl” and “home” options through the administration panel. In my case they would have to be changed to “” and“. I couldn’t do this because I override these with WP_SITEURL and WP_HOME in my wp-config.php. This is because I configured WordPress to support a development environment separate from the live production environment.

Ignoring the customizations for my development environment, these are the relevant settings in wp-config.php:

define('WP_HOME', '');
define('WP_SITEURL', WP_HOME . '/wp-factory');
define('WP_CONTENT_DIR', dirname(__FILE__) . '/wp-content');
define('WP_CONTENT_URL', WP_HOME . '/wp-content');

BTW: I really like it how WordPress disables the form controls for siteurl and home when you override these settings in wp-config.php. Kudos for that, devs!

Next time: git

In the end, this is all quite a bit of pain to compensate for what is essentially a version management problem. That’s why, on my newer projects, I’m now using git which makes forking and tracking an upstream repo absolutely trivial. 🙂

A few references

© 2024 BigSmoke

Theme by Anders NorenUp ↑