Jammy Gits

March 7, 2013 6:15 AM

GitHub was intended to be an open software collaboration platform, but it’s become a platform for much, much more than code. It’s now being used by artists, builders, home owners, everyone in between, entire companies … and cities. - The GitHub revolution.
posted by Artw (58 comments total)

I use subversion for my scientific writing and collaboration, but I am moving to GitHub soon. So add "scientists/writers" to the list. My thought is that after a project is done, I can make the whole repository public, increasing the transparency of my research to nearly 100%, and even enabling people to suggest changes later.
posted by Philosopher Dirtbike at 6:25 AM on March 7 [3 favorites]

Github is pretty amazing for quickly creating lightweight single-page sites, documentation, texts, articles, tutorials, etc. Just create a repository with a README.md file and start writing your stuff using markdown. Did I mention you do all of this in the browser with just a few clicks? Awesome. People can then read your stuff by simply visiting the front page of your repository, no wacky URLs required. There are other options for hosting content on GitHub.
posted by Foci for Analysis at 6:28 AM on March 7 [3 favorites]

I love Github, but I'm not sure I would classify it as "decentralized." Projects on Github are very much centralized – on Github's servers. It would be decentralized if git somehow allowed for a bit-torrent-esque distributed hosting network. (Which would be a terrible idea for source control, but might work for other types of projects.)
posted by deathpanels at 6:28 AM on March 7

Similar to Philosopher Dirtbike, I am working on an economic measurement tool looking at a lot more than the usual stuff - things like safety, health outcomes, community belonging, confidence, housing affordability - and last year I released the whole backbone and all raw data in an effort to be transparent.

I have been playing around with GitHub and think it might be the easiest way to be transparent and to encourage people to take the model and run with it.
posted by Rodrigo Lamaitre at 6:30 AM on March 7

I love Github, but I'm not sure I would classify it as "decentralized."

I tend to think of it more as disorganized. Sometimes it is impossible to even figure out where the 'real' version of something is. It's brilliant but not perfect.
posted by srboisvert at 6:39 AM on March 7 [1 favorite]

I love Github, but I'm not sure I would classify it as "decentralized." Projects on Github are very much centralized – on Github's servers. It would be decentralized if git somehow allowed for a bit-torrent-esque distributed hosting network.

I think 'decentralised' means 'distributed' and 'in contrast to SVN'. If you're going to release a build, you've got to privilege some version of it, after all.

