I’ve been putting off learning git. I’m lazy, svn works fine what what I need, and … oh. Look. MediaWiki switched to git. This is a problem for me, because I upgrade my MediaWiki install via svn. When it comes time for a new version, I just run something like svn sw http://svn.wikimedia.org/svnroot/mediawiki/tags/REL1_18_1/phase3/ ~/www/wiki/ and I’m off to the races. But now I have to git off my ass and learn it.
Before someone asks, I use svn to update my code because I like it better than wget-ting files, unzipping, and copying over. I can certainly do that, but I prefer svn. It runs fast, it lets me see what changed, and it’s easy for me to back out, just by switching back to the previous version. It never touches my personal files, and I’m happy. The more I looked at git, and how it works, I started to wonder if this was a practical idea for upkeep anymore.
Now, I actually like git for development when you’re working with a team. It’s great. So any posts about how I’m stupid for wanting to do this weird thing will just be deleted. Constructive or GTFO. The rest of this post details the journey of going from ‘This is what I do in svn, how do I replace it with git?’ The tl;dr of it is that I can’t.
What I want to do
I want to check out a specific branch (or tag) of code and upload it to a folder called ~/www/wiki/
That’s it.
The road…
First up, I have to install git on my server. Unlike SVN, which has been bog-standard on servers for a hog’s age, git is the new kid in town, and the odds are it’s not on your server. Thankfully, my host had note perfect directions on installing git on CentOS 5.(I’ll probably upgrade to CentOS 6 this summer, when my sites are less busy.)
Second I have to ‘install’ the git repository. This was weird. See, I’m used to svn, where you check out code, use ‘svn up’ to upgrade it, or ‘svn sw URL’ to switch to a new branch/tag. The official directions for gitting MediaWiki were: git clone https://gerrit.wikimedia.org/r/p/mediawiki/core.git
That doesn’t tell me what version I’m getting, and I only want the latest stable release. It was unclear at this point what this cloning did, but I was told over an over that I had to clone to get the version I wanted. Thankfully, git knows a lot of us are in the WTF world, and have a nice crash course for SVN users. Most important to me was this:
So git clone URL is svn co URL and that’s how I first installed MediaWiki. But… I know MediaWiki is working on a million versions and I’m not specifying one here. The git doc goes on to say that for git, you don’t need to know the version, you use the URL and it’ll pull the version named ‘master’ or ‘default.’ That basically means I’m checking out ‘trunk,’ to use an svn term. This is exactly what I do not want. I have no need for trunk, I want this special version.
After more reading I found git checkout --track -b branch origin/branch which they say is the same as svn switch url which is excellent. I can also use git checkout branch to check out the specific version I want!
I’m very used to SVN, where I can browse and poke around to see the tags, branches, and so on. When I go to https://gerrit.wikimedia.org however, all I see are the latest revisions. The directions said I should get the file /r/p/mediawiki/core.git which makes me presume that’s what tells git the version I’m checking out, but I can’t see that. I don’t like obfuscation when I’m checking out code. After some digging, I found the URL I wanted was https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git and that shows me the files, and their tags.
The tags were important for the command I wanted to run: git checkout tags/NAME where NAME is the tag. I want version 1.18.2, which is the latest stable, so I want to do is git clone -b tags/1.18.2 https://gerrit.wikimedia.org/r/p/mediawiki/core.git
I tried it with pulling a copy of 1.18.1, and it ended up pulling about 89 megs and put it in a subfolder called ‘core’. Oh and it told me it couldn’t fine tags/1.18.2 and used ‘HEAD’ instead, which put me on bleeding edge. It took a while to find something that looked a little better:
cd ~/www/wiki/ git init git remote add -t REL1_18 -f origin https://gerrit.wikimedia.org/r/p/mediawiki/core.git git checkout REL1_18
In theory, that would get me the latest and greatest of release 1.18, be that 1.18.1 or 1.18.2 and then, when 1.19 was released, I could switch over to that by doing this: git checkout REL1_19
It was time to test it! I pulled REL1_17 and … ran out of memory. Twice. fatal: Out of memory? mmap failed: Cannot allocate memory happened right after resolving deltas. Everyone said ‘You need more swap memory’ but when I looked, it was fine (not even using half). So that was when I said ‘screw it, I’ll go back to tarballs.’
Just as I hit that wall, some Twitter peeps stepped in to explain that, no matter what, I have to clone the whole archive first. I’m not really happy about it. I like SVN, since even when I switch, it’ll only update my changed files. I wanted to be able to do that in git without needing to pull down the whole repo, since I only use it to update, and not develop.
And that there is my one and only issue with git. It’s entirely for developers. Sometimes, some of us just want to pull down the latest version to play with, and not the bleeding edge. With git, I have to clone the repository, then export the version I want to play with. That’s not optimal for what I want to do. On the other hand, I totally get why it’s done that way. It’s akin to the basic svn check out, where I get all the branches and tags, only much much cleaner. And that’s cool! Smaller and leaner is fantastic.
And yet I’m not a developer in this instance. I don’t need, or want, the whole release, just a specific stable release. So now my workflow would be…
Install
On Git:(Of note, every time I try to run checkout I get “fatal: Out of memory, malloc failed (tried to allocate 1426604 bytes)” and I get the same thing when I try to archive. If I use the tool to change memory allocation, it also fails … out of memory. I’m taking this as a sign.)
mkdir ~/mediawiki/ cd mediawiki git clone https://gerrit.wikimedia.org/r/p/mediawiki/core.git . git checkout 1.18.1 -f cp -R ./mediawiki /home/user/public_html/wiki/
On svn:
mkdir ~/www/wiki/ svn co http://svn.wikimedia.org/svnroot/mediawiki/tags/REL1_18_1/phase3/ ~/www/wiki/
Upgrading
On Git:
git pull /home/user/mediawiki/ git checkout 1.18.2 -f cp -R ./mediawiki /home/user/public_html/wiki/
On svn:
svn sw http://svn.wikimedia.org/svnroot/mediawiki/tags/REL1_18_2/phase3/ ~/www/wiki/
You see how that’s much easier on svn?
Now, someone wanted to know why I like this. Pretend you’re trying to test the install. You often need to test a specific install version, say version 1.17.1, against some code to see how far back something was broken. Being able to quickly pull that, without coding any extra steps, is crucial to fast testing and deploying. The tool we use at my office required me to reverse engineer and script a way to do that with an ant script, and certainly I could script all that here. It’s not even that hard. But what’s one line in svn is three in git, on it’s best day, and you’re always pulling the latest and reverting back to the one you want, which seems a little silly.
Now, someone pointed out I could use this: git checkout-index -a --prefix=/home/user/public_html/wiki/ When I read the man page, it doesn’t say you can pick a tag/branch to push, though. If you have some advice on how to fix that, I’ll give it a shot, but I suspect my memory issues will block me.
I will be using git for a lot of things, but a fast way to update, spawn versions, and test will not be one. For development, however, I totally adore it.
Comments
9 responses to “Once GITten, Twice SVN”
You’re in exactly the boat I thought you were in – trying to bend a powerful, granular development tool to your will. True, the sky’s the limit with what you can do with Git … but if you don’t want the sky, it’s overkill. For what you’re doing, Svn is more than enough and, if it were me, I’d be very upset about the switch to Git.
That said … once you’ve gotten the exact workflow polished, it’s fairly straight-forward to write your own Git scripts to automate the process for you. That’s just an extra step that, really, you shouldn’t have to mess with 🙁
Well, now it’s back to this:
wget http://download.wikimedia.org/mediawiki/1.18/mediawiki-1.18.2.tar.gz
tar xvzf mediawiki-1.18.2.tar.gz -C ~/www/wiki/ --strip-components=1
Which is fine. I can script that to pull in major and minor versions and auto-copy.
Why do you feel you have to clone the git repo, checkout your desired branch, then export it to a different directory?
Why not just checkout in-place, just like you do an svn switch in-place?
Because by default the pull gets trunk, and I don’t want (need) trunk. So if I have to pull trunk and then revert back, I’d like to be safer and do it in another folder, verify that it’s the right version and completed successfully, and then move it up. I’m much more trusting of svn switches, since I’ve used them for years.
It really comes down to a fundamental difference between git and svn. SVN is a centralized version control system, meaning it has a central location from where you check things out and in to. Git on the other hand is de-centralized; you have the entire repository on your computer, you have the entire history of everything. This obviously has great advantages, when, as you say, you are a developer working on that project.
As Eric said, the sky is the limit with Git, but sometimes it can be a bit of a pain with smaller tasks like this 🙂
zamoose just told me about LeGit.
http://www.git-legit.org/
I will play with this!
I use Beanstalk. You update your local repository, then use that to push code to Beanstalk, then Beanstalk deploys that code automagically via sftp to your server. That way you don’t need to do anything funky on your server, yet you get the benefits of deploying via Git. Your server has none of the Git files, just the active working ones.
You can also have different branches and deploy them to live or staging sites where appropriate.
It’s pretty slick. You should check it out 🙂
You hit the one single use case which svn colossally excels at, and git colossally sucks at.
I know this from painful experience, and while I’ll never, ever willingly go back to svn, I do miss – sometimes – svn’s ability to check out a subtree and just get on with it. I’ve had to change my workflow to compensate. However, I also have to admit my workflow is probably smoother now with git than it was with svn. Go figure, I know.
It’s also great to see people in the WordPress community giving git a fair shake.
My development workflow’s improved, hells to the yes.
My ‘I like to test everything’ flow, less.