Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

masak (6289)

  (email not shown publicly)

Been programming Perl since 2001. Found Perl 6 somewhere around 2004, and fell in love. Now developing November (a Perl 6 wiki), Druid (a Perl 6 board game), pls (a Perl 6 project installer), GGE (a regex engine), and Yapsi (a Perl 6 implementation). Heavy user of and irregular committer to Rakudo.

Journal of masak (6289)

Thursday October 23, 2008
11:13 AM

Nonlinear development history

[ #37721 ]

This summer when we started the November project, we chose git as our revision control system. During the past week, seeing how we have been effortlessly throwing around commits and branches — we're up to five right now — and generally being very productive in our environment, I think I'm not just learning to live with git, but actually starting to like it.

Wikipedia has this to say: "Git supports rapid branching and merging, and includes specific tools for visualizing and navigating a non-linear development history."

One such tool is the network graph at github. Here's a snapshot of the last few days of development in November. Four of our five active branches are visible.

I've gotten into the habit of checking that graph regularly. Partly to see if anyone's committed anything new, but partly because seeing that graph is like getting a message from git, saying "here's all the complexity I'm handling for you automatically". Because, the thing is, doing branching and merging doesn't feel complicated. Branching and merging is rapid and painless, and has that It Just Works feeling to it.

As John Wiegley says in Git from the bottom up, "Most other systems have led me to believe they've reached their conceptual plateau — that all else from now will be only a slow refinement of what I’ve seen before. Git gives me the opposite impression, however. I feel we’ve only begun to see the potential its deceptively simple design promises."

Thanks, git.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • In fact, I have found that as I understand git better, what happens is I understand its simplicity ever better – not its complexity. It is difficult to learn because its command line interface obscures the underlying simplicity of its repository format. Understanding that format and relating what a command does to that format is the key to understanding git, which is actually much easier than it initially seems. I have actually toyed with the idea of reimplementing the format in pure Perl – it w

    • Aye. I should perhaps add that I was referring to the complexity of managing distributed changes to a common file tree, not the complexity of git (which I agree has a very simple design).