Sage is supposedly moving to Git (and I assume Github). I'm kind of excited because I don't really understand Mercurial and use Git for my own stuff, but I also shudder to think how unwieldy one giant Sage repository will be. (Right now, there is one giant repository, but most people, including me, don't see it ever.)
posted by hoyland at 6:42 AM on March 7

Git itself is far more decentralized than GitHub. Interesting how the two have become conflated.
posted by Artw at 6:43 AM on March 7 [1 favorite]

I love Github, but I'm not sure I would classify it as "decentralized." Projects on Github are very much centralized – on Github's servers. It would be decentralized if git somehow allowed for a bit-torrent-esque distributed hosting network. (Which would be a terrible idea for source control,...

(This is only partly a reply to you; it's also a simple explanation of WTFIsThis to everyone else. Most programmers I've met don't even know anything about distributed version control.)

Github uses git which, along with bzr and mercurial, are "distributed version control" systems. Most (all?) previous VC systems operated on a hub and spoke model. Everyone checks out from the server and checks into the server. Distributed VC systems allow you to do that too, but also to do much much more. Pretty much any topology is possible.

You can "branch" off from a project and then people can branch from you and so forth and you can all merge with each other in any order and it Just Works. None of those branches have to be on Github. Github is just a convenient location to put things for some people. Like if I want people to be able to branch from me without wanting them to get to my machine itself, I can put a branch up on Github to point them too. In a sense, then, you CAN use it as a torrent-like distribution mechanism.

That's the sense in which Github is decentralized. Obviously Github has a particular location and in that sense it is a "center". But it's location is not special other than being conventional.

Also, torrents would be a fine idea for source control (of large projects) because Everything Is A Branch. You'd just download the whole thing, then pull down changes since the branch was created and bam. All these systems already support submitting patches or merging via, say, email. Torrent is just another vector.
posted by DU at 6:43 AM on March 7 [5 favorites]

I love Github, but I'm not sure I would classify it as "decentralized." Projects on Github are very much centralized – on Github's servers.

Well, yes, but that isn't the meaning of "decentralized" as I understand how git uses it. My understanding is that the "decentralized" aspect is the fact that the forking process is central to how git works.

On preview, what DU and hoyland said.
posted by Philosopher Dirtbike at 6:44 AM on March 7

I love Github, but I'm not sure I would classify it as "decentralized." Projects on Github are very much centralized – on Github's servers. It would be decentralized if git somehow allowed for a bit-torrent-esque distributed hosting network.

It more or less does. Using Git in no way requires GitHub, you can sync your Git repos with any remote URL, and there are myriad ways of structuring your Git workflow. All it would take for a torrent-esque distributed Git network is for someone to build one.

On preview: what DU, hoyland, et al said.
posted by The Michael The at 6:44 AM on March 7 [1 favorite]

Oh and when we were going to switch from CVS to SVN at work, someone happened to point us to bzr at just the right time. The transition was a tiny bit painful, but only mentally. Now that I Get It, the world is a much, much better place than under the old model.
posted by DU at 6:45 AM on March 7 [1 favorite]

Free hosting for open source stuff is nice, but the fact that it's not open-source itself is kind of lame. You can't just run your own github web-interface on your own server - and if you want to work on a project privately with just a few people you do need to pay for it. (Obviously git itself is open source, just not the website)

I think 'decentralised' means 'distributed' and 'in contrast to SVN'. If you're going to release a build, you've got to privilege some version of it, after all.

Git is a distributed version control system. Github a cloud hosting service designed for software developers that interfaces with git.
posted by delmoi at 6:45 AM on March 7 [1 favorite]

I'm partial to Mercurial for coding work, so use Bitbucket for my personal projects. But I'm glad Github's great UI is helping version control spread beyond software development. My dream is that legislation will one day be published as diff files against the U.S. code.
posted by gsteff at 6:45 AM on March 7 [8 favorites]

Git is a distributed version control system. Github a cloud hosting service designed for software developers that interfaces with git.

DU has written what I meant much more thoroughly that I did, obviously.
posted by hoyland at 6:47 AM on March 7

My dream is that legislation will one day be published as diff files against the U.S. code.

forkthelaw.org
posted by The Michael The at 6:47 AM on March 7 [6 favorites]

the fact that it's not open-source itself is kind of lame

I long ago drank the open source Kool-Aid, but do you really believe people who build a useful service on top of open source are morally obligated to give their work away too? Should I be able to crash at their place if I'm in town as well?
posted by yerfatma at 6:48 AM on March 7 [2 favorites]

You can't just run your own github web-interface on your own server...

apt-get install gitweb, looks like.
posted by DU at 6:51 AM on March 7 [1 favorite]

> ... and it Just Works

git does have a fairly fierce learning curve, and many business document formats really don't work well with text-based diffs. I mean, my counsel might be down with editing legal docs in MarkDown, but he's an old-school computer hobbyist and in a tiny minority.
posted by scruss at 6:51 AM on March 7 [2 favorites]

FWIW, the main thing I prefer about Mercurial is that running "hg serve" gives me an instant, zero configuration web UI no matter what machine I'm on. The last time I checked, Git came with a CGI-style web UI, but you had to provide your own server.
posted by gsteff at 6:55 AM on March 7

I long ago drank the open source Kool-Aid, but do you really believe people who build a useful service on top of open source are morally obligated to give their work away too?

Morally obligated? What are you talking about? I said it was lame that you couldn't run your own version on your own server, because being able to do that would be convenient. Git is free if you're working on open source software, but if you want a private repository you need to either.

I think it would be helpful if people who write and distribute open source software used all open source software to do that distribution.

apt-get install gitweb, looks like.

DU: this is what a gitweb install looks like. It's a completely different system. this is a repository on github.

There seem to be a lot of people in this thread who don't seem to understand that git and github are completely different things. From completely different people. One is an open source tool, a version control system written by Linus Torvalds himself originally to maintain the Linux Kernel. The other is a closed-source cloud hosting provider like Dropbox or Amazon S3 designed around hosting git repositories - which you have to pay for if you want private repositories. You can use git to post stuff to github.
posted by delmoi at 7:00 AM on March 7 [1 favorite]

git does have a fairly fierce learning curve, and many business document formats really don't work well with text-based diffs.

This has nothing to do with the nature of business documents and everything to do with proprietary, binary formats that Microsoft has locked businesses into.

this is what a gitweb install looks like. It's a completely different system.

Yes, I know the difference between git and github. I was responding to the implication that there was no way to get an interface to git on a web page other than going through github.
posted by DU at 7:06 AM on March 7 [1 favorite]

I use Mercurial at work, and it was the first DVCS that I ever got familiar with, but I'm a total git partisan at home. I think the ability to edit commits is a fine idea (although I wouldn't mind its omission in Mercurial if Mercurial allowed for staged commits, which just seems like a totally obvious mistake-prevention feature to me), and it's still a little weird about named branches. But, I mean, it's still a universe away from the old bad world of SVN and that's what really matters.
posted by invitapriore at 7:07 AM on March 7 [1 favorite]

Free hosting for open source stuff is nice, but the fact that it's not open-source itself is kind of lame.

Gitlab does a perfectly good job of this. To be fair, you probably don't want the real Github codebase, which succumbs to every Rails exploit and is rewritten pretty frequently (based on how often their blogposts talk about phasing out an in-house developed system or how often the UI changes). However, they do try to make their most useful parts loosely coupled and release them independently, like Resque.
posted by 23 at 7:09 AM on March 7 [1 favorite]

delmoi: you can run github software on your own servers. It's called GitHub Enterprise.

It costs money though. $5k per year for 20 users. Also, this is just a license to use the software, there is no access to the source.
posted by sideshow at 7:09 AM on March 7

I'm pretty sure there are github workalikes both cloud- and local-based. I did a quick apt-cache search to prove the point, but I don't use git myself so I'm unfamiliar with the details. Several hits for "git web server".
posted by DU at 7:13 AM on March 7

Heh. The important thing about open source - the arguing.
posted by Artw at 7:15 AM on March 7 [21 favorites]

So, I've been happy with basic use of RCS, and have started dealing with SVN now for work (and it pisses me off that there's no trivial "roll back this change" tool and instead I have to check out the previous version and check it back in), but only for fairly straightforward no-forking changes. But suppose I want to start mucking around with git... Anyone have a pointer for a good tutorial that won't assume I'm starting out already being savvy with VC systems?
posted by rmd1023 at 7:22 AM on March 7

git does have a fairly fierce learning curve, and many business document formats really don't work well with text-based diffs. I mean, my counsel might be down with editing legal docs in MarkDown, but he's an old-school computer hobbyist and in a tiny minority.

If there's anything a lawyer doesn't want it's transparent source control. Lawyers recycle, borrow, and steal snippets of legalese like mad.
posted by ennui.bz at 7:35 AM on March 7

rmd1023, Git Magic from Stanford is the best one. It explains how to actually use it first, then explains the underlying mechanism in a way you can skip if you want.

Way, way too many tutorials explain the underlying workings in too much detail. Yes, it's beautifully simple and quite clever, but it's a little more complicated than you need to understand to use the damn thing, so you're just scaring people off.
posted by 23 at 7:37 AM on March 7 [10 favorites]

Thanks!
posted by rmd1023 at 7:39 AM on March 7

I would say that the git model is implicitly decentralized; that is to say, you can set up a workflow where you work locally and push to a remote repository; this makes the most sense if you're working with a team, or if you just want to keep a safe remote copy of your work in case of catastrophe. But unlike CVS or SVN, every working copy of a git repository is a self-contained clone with the complete revision history as of the moment you cloned it; Whether the server or your local machine goes up in a ball of flame, at least some the project and its edit history can be salvaged from one of the extant copies.

Bitbucket is a similar service which (for the time being anyway) lets you create unlimited private repositories for free for teams of up to 5 people. (I have no stake or affiliation, I was just thrilled to be able to move my private repositories there instead of maintaining my own clunky gitolite server.)

A PSA for anyone who does any kind of coding, from HTML to C++, and doesn't use some kind of version control system: You need to start right now, even sooner if you're part of a team working on the same code. You know how you have about fifty different versions of every file in your project, named things like


index.html
index.html.good
index.html.0
index.html.1
index.html.orig
index.html.orig.modified
index.html.orig.modified_1.backup

...and you don't remember what the hell the difference between any of them is but you don't want to delete them because there might be something important in one of them? That is what version control is for.

You make your edit to index.html, commit it to your repository with a message describing the changes you made, and forget about it. You can always view a concise changelog of all the changes you've made to any file in the project, and if for some reason you need to go back to an older version of a file, you can. In a team environment you can easily see who changed what and when, and if there's a collision you'll need to sort it out manually but that's worlds better than someone losing hours of work when someone else overwrites a file at the same time. If you want to try something totally different but aren't sure it's the way to go, you can start a whole new branch in your code and leave the stable code alone.

I was fortunate to be introduced to SCM pretty early on as a web developer - a company I worked for had an enormous web site of static HTML files, and anyone who touched the site had to use Perforce. Versioning my code is such a deeply ingrained habit at this point that I forget that plenty of people still do the "Overwrite the one authoritative copy on the server and hope I can remember how it was before I broke it" thing. It chills my blood to imagine working like that!
posted by usonian at 7:44 AM on March 7 [3 favorites]

Came in here to say what has already been said, but in a slightly different way in order to take credit and confuse people about what the actual true version of the words is.
posted by blue_beetle at 7:49 AM on March 7 [7 favorites]

What a silly, breathless article.

Github has changed how I've done things over the past four years largely for the better, but I would like to suggest a blanket moratorium on the word democratization used for technical or network projects. Making things easier for lots of people is very much not the same as making them more democratic. Git is reducing communication costs and Github is providing a centralized location for performing that communication, but it's no more democratic than Facebook. I still routinely fail to notice or simply ignore or procrastinate pull requests on my projects, a highly undemocratic outcome. Other users could decide to collectively bless a new fork as the true version of something, but revolution is not necessarily democratic either. Democracy is process, git is protocol.
posted by migurski at 8:48 AM on March 7 [3 favorites]

Is... Is your title... is it a Muffy Tepperman joke?
posted by humboldt32 at 8:54 AM on March 7

I use ssh on one of my Linux servers for most of my git repos, personally, and use the same setup at work internally. If I need to make it available briefly but do not wish to give shell access, it's as simple as pointing Apache to the directory it's in, as git will transport over http/https (in "dumb" mode wrt pack files, and read-only obviously). Good enough for most things.

I like GitHub -- it's sure a lot better than google code or *shudder* SourceForge -- but I don't feel it brings all that much to the table for non-collaborative projects, of which I have many. I always run across people's dotfiles and other sundries and find it a little baffling. If I put every repository (formerly svn subdirs) there, it'd just be a mess of stuff crowding out the useful things.

I did move my larger public projects (that other people use) from google to GitHub and I'm happy with it there, but to be honest I feel the web interface frequently gets in the way of proper git usage. I'm a bit of a git cli evangelist, though, and can extract information from the hilariously complicated log/diff syntax faster than with their UI, but I can see that not being the case for everyone. And I really wish people wouldn't fill out commit logs and such with those crappy browser text input boxes..

It's very nice for the collaborative aspects, though, and Markdown is just great.
posted by cj_ at 9:13 AM on March 7 [1 favorite]

Speaking of running across people’s dotfiles, Aldo Cortesi has been blogging Things Found On Github, including aspell custom dictionary entries, pipe chains, and shell histories. He’s performing a bit of analysis and interpretation on what he finds to come up with observed usage patterns for command line interaction. Fascinating stuff.
posted by migurski at 9:24 AM on March 7 [2 favorites]

Artw: Git itself is far more decentralized than GitHub. Interesting how the two have become conflated.

Link was borked. Correct Git Wikipedia entry.
posted by IAmBroom at 9:30 AM on March 7 [1 favorite]

DU: Also, torrents would be a fine idea for source control (of large projects) because Everything Is A Branch. You'd just download the whole thing, then pull down changes since the branch was created and bam. All these systems already support submitting patches or merging via, say, email. Torrent is just another vector.

I'm failing to see how torrents would accommodate version control (unless that's a very different thing from source control).

