5 reasons to use Git instead of Subversion

Git is a new version control system originally written and designed by Linus Torvalds for managing the development of the Linux kernel.  Due to the chaotic nature and massive amout of contributers to Linux kernel development, Linus is quite arguably the most qualified person in the world to design a good VCS.  Git is quite a bit different than a traditional VCS such as Subversion and it doesn’t have the mathematical theory that darcs has behind it, but it is by far the most practical VCS I have used to date.  So anyways, here are my 5 favorite reasons to git.

  1. You always have a full copy of the repository with all the meta-data, online or off
  2. You can merge with anybody’s repository, not only a single central server
  3. Even with the full history, git repositories take less space than a SVN checkout
    brandon@Brandon:~/localtmp/clone$ du -sh *
    1.6G    cohiba.git
    2.6G    cohiba.svn
  4. Modifying the history is easy, using git rebase -i <some_revision> will bring up a list of patches in your favorite editor and allow you to merge/reorder/delete them, then it will apply them as you’ve specified, re-committing with each one
    pick e4eb2ca Added -d option to only look at 1 date
    pick 881ef7f Fixed bug that caused an Prelude.head: empty list exception if no work orders were pushed
    pick 3595183 Added line itemized reports on pushed work orders
    pick 1b6ff52 Fixed the parser so that it doesn't break if there is a [] in the stack trace It was using a bit of a hack, but i've cleaned up the parser so there should be no more suprises, no matter what we throw at it
    pick 12b7023 Changed slurp_until to fail on eof
    pick e511b15 New log file for tests
    
    # Rebase 378dd8b..e511b15 onto 378dd8b
    #
    # Commands:
    #  p, pick = use commit
    #  e, edit = use commit, but stop for amending
    #  s, squash = use commit, but meld into previous commit
    #
    # If you remove a line here THAT COMMIT WILL BE LOST.
    # However, if you remove everything, the rebase will be aborted.
  5. You don’t need a centralized server with a single ‘master’ copy of the codebase with git, but that is  still how most software shops will operate.  Any mucking with this master copy would be noticed by all because git revision id’s are hash sums of the entire history up to that point.

bnIRC 1.0 released

I’ve finally released a 1.0 version of bnIRC.  It’s available on sourceforge as a .deb or a source package.  Windows builds are planned but will have to wait until a future release, hopefully not too far out.

New life in bnIRC

I’ve decided to breath some new life into my IRC client. I’m using a few people on freenode to test test test so that I can make it stable. The goal is to have a rock-solid (no new features) 1.0 release within the next few weeks and afterwards I’ll be adding some features that have been requested.

I created a git repot on github.com. Tarballs/zip files can be downloaded here. Or if you have git installed you can run:

git clone git://github.com/bniemczyk/bnirc.git

If your interested in helping test please do! Make sure that the python and ncurses header files (python-dev and ncurses-dev on debian) are installed before you run ./configure, or you’ll get a very bare-bones interface that is really only meant for debugging.