Git Public push-ing Woes Resolved

Over the last few days I’ve been experimenting with distributed version control. I’ve finally settled on git. My large projects (Bugdar, namely) will remain in Subversion for the foreseeable future because I don’t want the hassle of converting. However, one of the drawbacks of SVN is the fact that it needs a dedicated svnserve or Apache2 DAV. Most web hosts offer neither of these, which will make it impossible for me to publish my smaller works. In a few months when my current Subversion server will be taken offline forever (because I will no longer maintain it at college) this will cause problems. This left me with two options: create Sourceforge.net projects for each small project (which I didn’t want to do as some may die very quickly, others are too small and not worth it, etc.), or find a new version control system that didn’t require special servers. Hence, I went shopping for a version control system that works over plain old HTTP.

First, I tried Bazaar. It was okay. Nothing spectacular, however. And it seemed rather immature. SVK sounded interesting but it still relied on the SVN repository layer so it was done before it got started. I then thought about creating a Ruby-based CGI WebDav implementation and then adding a layer on top of that with the SVN SWIG bindings. However, I ultimately decided against this because it sounds like a total pain in the a$$ to maintain the SVN part of the equation (though I still may write the WebDav Ruby CGI as it sounds like a fun challenge).

So I was back at square 0. Then I decided to look at git. I briefly glanced at git in my searchings before but I was turned off by the command set. But I finally went back and had a thorough look. And I’m now using it to manage a new project I’m working on (more on that in another post).

Using git is straightforward (for most things). The only feature I wish I had was the ability to do the equivalent of “svn revert” on specific files instead of “git reset –hard” on the entire working copy. I also miss incremental revision numbers. But I’ll live. Because git is fast, and doesn’t get in your way at all. It makes perfect sense.

And git has some amazing features. The first of which is a compile-instantly and an install-without-being-root installation. Then there’s the whole notion of the “index” (or a staging area for commits). I like this a lot as it forces me to be more careful with what I commit. Also, the two built-in GUI commands (gitk and git-gui), while unattractive, are very useful and it’s great they come out-of-the-box without any work. But my favorite thing is definitely the ability to go back and edit the last commit! It’s fantastic to be able to fix a mistake without having to make a whole separate revision.

So I’ve been using git locally for a few days now, and I decided it would be a good idea to try push-ing it to bluestatic.org to make sure that public repositories will actually work! After many, many failed attempts all I could get was this cryptic message:

bash: git-receive-pack: command not found
fatal: The remote end hung up unexpectedly
error: failed to push to [removed]

And then, by chance, and after a good 20 minutes of searching, I found this perfect answer on Google:

Many installations of sshd do not invoke your shell as the login shell when you directly run programs; what this means is that if your login shell is bash, only .bashrc is read and not .bash_profile. As a workaround, make sure .bashrc sets up $PATH so that you can run git-receive-pack program.

So I solved this error by simply creating a .bashrc file with this in it:

export PATH=${PATH}:~/bin

I thought I’d just write about this in hopes of helping others out.

Bugdar 1.2.0 and the Future

Now that Bugar 1.2.0 is out in its final version (you can go grab it from the Bugdar page), it’s time to start thinking about the next major release of Bugdar.

Major releases of Bugdar have been happening about every 9 months: 1.0.0 was released 17 January 2006, 1.1.0 was released 1 October 2006, and 1.2.0 was released 14 July 2007. I have been wanting to use some OOP features in PHP5 for a while in Bugdar (namely the ISSO3 framework) but because I don’t want to cut down on the userbase, I have been wary of doing so. However, with the GoPHP5 project roughly 9 months away, it seems like the perfect opportunity to switch to PHP5.

I do think the next release will be 2.0 as I don’t think there’s enough semi-major features to warrant a 1.3 release. I have some ideas as to what should be in 2.0 and I think it will be an amazing release. You can see just a few of the features that are likely coming in 2.0 here. Unless there is opposition to doing so, I think the next version of Bugdar will be 2.0 and will be PHP5 only. Moving to 5.2+ would mean a lot of legacy code can go away and I can move into much more advanced OOP programing, which would make Bugdar more robust and would help reduce the number of bugs, as well as increase testability.

And a side note: I’ve started moving all my open source SVN projects to be at Sourceforge as a way of consolidating my servers as I won’t have the resources to maintain as many next year in college! You can find Bugdar’s page here.

Getting PHP mail() to Work on OS X Tiger

I recently (as in this week) got my brand new MacBook Pro. It’s shiny and I love it and for the past few days I’ve been transitioning my life from desktop to laptop. One of the things I had to do was to get PHP installed and working, which as usual, was straight forward. However, on Mac OS X, I couldn’t figure out why PHP wasn’t properly sending out email. The answer lies in the fact that, by default, Mac OS X does not start Postfix (which is what is used to send email). I searched the web for numerous tutorials on how to get this to work, but all of it conflicted. Ultimately I just read the man pages on launchd (the thing that makes OS X start) to get it to work after comparing my laptop’s configuration to my desktop’s.

So this will get the Mac OS X mail server working on 10.4.10 (and most likely all of 10.4.x):

Edit, as root, /etc/hostconfig and add this line (presuming there are no other lines for “MAILSERVER”, and if there are, simply change it to be this):

MAILSERVER=-AUTOMATIC-

And then run this command in the Terminal:

sudo launchctl load /System/Library/LaunchDaemons/org.postfix.master.plist

Next time you reboot, Mac OS X’s mail server will be working hunky-dory. Note: this will not create a persistent SMTP server, but instead will start when an email is sent and then will automatically close when it’s done (so Postfix will not run in the background when you don’t need it).

Bugdar 1.2.0 Last-Call

Bugdar 1.2.0 is almost ready for it’s final/debut release. There are just two outstanding issues that I would like to close before releasing. If you are in a position to do so, please help by submitting as much information as possible about these two bugs:

• #86 – Issue with marking bugs “hiden” that I cannot reproduce
• #82 – RTL/Hebrew emails are showing corrupted characters

Any help would be appreciated in order to move 1.2.0 out the door.

Forum Open

After many requests for a forum, I have decided to put one up. I chose to use Vanilla as the forum software because I think it is a far superior solution for what I want. I do not want a whole bunch of staunchly-defined categories delineating discussions, because then the number of topics in each would be few and sparse. With Vanilla, everything can appear in the same category (though you are not limited to this) which makes discussions flow. It may be slightly unconventional, but I think it will work the best.

The style for the forum is not yet done (let alone started), but one day it will match the rest of the Blue Static website. I just wanted to get it open so people are free to use it.

And please do not report any bugs or formal feature requests in the forum, please use the bug tracker for that.

Without any further adieu, this is the forum.