I torrent Code_X. You update Code_X while, or shortly after, I download the previous version. I make changes, and update Code_X - what's in place to keep my version from overwriting your version?

ELI45?
posted by IAmBroom at 9:40 AM on March 7

Hah, those blog posts are great. I didn't realize so many people threw their ~ on github as-is. Doesn't seem like such a hot idea..

I wonder how many of those ps | grep pipe chains have grep -v grep. I always twitch a little when I see that.
posted by cj_ at 9:43 AM on March 7

I was responding to the implication that there was no way to get an interface to git on a web page other than going through github.

What implication? I said: " You can't just run your own github web-interface on your own server...". And, since git and github are different things, I couldn't possibly have made any implication about git at all, because I was talking about github. Which, again, is a totally separate thing.

Gitlab does a perfectly good job of this. To be fair, you probably don't want the real Github codebase, which succumbs to every Rails exploit

That looks a lot better then gitweb. What I would actually like to see is other open source developers support the open-source solution, since that would actually result in more development and a better system for everyone to use.

So, I've been happy with basic use of RCS, and have started dealing with SVN now for work (and it pisses me off that there's no trivial "roll back this change" tool and instead I have to check out the previous version and check it back in),

If you could roll back changes, then it wouldn't be a very good version control system because it would mean you could actually destroy data. What happens if you roll something back, then change your mind? Would your stuff just be gone?

If you want you can fork, then if you decide you don't want that fork you can delete it - the fork will just disappear from future versions of the repository, old versions will still have it.

I use ssh on one of my Linux servers for most of my git repos, personally, and use the same setup at work internally. If I need to make it available briefly but do not wish to give shell access, it's as simple as pointing Apache to the directory it's in, as git will transport over http/https (in "dumb" mode wrt pack files, and read-only obviously). Good enough for most things.

One of the cool things about git is that if you want read right you don't need to setup any special protocol to handle read/write remote access. It just uses SSH as the protocol, so you don't need to worry about setting up a server or reconfiguring a webserver. With SSH it uses WebDAV which means you need to configure apache to handle that, along with HTTPS as well, obviously. With git you don't have to do any configuration at all, aside from installing it on the server.
posted by delmoi at 9:49 AM on March 7

If you could roll back changes, then it wouldn't be a very good version control system because it would mean you could actually destroy data. What happens if you roll something back, then change your mind? Would your stuff just be gone?

That's not what 'roll back changes' means, I don't think. It's popping a patch off a Mercurial queue or going back a commit or two and forking in Git.
posted by hoyland at 9:53 AM on March 7

I torrent Code_X. You update Code_X while, or shortly after, I download the previous version. I make changes, and update Code_X - what's in place to keep my version from overwriting your version?

