I’m really blown away by how nice a bit-o-work git is.
What Eric von Hippel taught me works both ways. Real innovation requires close contact between a interesting problem and talent. When you encounter innovation it signals an interesting problem and engaged talent. Ignore the story told. Look for that problem and why the talent had to fix it. Ask, without the snark: “so what’s his problem?”
It’s a guess, but I think Linus’ problem was two fold. First was a deep passionate desperate need to encourage other developers to take risks with the code. I think his guilty foxy phrase for this is: “They do the work so I can take the credit.” He wants to encourage forking! That’s obvious, once I recognized it. But it’s an insight that was denied me because forking has such a bad reputation. I knew a guy once. He forked, later he had a nervous breakdown trying to rejoin the main branch. An exagerated story sure, but I have suffered dozens of cases where-in good labor branched off and nothing came back. So given those experiances the insight that forking is something an Open Source project would want to encourage, v.s. temper, has left me gob smacked.
But it’s absolutely true. To suppress forking is scarcity thinking. Inside a closed system where you need to husband resources in an open system you need to court it. I know that, I just didn’t get it! Almost the whole point of open source is to cast forth the code so a million eyes and hands can improve it. And every one of those improvements will be a fork. It would be insane to try and keep that from happening. If you don’t enable billions of tiny edits/forks then your killing the seed corn. Since the entire cascade starts there (and it’s scale free) failure to encourage forking undermines the flow back toward the main branch(s).
I didn’t see that, at first. I came to that in a round about way. And damn if I did not have to puzzle out the second insight in a really round about way. I’m embaressed to admit I was not trying to figure out what “his problem” is. No, I was confused by this scenario that appears in most of the tutorials.
Your working on some complex change and suddenly your Boss steps into the room and demands a quick bug fix. What do you do?
... working on complex change ...
git checkout deployed_version
... make quick fix ...
git checkout branch_of_complex_change
... back to work ...
My reaction to that was “Huh, what? you don’t got any diskspace?” Just check out the main branch into a fresh directory and do the work there. In fact I’d be surprised if you didn’t already have a copy checked out. So it took me a while to accept the shocking part was that switching between branches in the same working directory is a common operation. It was only then that I asked “why would Linus want that?” That was the “what’s his problem” moment.
This story is a lie. Linus doesn’t have a boss like the one in that story. Linus lives on the boundry between “they do the work” and “i take the credit.” His boss, and this is critical, is “they.” “They” burst into his virtual office and make demands; in the form of patches. Each of those demands/patches is branch. Managing them is Linus’s problem. At any given time you might have a hundred, thousands even, of such demands/branches. It’s not your Boss coming thru the door that triggers switching from one branch to another; it’s email, irc, and the whims of your attention that do it. When ever your brain thinks “Oh, I wonder if patch Foo does Bar?” you do git checkout Foo, look into the Bar question. A moment later, buffeted by another boss/demand/patch you switch off to another branch.
These two are complementary. That git encourages forking energizes the periphery of your project; that it empowers you to manage a blizzard of patches lets you deal with the consequences. But even if you don’t need to have a vast army of contributors I find that rapid context switching useful. My damn brain is full of contributors too. I can give all these fever’d demons their own branch. You can cast those hot ideas out of your head an into git, stew them over time. It maybe a chaotic mess, but git provides the tools to help manage all that.
While this is a totally different model of branching and forking from the one in traditional source control systems, it is absolutely better. It is better at assuring the improvements are enabled, captured, managed, and nurtured. Full stop.
There is a social aspect to git that deserved it’s own posting. But leave it to say that it’s actually brilliant, from the point of view of somebody more familiar with the ASF’s development models, because it enables and encourage the forming of small groups of common interest around forks. Brilliant because it’s scale free. Brilliant because it creates a locus for socially constructed validation tied to that common interest. Brilliant because it distills out the flow of commits in a canonical form that enables the forks to bud off and remerge smoothly. Brilliant because it removes a huge “ask permission” cost; i.e. in this system you don’t submit patches you mearly reveal them. Notice that word “submit.”
I wrote an essay years ago about what could be done to improve the dynamism of open source. I wrote that there was a virtous cycle between the code base and the user/developers and one thing that we seriously needed was to look at all the friction in that cycle and see if better tooling and practices couldn’t ease them. Git delivers!
