Blog Archives

A Better git-svn Log

This morning, Devon tweeted a great git tip that shows how to create a git alias that produces more readable git logs. I decided I wanted to set this up.

At work, we use a central Subversion repository, but a number of us use git-svn because we prefer git’s various local branch tools for development. I decided that it would be useful to extend this alias to also include the Subversion revision number if the commit has one. Unfortunately, this information (in the form of a Subversion URL) is stored in the commit body by git-svn, which may include other notes added by a developer. git-log exposes this text via the %b format specifier, but since we want to do some post-processing to extract just the revision number, we’ll need to set up a shell alias.

Here’s the final version I’ve added to my ~/.aliases:

alias glog='git log --graph --pretty=format:'"'"'%Cred%h%Creset%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset%Cred%b%Creset'"'"' | perl -e '"'"'$log = do { local $/; <> }; $log =~ s/(>\e\[m\e\[31m)([^\n]*\n\| )*git-svn-id: svn\+ssh:\/\/[^\s\@]*\@(\d+) [0-9A-F-]+\n(\|| ) (\e\[m)/$1 r$3$5/gm; print "$log\n";'"'"' | less -RS'

First you’ll note the weird quote escaping – we want the alias to be single-quoted (no expansion), but we want the arguments to the commands to also be single-quoted. That’s where the '"'"' trick comes in; see this explanation on StackOverflow. The format string is almost identical to Filipe’s solution, except for the addition of the body. The nasty Perl regular expression pulls out the revision number from that while also preserving the ANSI color escape sequences I inserted into the format string. Finally, we pass everything back to less for paging; -R makes sure it interprets the colors correctly, while -S disables line-wrapping.

One unfortunate side effect of adding the post-processing is that you can’t pass the -p option to git log anymore, because Perl needs to read the whole log in for multiline matching (in case a developer had literal newlines in their commit body), and the diffs are large and could get caught in the regex filter.

Hopefully you find this useful!

Posted in Computers, How-Tos Tagged with: , , , , , ,

Kickstarting Apps

I have a tiny Kickstarter problem, but I mostly manage to resist. Earlier this year my excitement for backing video games overwhelmed me a bit, as you can see. I’m excited especially for The Banner Saga, but like any preorder, I’m out money now for something I won’t have for a year.

As you may know, I am also a big fan of the 5by5 podcast network, including the show Build & Analyze with Marco Arment. A few months ago, I wrote in to the show with this question:

I’m wondering if you’d talk about the recent large-scale Kickstarter video game projects, such as Double Fine Adventure, Wasteland 2, and Banner Saga. Do you think this would be a way fund non-game apps?

Marco and Dan answered this in Episode #70, 116 Degree Burns, starting at the 23:35 mark, right after the first sponsor, and going to about 34:25. I meant to follow-up a while ago, but the end of the semester was a busy time, so here goes.

My interpretation of Marco’s overall point was that software, especially complex apps like a game, is too risky to back. This is because it’s near impossible to estimate the total amount of development time, and therefore the cost, so the project can’t set a reasonable goal or backer rewards.

As a fellow software engineer, I totally understand this difficulty, but Marco’s take was definitely a downer for me. I think I wanted him to agree with my thinking, which is that Kickstarter could be an alternative source of funding for app creators, basically a way to gauge market interest before doing anything more than preliminary planning and development. I think Marco goes too far in claiming that Kickstarter possibly shouldn’t allow these projects because of that risk.

As an aside, there is some irony in one of the first high-profile app Kickstarter projects, Dark Sky, being an occasional sponsor on 5by5.

Kickstarter has a good stats page, but it just shows the breakdown of successful vs. unsuccessful funding; it doesn’t show how successful projects are at completion and wisely using their funding, which is at the core of Marco’s argument. At a glance,  I have seen a few updates from some of the projects I’ve backed that the project team didn’t accurately predict the cost and effort of putting together (and in some cases, shipping) backer rewards. I do note that Games as a category are on the higher end of the money range, but the lower end of the success rate, which probably bears out Marco’s point about risk.

That all said, I think Kickstarter has a very important role for the future of “the useful arts”. The content industry in particular is in the process of a major upheaval, so it’s not clear how someone with a good idea that doesn’t fit into the usual day job archetype can get the money they need upfront in order to take the time to create. Backers can in that sense collectively fill the role of Renaissance patrons.

Apps are in a bit different category, in no small part because the skills necessary to create an app are economically valued in the traditional employment market. Maybe some of my interest in the idea is that, while I love my job, I envy some aspects of Marco’s lifestyle as an independent app developer. (It doesn’t help that we’re within a few months of the same age.) I suppose then a subtext of my question was wondering if this is a feasible way to start working in this space.

What do you think?

Posted in Opinion Tagged with: , , , , ,

Local Version Control With Git


I’ve recently become obsessed with git for version control. I know that there are many git tutorials out there; this is probably redundant, but it focuses on only the simplest operations for my own reference. The git man pages themselves are extremely well written. This post is an adaptation of an article I wrote for our department wiki, targeted at some of my fellow researchers who have probably never heard of git. I removed all of the references to our internal projects.

Unfortunately, one of our major codebases at work is stored in a Microsoft Visual SourceSafe repository; it has been for years, and there’s enough momentum that we likely won’t move to a better version control system any time soon. If the motivation sounds odd, I mostly write research code, so we are regularly creating totally new code that may be used once or twice and then never again.

Visual SourceSafe has limited branching capabilities, so many users keep large subsets of the codebase checked out onto their development machine. When a major experimental change is feature-complete, dealing with merges in VSS is a pain that typically involves face-to-face negotiations of who checks in what when, or one person spending a day or two fixing conflicts in WinMerge or a similar tool. This article demonstrates how to use git, a modern distributed version control system used by the Linux kernel (among others), to manage smaller-scale changes to VSS code trees on Windows without having to risk checking in files that “break” functionality for other users.

The main point of using a local version control repository inside of a VSS checkout is three-fold:

  1. Commit more often
  2. Easy branching for experimental code (whether or not it pans out)
  3. More detailed history/self-documentation of recent changes

I’ve found that my development habits have gotten much better using git; in particular, I commit just about every successful compile-and-test, and I try to isolate commits by functionality as much as possible, so that it’s trivial to cherry pick experimental changes that should be kept or not.


Posted in How-Tos Tagged with: , , ,

Nicolas Ward

Software engineer in Natural Language Processing research by day; gamer, reader, and aspiring UltraNurd by night. Husband to Andrle
Creative Commons License

Post History

June 2018
« Jan