All of the source code for HexSLayer is on Github. I'm going to try running this game as an open source project, and do all issue tracking using the Github issues list. If you like the game, or hate the game, or want to learn more about how it was made, follow me on github, or leave me a message.

When working with Git, you may run into the issue/error message couldn't find remote ref master when attempting to perform a pull. This message can be a little frustrating, because when you look at the remote repository, everything most likely can be seen just fine.

The answer to this problem is that this error means your system couldn't find the git repo details within a remote git repository. This is distinct from the error message when the repository cannot be found at all, does not appear to be a git repository.This is most often caused by inconsistent permissions within the .git folder. Check that you have permission to all of the files in your .git folder in the remote repo, using whatever combination of chmod and chown to ensure you have full permissions from the repository attempting to pull into, on the repository you are attempting to pull from.

I love the guide found at http://ubuntuforums.org/showthread.php?t=786095. It's one of the best guides for getting ffmpeg working with a lot of the "encumbered" codecs and capabilities. In order to make the process simpler, I have updated the ffmpeg connection from svn to git, and put the entire set of commands into a single spot. Simply copy and past the following into a console to run the entire set.

The Humble Indie Bundle was a huge success, making over 1.25 Million Dollars for the game developers and the charities. This has been a great example of what can be accomplished with the "Pay what you want" model, and a huge success for Linux Gaming, as well as DRM-free gaming. As part of the promised outcome of this huge success was that 4 of the 5 games would be open sourced. As of today, 3 of the 4 have been released. This isn't the complete success I was hoping for, but it definitely meets my expectations. The reason it wasn't a complete success was because although they have released the source code sufficient for users to build the games, they are maintaining control of all of the arts and assets. I see their perspective, being able to retain control of the creative side and the trademark, while sharing the logic and code with the world.

Gish

Gish can be downloaded or forked from Github at http://github.com/blinry/gish.

Penumbra

Penumbra can be downloaded or forked from Github at http://github.com/FrictionalGames. It is split into 3 different projects for the different modules the game is built into.

Lugaru

Although this project is being hosted and maintained on Icculus.org, there is a Github copy at http://github.com/pvtcupcakes/Lugaru being maintained by volunteers.

Last night I performed a bit of work on Gitosis Web. These recent modifications can be found in the Gitosis Web GitHub project profile. The most recent work was related to the reliability. When I started, the system was not able to make changes to the config file, and the key file deletion wasn't working properly.

The changes pushed resolve both of these issues. The first bug was resolved by fixing the variable scoping in a function.

What's next?

Hopefully soon I will be able to add non-administrator user authentication. The idea is that users with usernames and passwords listed in the configuration file will be able to add new keys, associate existing keys with their user, and remove keys from their user. I'm not sure if I want to allow users to delete keys from the filesystem, but one good way I could do it would be to allow deletion of the filesystem, if the user is the only person using that key.

Git is an excellent version control system. It is built on the principles of DVC, or distributed version control which means by default, your local copy contains all of the revision history for the entire repository. This is great because changes can be made, committed, undone, and even merged offline.

This property of git also has a potential downside when you are simply trying to access the latest version of a repository. In order to overcome this, git support a --depth parameter. This parameter will have the effect of preventing you from cloning it or fetching from it, and other repositories will be unable to push to you, and you won't be able to push to other repositories. These downsides ignored for a moment, having to work with only the recent history can be extremely desirable.

One concrete example of this would be the case where a user wants to compile wine. The official Wine Wiki has a git clone built right into the instructions. If you follow these instructions you will have the entire history, and it will take up around 200MB of disk space (this number will go up as time continues). By adding the depth parameter as follows, you can save more than half of this time by only checking out the most recent version of the repository.

Gitosis is a git repository management tool. It has features that make multi-repository, multi-user environments much simpler. The way you access the configuration is through git. You make configuration changes in your working copy, and then push them to the repo. These changes are then processed by git hooks to create/manage the repositories and keys.

One of the downsides of gitosis is that all administrators have equal permissions to add/remove keys, and there is no mechanism for users to manage their own keys. In response to this I have begun building Gitosis Web, a PHP frontend to gitosis that adds some extra capabilities and ease of use.

Many people are comfortable with Gitosis, and that's great. This tool doesn't replace Gitosis or say there are any issues with Gitosis, but simply that some workflows could benefit from an additional frontend.

Check out Gitosis Web on github

