Git on that train

Warning: As the title suggests, I’m on a train.

In the last week and a half or so I’ve been using Git for a project amongst coworkers and most recently for my own code and text files.  I was a bit skeptical.  But after going through their excellent documentation, seeing the videos, and most importantly, a lot of tinkering, I’m realizing that it’s making life better for me.

There are a lot of resources that compare SCMs, so I don’t want to worry here about which is better and why. But I’d like to share two things that I’ve really liked about using Git.

  1. First off, using something like Git doesn’t necessarily have to be for a big collaborative project.  This may be a sort of different take than the usual, but I like to see it as a tool that helps me see different “views” of my files depending on the job.  Anyone who’s written a lot of text or code realizes that it’s actually quite hard to make things as modular as one would like and that sometimes we’re relegated to grabbing snippets of text here and there rather than making black boxes.  While this is not encouraged as an engineering practice, it’s sometimes very useful for play. With Git, I’m less concerned about making all my source code fit in a super-consistent modular framework and more concerned with focusing on doing a task cleanly.  This is possible because I can branch and merge with relative ease (which I understand is a pain in the ass with other SCMs).  In a branch I can move some files around and do whatever I want without affecting the source.  I can then cherry-pick commits I like from that into another branch.  These branches can look wholly different, but the code can still be updated.  This flexibility makes me worry less about organization and directory structure and more about just choosing the right, minimalistic view for the job.  I now see things in terms of diffs and commits and Git provides the machinery to do real work with them.
  2. Git is minimalistic, local, and fast. Which is great.  It’s a  small source code base that compiles quickly and gives me handy command line utilities.  Proper use of them = power (though even with good documentation there’s a learning curve involved).  Unlike a lot of SCMs, Git is designed to be local.  While it can do a lot of stuff over the network, it’s modus operandi is in a local repository (which is just one .git/ directory in your root directory).  I, in fact, don’t even use the SSH/SSL features layered on top.  Git helps me realize what I’ve changed and worked on and I build patches from there.  You can email them to whoever, and applying them is easy.

And if I’m frustrated with some apparent inadequacy, it’s likely I can find some post with Linus himself justifying it with a little intellegence (e.g.).

Handy Makefile

The following is a snippet for a handy and concise Makefile that will make executables for all C files in a directory.  It’s good for “sandboxing” this illustrates some of Make’s useful features without before consulting a larger resource.  Tip of the hat to Erik for helping me polish it up.

# Flags for gcc
FLAGS = -D_GNU_SOURCE -O3 -g

# All C files as sources, and chop off the .c for targets
SOURCES = $(wildcard *.c)

TARGETS = $(patsubst %.c, %, $(SOURCES))

all: $(TARGETS)

# All targets without an extension depend on their .c files
%: %.c
	@echo "Building $@"
	@gcc $(FLAGS) $< -o $@

# The "@" symbol suppresses Make actually displaying the command. 

clean:
	@echo "Removing hidden files"
	@rm -rf .*.swp *.dSYM ._* 2> /dev/null
	@echo "Removing executables"
	@rm -rf $(TARGETS)        2> /dev/null

The nice thing about Make is that it’s useful not only for things like C code. I’ve even used it (quite some time ago) to piece together tracks of music using ecasound.

Wikipedia-like blog entries?

This is a sort-of half-baked notion that may have some flame war started somewhere on the net, but I can’t resist.

The combination of a noble call for better Wikipedia articles in a specific subject with a recent example of someone blogging to correct his own entry makes me fantasize: what if individuals wrote blog-like entries that were, in effect, articles like those on Wikipedia?

Why not just create an HTML page or contribute to Wikipedia?  As far as contributing to Wikipedia, don’t get me wrong: I think that’s great. But as outlined in linked “noble call”, there are some legitimate issues–most notably that of authorship.  Blogging allows one to retain authorship and control but, unlike HTML, it facilitates commenting and allows RSSee updates to interested readers and contributors.

In the second link, the creator of Bittorent is correcting his own Wikipedia entry. This makes sense at some level for the sake of clarification and posterity.  There’s no guarantee that if he edits his own entry (say anonymously), the changes will persist, and it may not be appealing to constantly keep watch of minor changes to articles either.

In the days of web one point yore (say before Wikipedia and Wolfram’s Math/Physics pages), if I Googled “Maxwell’s equations”, any page put up by some schmuck like me would probably be dicey at best.  But now, I can just feel lucky and get some pretty decent information from Wikipedia.

But due to the number of people editing the entry, there is a certain lack of authorship and potentially unwillingness to even contribute in the first place.

These days, we see lots of academic bloggers posting their lecture notes on specific topics online (some even making the lecture notes themselves posts rather than linking to PDFs), so parts of me feel like we’re already seeing this kind of behavior, though lectures tend to be less encyclopedic.

The thing I like about this approach is that it’s decentralized and personable in the sense that we can use the fact that we trust/value certain people’s discourse more than others to our advantage.  Potential downsides: (1) we’re that much more reliant on a YourFavoriteArticleRank algorithm to rank the articles for us (for example, when you link to another article, do you link to your favorite one? the top-ranked one? eh hem, Wikipedia?), (2) more people/groups would need to get blogs, and (3) the notion of a “collaborative article” is substituted with a “first author” (the writer of the post) and “contributers” (commenters).  But those concerns don’t seem that dire.

Science in the recent stimulus

Prodded by prof Tao’s post, I spent a little too much time sifting through official documents on the congressional budget as well as other articles related to NSF funding and the stimulus amendment.

Jake Young at Pure Pedantry has a nice post discussing the issue and outlines recent attention given to this subject by Science and Nature. Something I thought I’d forward on….

</politic>