In the roughly five years that the Git distributed version control system has been around, it has gained quite a following. But at its core, Git is command-line oriented, which doesn't necessarily suit all of its users. Along the way, various GUI interfaces to Git have been created, including two Tcl/Tk-based tools that come with Git. Giggle is a GUI front-end for Git that is based on GTK+, which released a 0.5 version in late April.
The two tools that come with Git are oriented for two separate jobs: gitk is for browsing the repository, while git-gui provides a way to change the repository by committing files, merging, creating branches, and so on. The combination provides fairly full-featured access to Git but, because of its Tcl/Tk-based UI, lacks much in the way of eye appeal. In addition, those tools don't integrate well with a GNOME desktop, visually or functionally, which is what Giggle (and others) are trying to do.
Giggle combines both the repository browsing and changing functions into one program, but the feature set for the latter still lags git-gui. There are two modes in Giggle: "Browse" for looking through the source tree and "History" for looking at the commits in the repository.
Browse mode has a three-panel view, with the source tree on the left, any currently selected file's contents at the top right, and a log and graph of the revision history of the file at the bottom right. Clicking on earlier revisions in the history section changes the file pane to show that revision as one might expect. In addition, hovering over lines in the file pane brings up a pop-up with the commit information when that line was added, so you are essentially always seeing the equivalent of git blame.
Other operations, like editing or committing a file, creating a branch or patch, etc. are also available in browse mode. Double-clicking on a file name brings up an editor, though how it chooses which editor is a bit of a puzzle. For the Linux kernel repository, it decided that Emacs was a good choice, but for the LWN site code, KWrite was deemed the proper choice. Presumably the latter comes from some default editor choice down in the guts of the KDE preferences, but it's unclear where Emacs came from—perhaps the different implementation languages (Python vs. C) played a role.
That points to one of the areas that makes Giggle somewhat difficult to use: lack of any documentation. It's easy enough to click around and figure most things out, but a small users' manual would not be out of place either. In addition, the "click around" method of figuring out Giggle runs afoul of its other main deficiency: performance.
The performance of Giggle is rather poor, especially considering that the underlying tool has a definite focus on speed. Starting up Giggle in a Linux kernel repository takes 15-20 seconds of 99% CPU usage before there is a usable interface. That might be understandable for a large repository with many files and revisions, like the Linux kernel, but the performance was much the same on a much smaller repository.
It's not just startup that is slow, either. Switching from browsing to history mode can sometimes take up to ten seconds. When scrolling through history, Giggle will just pause and eat CPU for a while. Overall, it is a fairly painful experience, especially when compared with gitk, which seems quite snappy. Giggle also suffered from a few crashes and hangs in an hour's worth of using it.
History mode has the git log output in the top panel, along with the commit graph. Once a commit is chosen, the files affected are shown in the lower left. Each file can then be selected to show the diff output from each change made to that file in the lower right pane. There is no side-by-side comparison of old vs. new versions that other tools have, which might make a nice addition.
The project has been around since it was created in a January 2007 hackathon, and has slowly added more features. Development releases have been fairly frequent of late, more-or-less monthly since January, but before then things seem to have stagnated for almost a year. It is unclear what the plans are for 0.6 and beyond, though the list of open issues gives some ideas of the kinds of bugs and features that will likely be addressed.
There are other fairly active Git GUI programs available including git-cola, a Python/Qt4-based program, and gitg, which also based on GTK+. The latter is meant to track Git clients on Windows and MacOS to try to provide a consistent interface to Git on all three platforms. In particular, it closely tracks the GitX interface for MacOS X.
Other than purely visual attractiveness issues (and Tk definitely has a fairly clunky look and feel), it doesn't seem that Giggle and the other Git GUIs really provide very much beyond what gitk and git-gui do. That may explain the fairly slow pace of development for those tools as anyone who really wants a GUI interface to Git already has one at hand. It's also likely that standalone GUI interfaces are less interesting to those who are used to integrated development environments (IDEs) like Eclipse.
In the end, a GUI is supposed to make a tool easier to use, but Giggle does very little to make Git more approachable. The user still needs to understand a fair amount about Git in order to use the tool effectively. Once they do, using the command line may not be that much of a burden.
Newsletters and articles
Page editor: Jonathan Corbet
Next page: Announcements>>
Copyright © 2010, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds