By Jake Edge
June 2, 2010
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.
(
Log in to post comments)