Gitosis Web Readme

Gitosis Web

Gitosis Web is designed to is designed to be a layer on top of gitosis. Leveraging PHP and extra properties stored in the gitosis configuration to allow and administrator to control the entire file, and to allow individual users to manage their keys.

Install Instructions

To install, you will need working installations of git, gitosis, php, and mysql. This system has been tested under linux, but might work on windows too (Assuming you have git in your PATH). Once you have this, make sure your apache user (probably www-data) has a checked out copy of gitosis-admin, and that it has a key setup with the gitosis server you want to administrate. You should add a "name = x" row for your adiministrator to the [gitosis] section, and an "x = pass" section to specify the cleartext password.

Once you have it setup, you load the web interface, specify the path of the gitosis-admin working copy, and provide a username and password. From there you can make changes to the gitosis configuration, or add keys to already specified users. Each user should get a group looking like [group user-stephen].

Future Plans

At some point in the future, I hope to add the ability to manage users without tweaking the gitosis.conf file, or allow users to manage their own keys. Allowing project owners might be a cool idea, but might make the interface too complex.

As modern web development methodologies continue to improve and optimize our workflows, one of the workflows that has risen to the top is a development deployment model using git.

Making it Secure

Before you do any of these steps, make sure you add the following to your .htaccess, and that URL Rewriting is working in your apache setup.

Without doing this, anyone will have read-access to all of your code, and your entire source history.

Use git

This guide assumes a lot of knowledge about source control, management, and is not a guide to git. This guide assumes you can figure those parts out, but that you want to know more about one specific workflow that works very well in my opinion.

The main idea behind this workflow is that you will have a central repository, a development version of the software, and a published version of the software.

Convert something else to git

If you want to keep any history, the first step is going to be to convert the source control history to git. If you are using cvs, you will need to convert to SVN, and then to git. If you use SVN, simply use git to do a git svn clone of the repository somewhere on your local system. From there I recommend you move the .git folder to the remote production server, and make a copy in the development folder. If you go into each of these folders and type git status, you will see any differences that have not yet been committed to the repository, but you will be ready to make and receive changes.

Now that you are setup, time to develop

From there, things are relatively simple. Simply make any changes you want in your development environment. When you are finished with your changes, and they have been tested to your satisfaction, commit the changes, and push them to the repository. You can then enter your production server, and pull the changes from the repository. You can also simply pull directly from the development server, but organizations I have worked with tend to like a 3rd copy of the source, somewhere separated from the hosting environment.

If you want to, you can make emergency or urgent changes directly on the production, following any existing workflow you have for ensuring something is not broken. When these changes are complete to your satisfaction, simply commit and push them, and do a pull from the development environment.
permalink

You may notice a new feature to the right side of the home page. This feature, called "Latest commits" intends to share some of the development projects I'm working on, but haven't had a chance to do a writeup on.

The bulk of the work for this feature was done for me in the form of an RSS feed provided by Github. I have been exploring Github for about a month now, as well as experimenting with Git in general as my preferred version control system. In the past I used CVS and SVN, but so far I have been extremely pleased with the quality, speed, and ease-of-use of Git, as well as Github.

What you are seeing now

There are two main projects I'm working on at Github actively. The first is a hex-based game called HexSLayer, written in python. It is a small strategy/puzzle game with a naive AI, and some decently interesting gameplay. Currently it is playable, but the AI isn't very smart, and there is no way to add other human players locally or over the network, hopefully these features will come with time.

The second project you can currently find active commits for is called Youtube-HTML5-Chrome, among other names. The idea of this project is to provide a Google Chrome extension that swaps out the flash videos on youtube for a native HTML5 <video> element, which is faster, more reliable, and demands fewer system resources. You can find the actual extension at the HTML5 youtube page in the extension index.

Sometimes when migrating git repositories around, or when importing older version control systems into git, the author history would be nice to update to be forward looking.

CVS to git conversation

Rewrite git authors

git filter-branch --commit-filter '
        if [ "$GIT_COMMITTER_NAME" = "PeEll" ];
        then
                GIT_COMMITTER_NAME="New Name";
                GIT_AUTHOR_NAME="New Name";
                GIT_COMMITTER_EMAIL="new.email@example.com";
                GIT_AUTHOR_EMAIL="new.email@example.com";
                git commit-tree "$@";
        else
                git commit-tree "$@";
        fi' HEAD