Both would sit side by side, presumably. The problem with a torrent system is what happens when the system gets overloaded? Stuff just randomly gets deleted?
posted by delmoi at 9:54 AM on March 7

That's not what 'roll back changes' means, I don't think. It's popping a patch off a Mercurial queue or going back a commit or two and forking in Git.

Well, you can fork in SVN off an old version if you want. In SVN forking is just like creating a new folder with a copy of the main directories files. So you have, for example, stuff like /repo/trunk and forks like /repo/fork1, /repo/fork2 and so on. So you can pull revision N-3, then fork that to another folder. Of course, when you do that it will increase the revision number.
posted by delmoi at 9:58 AM on March 7

One of the cool things about git is that if you want read right you don't need to setup any special protocol to handle read/write remote access. It just uses SSH as the protocol, so you don't need to worry about setting up a server or reconfiguring a webserver. With SSH it uses WebDAV which means you need to configure apache to handle that, along with HTTPS as well, obviously. With git you don't have to do any configuration at all, aside from installing it on the server.

Not even that, in many cases. If you use `git update-server-info`, the contents of the .git folder are directly usable over HTTP. You can throw it up on S3 or archive.org and people will be able to clone from it. Linus Torvalds really outdid himself with the design of Git.
posted by migurski at 10:18 AM on March 7

> This has ... everything to do with proprietary, binary formats that Microsoft has locked businesses into.

Producing a meaningful delta between two even XML documents is much harder than it looks. I don't mean a diff-style line difference, but a real redline report containing element additions, deletions and modifications by user and time. Code needs to have a trivially simple document structure (hey, a computer has to understand it!) so it only needs simple tools to manage it.

