[Sat Dec 29 11:22:44 CST 2012]

I just ran into a problem trying to configure Debian Squeeze for CGI. I thought that installing the libcgi-pm-perl package would do the trick but it was a no-go. Every single time I ran the Perl script, it just showed the contents of the script, instead of actually running it. Well, in case anyone out there runs into the same problem, the trick is to install libapache2-mod-perl2. Doh! {link to this entry}

[Thu Dec 27 15:28:41 CST 2012]

I recently found the excuse to finally learn git, the revision control software originally written by Linus Torvalds for the Linux kernel. I was asked to put together a simple web-based tool to allow people to submit draft solutions for company-wide knowledge base, as well as some other internal tools, and figured out that it just made sense to: 1) make it easy for other employees to contribute code to any of the tools, and 2) move away from good old CVS which, although good, is definitely showing its age. Now, the problem with git —as with any other powerful tool, of course— is that it's quite complex, at least when compared to CVS. Its distributed nature means it is far more flexible than older software, but it also entails a larger effort to learn the basics. So, I searched for online tutorials and... yes, sure, there are plenty of them, but I found them to be overkill, for the most part. More than tutorials, I found fully fledged documentation, which was far more than I needed. Yes, there are plenty of tutorials too but, for whatever reason, they seem to concentrate on dealing with local repositories, and not central repos sitting on a server somewhere in the network, which is what I use. In any case, in the end, this short tutorial put together by the folks at GitGuys.com helped get started.

OK. So, what are the steps involved in creating the repo? It's easy enough. First of all, you do the following on the server side:

$ mkdir project.git

$ cd project.git

$ git init --bare

As far as I can see, the .git extension is entirely optional, but it's pretty much standard for git repos.

You then set basic things on the client side:

$ git config --global user.email Your.Email@example.com

$ git config --global user.name “Your Real Name”

Once you do that, you can then move to the client and proceed as follows:

$ git clone ssh://host.domainname.com/path/to/project.git/
Initialized empty Git repository in /home/username/src/project/.git/
warning: You appear to have cloned an empty repository.

$ cd project

You can now add your files to that directory. In other words, create new files, copy existing files to that location... whatever. Now, let's add those files and commit the changes:

$ git add .

$ git commit -m "Initial commit" 
[master (root-commit) 01d7520] Initial commit
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 test.txt

However, the file test.txt is still only available on your local repository (or branch). The idea is to commit it to the remote repo on the server. If you were to push the changes to the remote server right now, you'd see an error as follows:

$ git push
No refs in common and none specified; doing nothing.
Perhaps you should specify a branch such as 'master'.
fatal: The remote end hung up unexpectedly
error: failed to push some refs to 'ssh://host.domainname.com/parth/to/project.git'

That happens because the remote repo was completely empty and still has no branches whatsoever. So, you need to do something like this:

$ git remote
origin

$ git branch
* master

$ git push origin master
Counting objects: 3, done.
Writing objects: 100% (3/3), 245 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
To file:///home/gitadmin/project1.git
 * [new branch]      master -> master

Right after this, any regular git push will just work as expected:

$ git push
Everything up-to-date

{link to this entry}