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: , , , , , ,

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

March 2017
« Jan