Git ‘er done

If you wanted a distribution channel for text files that is practically uncensorable and highly resistant to being taken over by hostile gatekeepers, you could do worse than the open-source software program git and the sharing platform GitLab. Git lets you manage arbitrary text files and share them with anyone that downloads the software. GitLab and its better-known competitor GitHub let you easily share projects.

If outside pressure comes along demanding GitHub or GitLab get rid of your project, losing access to either or both of the hosting platforms isn’t the end of the story. You can install a version of GitLab on your own server and keep working with the nice abstractions that the sharing platform software provides on top of git or even just share the repository on the Internet as a directory and just use git. Even a search and seizure of all your computers is just a bump in the road because anyone who has cloned your repository has all the files and can publish them.

The hostile gatekeeper problem is handled by the project license, which should allow others to fork (copy and make a legal clone of) a project and the nature of git. Everyone who grabs the project is cloning it onto their local hard drive. It’s trivial to get around the gatekeeper so why bother being a jerk about other people participating? Someone will clone the project, behave better, and replace the misbehaving gatekeeper.

Since everyone gets a copy of shared content in their own fork and everyone can move the project in the direction that they’d like, the risk of doing useless work goes down. You pick what you’d like to add and your own version maintains that addition. Nobody can stop you. Whatever you contribute can’t get deleted later on. You never let it go.

7 thoughts on “Git ‘er done”

  1. OK. I think git might be overkill but its a great …

    Linus got tired of bitkeeper and especially CVS so he wrote git. It was to allow his kernel stuff to be in a better place than using CVS and has become the distributed platform of choice, as Linus don’t write no crap.

    Hope that works for you.

  2. Linus got tired of bitkeeper

    No, he didn’t. My somewhat fuzzy memory of the episode was that Andrew Tridgell reverse engineered the BitKeeper protocol, a violation of Larry McVoy’s terms for free use for Linux development, resulting in a threat to end free use. Linus was annoyed with Tridgell, but didn’t need the hassle, so went looking for a replacement. Several were under development, but none of them was ready or had the speed he wanted, so he took a couple of months off from Linux and wrote the early, very rudimentary version of git. I expect his time with BitKeeper made that easier because using it gave him a good idea of what he wanted and what could be done.

  3. It was CVS that Linux really did not like. Bitkeeper was just the repository, that Bitmover owned. It went away when they took it away from open source, and tried to charge for it after it was reverse engineered. Reverse engineering was a fun part of early Linux development.

    I suspect Linus learned what not to do, after having to use Bitkeeper.

  4. I suspect Linus learned what not to do

    Linus and McAvoy had spent a long time discussing what Linus wanted in a version control system. In a sense, BitKeeper was *made* for Linus. As Linus said, he used BitKeeper because it was the best tool for the job, he didn’t care if it was proprietary. I had been compiling my own kernels since 1999 and following the Linux mailing list, so I’m not completely unfamiliar with the topic.

  5. I go back to Slackware 3.2 myself and built all my damn kernels for decades. I built all kinds of other stuff as well, as its nice to build against what you actually need.

    I don’t doubt it was the best tool for the job, but all the baggage was a real pain.

  6. but all the baggage was a real pain.

    What baggage? The only controversy I recall was that it was proprietary. It was a distributive system like git, an idea McAvoy had been developing since the 1990’s when he was working at Silicon Graphics. I even recall the time that BitKeeper flagged an attempt to sneak in a backdoor, the hashes of the public repo didn’t match what Linus was using. Someone had changed `==` to `=`, escalating a user to root privilege instead comparing against it. An investigation followed.

  7. The baggage you describe. Using non free software was the real problem.

    A great many Linux users did not like blobs, outside of course Nvidia’s. ;)

    I worked for Carmack for a while, making the Matrox drivers for Linux Quake. I had to compile almost a year’s worth of kernels to find the one that broke dual processor performance, as my job was testing dual processor setups, as I had one.

Comments are closed.