Very popular because of GitHub.
May'2008: Oliver Steele describes his workflow. I use the index as a checkpoint. When I’m about to make a change that might go awry — when I want to explore some direction that I’m not sure if I can follow through on or even whether it’s a good idea, such as a conceptually demanding refactoring or changing a representation type — I checkpoint my work into the index (by doing add but not commit). If this is the first change I’ve made since my last commit, then I can use the local repository as a checkpoint, but often I’ve got one conceptual change that I’m implementing as a set of little steps. I want to checkpoint after each step, but save the commit until I’ve gotten back to working, tested code... I actually don’t want the fine-grained history in the repository. I might make a checkpoint every five minutes, and many of these checkpoints are pretty low quality; I don’t want them persisted.
he compares to a different style/workflow used by Ryan Tomayko, which works around his habit of working on unrelated chunks of code in the same working copy, then realizing he wants to commit just some of that work (The Case of the Tangled Working Copy.) The Index is also sometimes referred to as The Staging Area, which makes for a much better conceptual label in this case. I tend to think of it as the next patch: you build it up interactively with changes from your working copy and can later review and revise it. When you’re happy with what you have lined up in the staging area, which basically amounts to a diff, you commit it. And because your commits are no longer bound directly to what’s in your working copy, you’re free to stage individual pieces on a file-by-file, hunk-by-hunk basis.
a commenter compares this to Mercurial Queues.
- note that both Oliver's and Ryan's processes focus on a single developer.