I think I've recovered from managing a book project where chapters were written in some ancient Unix word processor and then checked in using SCCS. It managed binary files by uuencoding them, then running the versions through diff -c ...
<shudders slightly>
posted by scruss at 11:14 AM on March 7 [1 favorite]

That's not what 'roll back changes' means, I don't think

I have / companies I've worked at have always used the term "roll back" to mean:

Source control system gives me a patch/diffset that takes trunk/current branch back to state before change 123 happened.
I now commit this patch/diff as a new change (124 lets say). So now 122 and 124 are identical. But 123 is still in the system, nothing has been destroyed.

Basically its a shortcut for manually creating a change that reverses the effect of a previous change.
posted by wildcrdj at 12:17 PM on March 7

Or as Git would say, "revert".
posted by nicwolff at 12:39 PM on March 7

Mercurial actually uses the term "rollback" to describe a destructive revert to the parent of the current head, though you can't apply it recursively, i.e. a changeset that has ever had a child can't be rolled back on. Now that I think about it I guess it's technically the solution to my gripe above with respect to Mercurial's lack of staging.
posted by invitapriore at 12:46 PM on March 7

... have grep -v grep. I always twitch a little when I see that.

Okay, I give. I do that frequently, and don't see the downside or alternative. Explain?
posted by benito.strauss at 1:39 PM on March 7

I think the implied alternative is pgrep, the default behavior of which just outputs the pids of the processes matching the pattern which are not the instance of pgrep doing the searching. It's certainly convenient, but as far as downsides go I think it's on the same level as redundant cat invocation -- in 99.99% of cases it's just a matter of extra keystrokes.
posted by invitapriore at 1:53 PM on March 7 [1 favorite]

We've been dabbling in git at $EMPLOYER and I think it truly works better in an open source environment than SVN. I'd still argue that SVN works better in a corporate dev environment where everyone is ostensibly working on putting out the same release and not running their own hooch still in the back corner of their cube^[1]. The same behavior can be copied in git, but it feels overly constrained because it is so flexible otherwise.

Where we have found it to be truly useful is as an intermediary between disparate repositories. Because mergers and acquisitions are such fun from an SCM perspective, as of late I've been pulling a lot of different version control schemes into our corporate-approved SVN world. There's a lot of tooling for sucking in and spitting out around git and it seems to be a lot more robust than some of the other things we've tried.

I'd also recommend getting into [almost] any kind of version control paradigm as soon as possible for just about any workflow scenario you might be presented with. Back when I was a computer lab monkey for $LOCAL_CAMPUS I presented a simple version control class for masters/phd students hoping that just one or two of them would use version control for their dissertations instead of whatever crap Word-based workflow they could come up with. Trying to help, on average, two students per semester try to pick up the pieces after moving ~FILENAME.doc instead of FILENAME.doc to a network share or some flavor of file corruption is painful.

^[1] I primarily work in an SCM / build monkey / installer-writing role so my perspective on cat herding may be a bit skewed toward the cynical from the average developer. Take my commentary for what it's worth there.
posted by Fezboy! at 3:00 PM on March 7 [1 favorite]

I'm a big fan of git and GitHub. I recently collaborated with them and an open access journal to flesh out more use cases for git and science. Shameless self promotion below:

Version Control for Scientific Research (my guest post with a collaborator)
My accompanying review paper.
posted by special-k at 5:06 PM on March 7 [3 favorites]

Gitlab does a perfectly good job of this. To be fair, you probably don't want the real Github codebase, which succumbs to every Rails exploit

That looks a lot better then gitweb. What I would actually like to see is other open source developers support the open-source solution, since that would actually result in more development and a better system for everyone to use.

Gitlab has over seven thousand stars and a thousand forks on Github. I'd say it's pretty well supported for a very new project. We use it at work and I'm happy with it.

I torrent Code_X. You update Code_X while, or shortly after, I download the previous version. I make changes, and update Code_X - what's in place to keep my version from overwriting your version?

I don't really understand the whole torrents-as-version-control idea - you get no real branch support, you have to download new torrent files all the time, you have to re-download the entire source package every time... If you make a source control system rely on torrents you'd have to write all the actual source control functionality on top of it because nothing about the way torrents work is going to help you. I think they're a pretty good distribution mechanism for releases, though.

