Tracking Wordpress in Git

I finally decided to sign up for github. What prompted me was the desire to upgrade this blog to WordPress 3.0, from its current Wordpress MU 1.5.1. I find that it is much easier to pull in an upstream branch and make my own changes on top if I use git as opposed to subversion. And since importing the wordpress svn repository into git was an overnight process, I decided to share the resulting git repo on github, so others can speed up their own wordpress git import should they ever want to do that. And that is how my first ever github repo became a repo that is just tracking the progress of wordpress. Good enough for a start.

I did not use the default git-svn configuration because it was lacking a few feature I like.

First, my local repo is not using the default git-svn branch to tag mapping. Instead, I configure git-svn to prefix all remote branches with "svn" so they are easy to follow. The "trunk" I also push into a branch named trunk, to make it easy to follow on github. I also configured the github remote repo to simply push all remote svn branches to similarly named proper branches. Tags in the subversion repo also become tags in the local repo. So, the flow is: wordpress subversion -> refs/remotes/svn @ local -> refs/heads @ github. And the commands I have to run to update github are just "git svn fetch" followed by "git push github" and eventually "git push github --tags".

The other cool thing is that with this configuration I can do the syncing with a bare git repo.

And here are the relevant parts from the config of my local git repo:
[svn-remote "svn"]
        url = http://core.svn.wordpress.org
        fetch = trunk:refs/remotes/svn/trunk
        branches = branches/*:refs/remotes/svn/*
        tags = tags/*:refs/tags/*

[remote "github"]
        url = git://github.com/chutzimir/wordpress-svn
        pushUrl = git@github.com:chutzimir/wordpress-svn
        fetch = refs/heads/*:refs/remotes/svn/*
        push = refs/remotes/svn/*:refs/heads/*

Note that I also do not prefix the fetch line of github with "+" because I do not want the two remote repos - subversion and github - to accidentally overwrite the local tracking branches.

Comments

  1. Julián LanderrecheApril 11, 2011 at 8:10 PM

    Hi Chutz,

    Thanks for sharing the tips on how to keep track of an SVN repo by creating a mirror of it using Git. Really appreciated. I'm trying to setup a similar local repo for tracking the SVN repo at Google Code for Textpattern CMS.

    Now, a little request: please, could you try to explain this sentence a bit more:

    "Note that I also do not prefix the fetch line of github with “+” because I do not want the two remote repos – subversion and github – to accidentally overwrite the local tracking branches."

    Not only I'm having a hard time trying to undesrtand it and the "+" syntax, but also, I think your suggested config file on the blog post doesn't match with your suggestion at:
    https://github.com/chutzimir/wordpress/wiki

    There (at wiki), you did prefix the fetch line with plus, running this:
    git config remote.github.fetch '+refs/heads/:refs/remotes/svn/'

    So, could you please shed some light on using plus/non-plus on fetch, and, by now, which is your preferred method (the one on this post or the one on the wiki)?.

    Thanks again.

    ReplyDelete
  2. Julián LanderrecheApril 11, 2011 at 8:10 PM

    One more little question, if you don't mind.
    I've seen both at this article and at GitHub wiki that, for tags, you use something like:

    git config svn-remote.svn.tags 'tags/*:refs/tags/*'
    What's the reason to keep tags at refs/tags/ instead of keeping them at refs/remotes/svn/tags?
    I must admit I don't fully grasp the idea.

    Thanks.

    ReplyDelete
  3. chutzApril 11, 2011 at 11:26 PM

    fetch = refs/heads/*:refs/remotes/foo/*

    "fetch" tells git what refs to take from the remote (the part before the colon) and save them locally under the name given after the colon. refs/heads/bar on the remote will be visible as refs/remotes/foo/bar locally. Normally, the local branch will only be updated if it is a fast forward (if it is an older version of the remote branch).

    fetch = +refs/heads/*:refs/remotes/foo/*

    If you put a "+" in front of the "fetch" value, then the local tracking branch will be updated even if it is not a fast-forward. In other words, an older version of the branch on github could overwrite the newer local branch that I got from subversion.

    The problem is that normally you dedicate one tracking naming prefix for one remote. It's usually called refs/remotes/[remotename]. In this case I am using the same name for svn and github.

    I updated the github wordpress wiki to match this page.

    ReplyDelete
  4. chutzApril 11, 2011 at 11:29 PM

    When they are under "refs/tags" then git will know that they are tags ("git tag" will list them, "tig" will show them in pink color, etc). If they are under "remotes/svn/tags" then they are just like any other branch.

    ReplyDelete
  5. Julián LanderrecheApril 13, 2011 at 10:20 AM

    Chutz, thanks for the reply, it really helped clearing the fog, as it confirms most of what I suspected about this particular way of setting up a git repo tracking an SVN repo.

    Really clever solution.

    ReplyDelete
  6. Julián LanderrecheApril 13, 2011 at 12:12 PM

    Thanks for this one too.

    As I originally initialized and fetched the SVN repo using an slightly modified .git/config file, I ended up putting branches at "remotes/svn/tags", and as you said, those were seen as branches.

    Then, I converted them to real git tags, by running the command on this post
    http://beardedmagnum.com/2009/02/15/converting-git-svn-tag-branches-to-real-tags/

    Problem was that it seems (hopefully, I'm correct about this) I ended up with two tags for each tag: one lightweight and one annotated.

    Luckily, I was able to clean up this mess by editing the .git/packed-refs file and getting rid of the lightweight tags.
    An 'git ls-remote .' displayed a nice list of references.

    Then, the only remaining thing was to push this new list of tags ('git push [remote] --tags') to a few remotes I've got configured and then, ran "git fetch [remote] --tags" on each cloned repo to update to the cleaned list of tags.

    So far, everything seems to be in good shape.

    ReplyDelete

Post a Comment

Popular posts from this blog

Installing Gentoo with full disk encryption

The purpose of this exercise - install Gentoo where all disk partitions are encrypted. Boot from a system rescue disk and partition the disk - use GPT partition table where the first partition is reserved, second is the boot, and the third one is for the rest of the data. Device Start End Sectors Size Type /dev/sda1 2048 32767 30720 15M BIOS boot /dev/sda2 32768 442367 409600 200M Linux filesystem /dev/sda3 442368 375093902 374651535 178.7G Linux filesystem Encrypt partitions number 2 and 3, and open them cryptsetup luksFormat /dev/sda2 cryptsetup luksFormat /dev/sda3 cryptsetup luksOpen /dev/sda2 crypt_boot cryptsetup luksOpen /dev/sda3 crypt_data Format the boot partition mkfs.btrfs /dev/mapper/crypt_boot Prepare LVM for the rest, and format the top level vgcreate vg0 /dev/mapper/crypt_data lvcreate -l 100%FREE -n data vg0 mkfs.btrfs /dev/vg0/data Mount and set up any subvolumes mount /dev/vg0/data /mnt/gentoo btrfs subvol create /mnt/gentoo/@ /mnt/gentoo/@home umount /mnt/gentoo Now
Read more

ADSL Router Model CT-5367 user and pass (VIVACOM)

Writing down the username and password for the vivacom ADSL router, in case I need it again. user: root pass: warmWLspot Useful to telnet 192.168.1.1 and then reboot . Originally found at Neo2SHYAlien blog . And here I found passwords for other models, just in case. ZTE ZXDSL 832 username: root password: GSrootaccess ZTE ZXDSL 831 username: root password: GSrootaccess ZTE username: root password: 831access Huawei SmartAX MT882 username: root password: MT882rootaccess ZTE ZXDSL-531b username: root password: rootWLaccess Pirelli – DRG – A124G username: root password: warmWLspot Comtrend CT-5367 username: root password: warmWLspot HG530 Home Gateway username: root password: warmWLspot
Read more

FreeIPA cluster with containers

Notes on how to install a FreeIPA cluster on Ubuntu. Mostly following the instructions on https://github.com/freeipa/freeipa-container Start with what would be the primary host. If you install a third replica you would want to review the replica agreements to ensure you have a two-way replication between all pairs of nodes.
Read more