git, to the best of my knowledge, is the most complete and atomic version control system yet written. However, because it takes a tools-based approach to version control, it is cumbersome for typical development tasks. While release engineers and occassionally project managers may require the need to do very fine-tuned version control, as a typical developer, all I really care about from a version control system is the ability to check in my code, pull the latest changes, and merging conflicts.

git in fact has no workflow. This is a good thing, in that it allows arbitrary workflow to be built on top of it. Different workflows are appropriate to different projects and situations. However, it is a bad thing in that workflow has come to be expected from version control systems. While this is somewhat of a historical accident, a VCS without workflow is pretty useless. People will do whatever they want. People will complain when other people's method of doing what they want is at a conflict with theirs or makes theirs hard. I have found that agreeing on a workflow (a human problem) to be much more difficult than the usual taks of dealing with a VCS.

I have been disappointed that github.com, which brought git "to the masses", has completely ignored the workflow problem. github highlights how easy it is to fork and make your own copy of a project, and gives some hand-wavy explanation about pulling from each other's copies. However, for a large collaborative project, the instructions that github gives you are not really helpful. You'll want a workflow. You'll want an actual procedure whereby people can develop code and contribute upstream without stepping on each other's toes. While github does things like code-commenting and pull requests excellently, it gives no real tools for coordinating among people working on the same project.

So people write workflows as list of instructions. "Do this...then do this..." As a programmer, I'm good at writing lists of instructions -- that's in fact what programming is -- but when it comes to following a long list of instructions for a task I have to do several times a day, I am ill-suited. I get impatient. Often a small typo can have dire consequences. If its a one-off, then I can be very careful and do it. If its a bunch of typing I'm asked to repeat over an over again, I have very little patience. Machines do such things very well. I do not do such things very well. Enter: automation.

So the real solution to git's lack of workflow -- and probably to other VCS's as well -- is to write a layer on top of the bare VCS that contains the needed workflow. Ideally, such a workflow-program would have the following characteristics:

1. It should be easy to follow the workflow, in the same way that you don't have to worry about steering a train.

  1. It should be hard or impossible not to follow the workflow

3. The parts of the VCS that aren't part of the workflow, such as purely informational components (viewing logs, etc), shouldn't be affected by the workflow wrapper

I've written such a wrapper, that I call gut : http://k0s.org/hg/gut . This is a pretty naive implementation for a particular workflow, that for Mozmill detailed in https://wiki.mozilla.org/Auto-tools/Projects/Mozmill/RepoSetup . It doesn't really meet these ideals (except #3). However, it does automate a number of aspects of the git workflow that I've gotten wrong many many times due to typos or other silly human mistakes. It's not 100% identical to what is in the RepoSetup page, but it is conceptually the same.

I'll admit that this is a cheap fix and a brittle one. The important part is that since using gut I've made fewer mistakes and have more confidence working with a VCS that continues to baffle me. More so, with the --simulate flag, I can see what commands will be run, so if I do have to do manual intervention or want to make sure what will be run next is what I really want to do, I have that control.

While I wrote gut to make my life and the life of my coworkers easier, it is a good proof of concept for what I think needs to be done to really bring complex VCS "to the masses". In order to really tackle workflow wrappers for VCS, there should be a way to:

  1. precisely define the workflow that is being used

2. be able to build a tool like gut from this workflow definition automatically

  1. have wrappers that are more robust