Tag: git

Forking is a Feature

THE ONE TRUE VERSION
Most importantly, the new culture of ubiquitous forking can have profound impacts on lots of other categories of software. There have been recent rumblings that participation in Wikipedia editing has plateaued, or even begun to decline. Aside from the (frankly, absurd) idea that “everything’s already been documented!” one of the best ways for Wikipedia to reinvigorate itself, and to break away from the stultifying and arcane editing discussions that are its worst feature, could be to embrace the idea that there’s not One True Version of every Wikipedia article.

A new-generation Wikipedia based on Git-style technologies could allow there to be not just one Ocelot article per language, but an infinite number of them, each of which could be easily mixed and merged into your own preferred version. Wikipedia already technically has similar abilities on the back end, of course, but the software’s cultural bias is still towards producing a definitive consensus version instead of seeing multiple variations as beneficial.

There are plenty of other cultural predecessors for the idea of forking, all demonstrating that moving away from the need for a forced consensus can be great for innovation, while also reducing social tensions. Our work on ThinkUp at Expert Labs has seen a tremendous increase in programmers participating, without any of the usual flame wars or antagonism that frequently pop up on open source mailing lists. Some part of that is attributable to the cultural infrastructure GitHub provides for participation.

Moving forward, there are a lot more lessons we can learn if we build our social tools with the assumption that no one version of any document, app, or narrative needs to be the definitive one. We might even make our software, and our communities, more inclusive if we embrace the forking ourselves.

or more accurately, easy forking and easy merging is. the author goes off the rails towards the end saying that forking wikipedia would be good.

Commit Policies

Policies implement the intent of the salmon run. By placing unrestrictive policies to the left, I can checkpoint my work frequently. By placing restrictive policies on the right, I can maintain the stability of releases. And by incrementing the restrictiveness of these policies in small steps, I reduce the backlog of code that is “trapped” towards the left. Compare this to a centralized VCS, in which (since there’s no local repository), developers may keep changes out of VCS for hours or days (since the alternative is making a central branch, which is expensive to create and expensive to tear down). Or compare to a DVCS system without an index, where the overhead of either making and tearing down branches, or of pruning temporary commits, can discourage a developer from making a checkpoint every minute or 2. (At least they discourage me, even though these operations are far less expensive than with centralized VCS.)

i like the notion of having chained stores with increasingly higher bars between them. pretty obvious between head and release branch, less so between working dir and head

Git Workflow

Here’s my path to enlightment, and how I ended up using the index in my particular workflow. There are other workflows, but this one is mine. What this isn’t: a Git tutorial. It doesn’t tell you how to set up git, or use it. I don’t cover branches, or merging, or tags, or blobs. There are dozens of really great articles about Git on the web; here are some. What’s here are just some pictures that aren’t about branches or blobs, that I wished I’d been able to look at 6 months ago when I was trying to figure this stuff out; I still haven’t seen them elsewhere, so here they are now.

i hope we move to git soon. perforce is getting on my nerves.

Git is the next Unix

With git, we’ve invented a new world where revision history, checksums, and branches don’t make your filesystem slower: they make it faster. They don’t make your data bigger: they make it smaller. They don’t risk your data integrity; they guarantee integrity. They don’t centralize your data in a big database; they distribute it peer to peer.