[mechanical_fish]

I don't understand this use case:

These projects are mainly side projects, or small freelance jobs I've done through the years, and I want to save them for posterity; who knows when I'll need them, right?

My solution to this problem is called tar. Just clone the Git repos to /tmp, tar up the results, and push the tarball to S3. Done. Archived for posterity for a few cents per month.

This isn't SVN anymore: It doesn't take special voodoo to host a repo. If nobody needs to push or pull from a repo, tar it up and archive it. If one person needs to push and pull from a repo, store it on that person's local hard drive (with backups, of course). If two people need to push and pull from a repo... Well, this is no longer an archive for posterity, this is an active project, and can the team really not afford to pay Github something like $5 per month per repo?

[frederickcook]

this is an active project, and can the team really not afford to pay Github something like $5 per month per repo?

This is the OP's complaint: once you're over 20 private repositories, you're paying $100/month. He wants stupid-simple, hosted, private git repositories, and lots of them. He probably ran a bunch of numbers on servers, storage, and bandwidth, and found that he run a simple, low-cost hosted git solution (without all the fancy web features) at a fraction the cost.

There was an opportunity in the market to make a simple, low-cost competitor to github, and he built it. Kudos.

[evlapix]

Technically, yes.. waving your command line wand IS a solution. But also, technically, there isn't any reason why you shouldn't be able to keep 100+ small remote git repositories active for less than $100/month.

Also, Github doesn't require you to know how to use tar, S3, or have any other Linux experience. So why should this particular use case? Why wouldn't a business be able to cater to that market?

This is a business, and as such, should be measured as one. Why are we criticizing the "technical necessity" of the product? Are we under the impression that HN is the target audience?

[true_religion]

> Github doesn't require you to know how to use tar ... or have any other Linux experience

You don't need tar to package a git versioned project.

All you need is some kind of zip program, and every major OS has one built in.

The difference knowledge it requires to just zip up a directory and send it in an email, versus running a github connection is so minimal its laughable that anyone suggests that you need some kind of web interface in order to unburden yourself.

> This is a business, and as such, should be measured as one.

I think that this is a solution chasing a problem. However, lets assume that it is a viable business.

The beauty of github was ease of sharing, and the web interface. If you take away the web interface and don't need to share then what's the value proposition here?

All you're getting out of this project is backups of your local git repo. And you know what.... tar is pretty damn competitive when it comes to that arena.

[tptacek]

Doesn't "git bundle" already do exactly this?

[alphakappa]

Yes, you can zip up a repo easily. But where do you store it? Do you really want to save it in your email instead of saving it in some kind of source control so that you can use it as such if you need to quickly commit some change?

Saving it to S3 is an option, but then you have to create that account too. Why shouldn't you be able to just use one account?

[true_religion]

Codespace is in the feature middle-ground between Github and a zipped backup.

It's online and active, but its a CLI only.

To match the functionality of Codespace, you don't need anything as inelegant as S3. If you have a dropbox account, you basically have the same functionality as Codespace offers. And its free.

And as a bonus, you can store other things in dropbox apart from your git repos.

Looking at Codespace, its targeting a space below Github that's already massively serviced by other simpler competition.

Edit:

Let me add. Before using Github, I personally would just open a network drive to my webhost, and save things on there. It was cheap. It was CLI. And as a benefit I could save other things apart from my code there.

[burgerbrain]

If your goal is to have only one account, and you presumably also back things up that are not under version control (who doesn't?), then S3 is clearly the more appropriate route since it can do both.

[jshen]

Write down the steps required to merge changes from 5 different people using your method. Now what are the steps using something like github without the web interface?

There is a big difference.

[vog]

> Write down the steps required to merge changes from 5 different people

This thread (and hence the comment) was about archiving a repository, not about merging it.

[jshen]

The original post was not about archiving only. To argue that archiving is easy, and ignore the other needs, seems to miss the point.

[masnick]

The killer feature of codeplane is cheap shared private git repositories. If you are the only person using your git repo, there is no reason you wouldn't store your remote on some random webhost (you can do this at http://nearlyfreespeech.net for essentially free).

If you want to collaborate with this setup, you would need to create a system-level account for every collaborator on your VPS (ugly) or install something like gitolite (https://github.com/sitaramc/gitolite).

The downside to gitolite is then you are running your own VPS, i.e. are responsible for security, updates, config, etc. It seems codeplane takes care of all the nonsense for you so you can get on with your real project.

As someone who had to set up gitolite because of this exact need, I can attest to the need for a service like codeplane.

[jpeterson]

I imagine part of the use case is "quickly and easily getting back to a snippet within one of those old files", in which case the tarball and archive method won't really work.

[bruceboughton]

He's talking about tarring a local git repository. You can still use all the git history stuff, you're just backing up using tar rather than via git push/pull.

[rawsyntax]

I keep a local copy of old git repos on my harddrive. I backup my harddrive religiously. Provided you don't have giant repos, this works well

[runjake]

I prefer to have my saved code at the ready, easily-browsable preferably via a browser-based colorized, tagged hubaju. I can appreciate this use case.

[scorpion032]

Sounds to me like a service that "archives" your github projects on to S3 and "activates it" back to github would be of particular interest.