Monday, February 4, 2013

GIT-ified views

When I first discovered Distributed Version Control Systems (DVCS), one of the few open source implementations available was Tom Lord's Arch, or tla. Arch was a direct predecessor to Bazaar, a spiritual parent to DARCS, and preceded GIT by about 4 years. The ground being plowed up by these projects, Linus re-envisioned the whole-changeset implementation and added a core audience in the form of the Linux Kernel project. It also didn't hurt that GIT's speed and space efficiency was better.

Coming out of an environment that used Rational's ClearCase, I found it useful to emulate the "set view" functionality using carefully constructed shell functions that could set up or reuse working trees on demand, separate from the repositories. A child login shell was launched to establish a repo-specific environment, and the environment curried to include tla command wrappers with defaulted common command arguments (tla was excessively verbose). I called the resulting wrapper Setview, after the ClearCase command.

The ClearCase feature provided a measure of process- and filesystem- isolation to the development cycle. This was probably deemed to be important to lawyers, who wanted to micromanage what every person could see. Never mind that they probably relied upon tons of GNU copylefted code, but I digress. There are still times when, instead of a stash or a branch/commit/checkout/branch, or cloning a repo a second time, I'd like to just have a transient, isolated instance of the working tree.

And I have to ask myself, "why?"

A decoupled working tree can more easily be automatically garbage collected. When I create temporary and intermediate files in such an ephemeral tree, I don't have to be concerned with clutter: it will go away on its own when I discard the view.

If the repo is decoupled from the working tree, that is, not in a .git subdirectory, the working tree can be destroyed accidentally without risk of destroying the repo. This is mitigated by a frequent cycle of pushing to a remote.

Switching working contexts is something every software developer has to do, especially when working in an institution with multiple internal clients. A pre-configured shell environment, launched when starting a task, and cleaned up when the task is finished, is a useful device for establishing context. It gives a sense of space, boundaries and structure, which is an illusion but helps keep work and thought processes organized.

Having common commands and options curried into wrapper functions is helpful. I find git to be less verbose than tla, but the inconsistency and whacked out grammar in the git command line interface is still a challenger to tla for the most obfuscated command line contest. Still, having aliases, functions, and some environmental variables set per view allows tools to be configured based on the task at hand rather than globally or per repo. An extremely simple example, but very pleasant, is to be able to go snooping around other directories and then just lcd (local cd) to somewhere in the $VIEWHOME. I know pushd/popd offers similar functionality, but it isn't quite the same and lcd is shorter.

For whatever its benefits, having wrappers for git seems a necessity, be they scripts, aliases, functions, or whatever. Having wrappers coupled to the working context, and not coupled to the repo or the users' login environment, is useful for ensuring good isolation and control over configurations.

I don't know if those are good enough reasons for re-implementing a more robust version of setview for git, but sooner or later it seems like I must.
Post a Comment