We've been dabbling in git at $EMPLOYER and I think it truly works better in an open source environment than SVN. I'd still argue that SVN works better in a corporate dev environment where everyone is ostensibly working on putting out the same release and not running their own hooch still in the back corner of their cube.

I hear this a lot when git comes up. I understand that someone being able to check in without sharing their code could cause nightmares if you think of version control in a certain way, but I'm not sure how this is different from someone running their own branch in SVN or just not checking code in at all until the last minute. Any number of rules - even just "strongly encouraged" daily checkins - can nip this in the bud. Surely you only QA code in source control?

I think there are severe problems with SVN that make it unsuitable for normal use, and that these are worse than the guy hiding in the corner:

- If you breathe on the filesystem of the master repository everything will break
- Can't checkout part of the history (so if you have a repo that's been around for ten years...)
- Weird properties on top of filesystem metadata which are usually broken, causing unchanged files to be marked as changed (see here)
- tags can change, which makes them meaningless

Additionally, being able to check in without sharing gives a number of advantages. You can check in code, find a bug in it, fix it, and then merge the commits - essentially making it like there was only one - before sharing your history with anyone. You can check in code without testing it at the end of the day but just keep it in your scratch work branch. You can make branches without having to check you're not screwing up anyone else's namespace.

I know that technical measures can't fix social problems. If using git would lead to people hiding their code at your company, you should probably stick with SVN. However, if that's the case, I'd say you have bigger problems than what version control system you're using.
posted by 23 at 5:20 PM on March 7

The H is capitalized, you people are killing me.

Anyway, if what you want is repository hosting, there are a variety of options. People find GitHub useful and valuable for the tools and workflow it adds around simple repository hosting. Git is not a version control system, it's a tool for building your own version control system, and GitHub's system is a different animal than GitLab, Gitorious, gitweb etc.
posted by thedaniel at 9:59 PM on March 7

I think git is awesome. It should get the Nobel Peace Prize for 2000-2009.

But the article is a little hyperbolic. It's just as easy to share stuff as it was 30 years ago, when you'd email someone a patch file. Now the patch file has a SHA-1 signature and is associated with a parent commit, and other stuff. Good stuff, to be sure, but it makes things *easier*, not *possible*.

Github is great too, but it's more notable for being a place where people can show off their talents. It's LinkedIn for coders. I like that idea, because I like getting rid of my LinkedIn account.
posted by RobotVoodooPower at 10:21 PM on March 7

> It's just as easy to share stuff as it was 30 years ago, when you'd email someone a patch file.

You can't be serious. Doing any serious development with a group - or even solo - at any velocity is almost impossible that way.

Here's me and here's my biggest open source project. That second one's interesting - I have 642 commits to it and I'm the only committer. While there are (too many) huge commits in there, a majority of them are small or tiny.

When we were sending patches around, if you sent someone a dozen patches in a day they'd punch you out. But very small changes are the way to go (if you can pull it off).

I work as fast as possible, making tiny changes, testing that change only, and checking them in. If my change breaks the system, I spend a little time trying to see what it is, but if it's at all puzzling I revert the change and do it again.

Periodically I do system tests - if I break something I have to figure out what I did. I don't often break things that I can't figure out - but the obscure ones can be very obscure! But then I have a whole array of tools like git bisect that let me quickly figure out where I broke things.

That's just me, as one person. My other big open source project has three major developers including me and several other people - all part-time. Multiple branches, we all work in the same dev. branch, and mainly avoid breakage. I can't conceive of how you'd keep track of this all without some source control system.
posted by lupus_yonderboy at 11:06 PM on March 7

> Doing any serious development with a group - or even solo - at any velocity is almost impossible that way.

And... how did we do it in the old days? We simply accomplished a heck of a lot less. I do in a day what would have taken me a week to do a decade ago. God knows how long it'd have taken to do this stuff 30 years ago when I had my first programming job - actually, I can say that everything I'm working on would have simply been difficult to even conceive of then and impossible to accomplish if you had.
posted by lupus_yonderboy at 11:12 PM on March 7

suppose I want to start mucking around with git... Anyone have a pointer for a good tutorial that won't assume I'm starting out already being savvy with VC systems?

Pro Git is pretty good.
posted by flabdablet at 11:21 PM on March 7