I decided to move all my private repositories to my own server. When you do this, make sure that the server has continuous backups. Also, make sure you still have an offsite backup. Once you figure out what these things are worth, you may realize that you should probably just keep paying Github.
My poorman's offsite backup script involves zipping up the repository, encrypt it, and mail it to GMail. The task is scheduled daily and works pretty well.
How to set up your own private Git server on Linux
61–66 of 66 posts
Re: How to set up your own private Git server on Linux
#62Earlier quoted context omitted.
My poorman's offsite backup script involves zipping up the repository, encrypt it, and mail it to GMail. The task is scheduled daily and works pretty well.
I did this with my university project source code. The only difficulty is that Gmail does not allow executables even within a zip file. You have to work pretty hard to avoid getting them into your repo.
Re: How to set up your own private Git server on Linux
#63Earlier quoted context omitted.
it could also happen that github loses data and it's hard to valuate the exact likelihood of you accidentally deleting two repos or github losing a fileserver and its backup. Also, if github is down or your repo with them is corrupted, you have to go through their support. If your own server has a problem you can fix it instantly. I'm not convinced that reliability is the correct reason to go GitHub. Features: Yes. R…
Sure, Github can lose data. And you can lose data. But the advantage is that you and Github are much less correlated ; the odds that both of you will lose the data at the same time are fairly low. [1] Data safety is all about fighting correlation. You don't back up one partition to another on the same spindle, because when the drive dies the whole spindle is lost. Paranoid people back up to two different drives, two…
Re: How to set up your own private Git server on Linux
#64Earlier quoted context omitted.
I don't see any reason to run gitosis when there's gitolite, even for a single user. Either is definitely preferable to doing things manually, though.
I just went throught gitolite's readme, and I don't see any reason why a lone dev might want to use it, since it seems to be built for managing teams with access control needs. Doing it manually for me just means (on the server): mkdir project_name cd project_name git init --bare Hardy difficult. I already have ssh keys set up from long back, so that's all I have to do really. Then I just add the remote repository on…
Setting up gitolite is dead simple - setting up a git server manually manually might be 'simple' compared to other tasks, but it's still unnecessary work. Creating new repos is as simple as changing the config file and pushing it - no need to do anything on the server at all.
I see absolutely no reason TO do it manually, and that's the decider.
Re: How to set up your own private Git server on Linux
#65Earlier quoted context omitted.
My poorman's offsite backup script involves zipping up the repository, encrypt it, and mail it to GMail. The task is scheduled daily and works pretty well.
I did this with my university project source code. The only difficulty is that Gmail does not allow executables even within a zip file. You have to work pretty hard to avoid getting them into your repo.
mv $ZIP_FILE_NAME $ZIP_FILE_NAME.txtRe: How to set up your own private Git server on Linux
#66Earlier quoted context omitted.
This is not an idempotent operation, and I would not recommend this for anything besides a one-off event.
Interesting, I hadn't thought about it since, for my usage, setting up keys is pretty much always a one-off event (and pretty rare on top of that). What are the consequences of dropping your key into authorized_keys files multiple times? Tried it out on a Debian box, and didn't see any issues other than the obvious clutter.
But it's a bad habit to get into. Or better yet, it's better to think in idempotent operations when doing systems work.