Autarchy of the Private Cave

Github is awesome and still improving, but sometimes I’d prefer to have some of my repositories hidden from the eyes of the public – not so much because of the code value (though that is also important sometimes), but rather because those repositories are all “work in progress” or “short-lived” and may have so much junk in them at some moments in time that it would simply be too embarrassing to publish this untidiness.

Previously, I’ve used gitosis to setup git repository hosting on my server. I’m still using it for long-living projects, but I’m now lazy enough to dislike the steps needed to setup a new repo (and I’m creating more and more new repos, some of which are likely to die very young). Some kind of GUI would help, but gitweb seems not that useful to me (here’s how to make it work with gitosis, and another recipe, or maybe just try gitosis-web or gitosis-web-admin).

Another downside is that gitosis is no longer actively maintained and was even removed from ubuntu repositories. Suggested course of action for gitosis users is to migrate to gitolite. However, basic design of gitolite is the same, so personally (looking for something easier to use) I see only minor gains in this migration (which I’ll have to perform anyway sooner or later).

Another interesting self-hosted option is girocco. Too bad I have absolutely no experience with http://repo.or.cz/, so it’s hard to tell if girocco is convenient to use or not… Comments are welcome.

Using dropbox for git repositories (also here) seems a nice and fairly easy option, with only a few downsides: it’ll eat your dropbox space (which is still much more than you get from free git hosters), and it isn’t that easy in a multi-user environment. Also, you will have to setup dropbox on your headless servers where you may want to run your code, which isn’t exactly what I’d want to do. Same arguments apply to git on google drive.

An alternative to various self-hosted systems would be to use an existing system with free private projects. Git wiki has a list of hosts to start with.

Here’s a brief summary of the options I’ve found relatively attractive (see below for my experience with 3 of the listed services). (See also this recent comparison.)

Initially, I found GIT Enterprise and Assembla to be the most attractive options to try. After trying both, I found Assembla faster and generally more attractive to work with. It wasn’t immediately obvious how to create more than one source repository, but after figuring that out everything is smooth.

However, after trying BitBucket, I had immediately switched all my assembla repositories to it BitBucket is just like github, but with free private repositories. It also has an issues tracker and a wiki. It even allows small teams to work on private repositories!

I assume that you already have your gitosis-admin repository working (this is described elsewhere).

1. cd gitosis-admin && git pull – enter your gitosis administrative repository and ensure it is up-to-date
2. $EDITOR gitosis.conf
3. add [group newreponame] section (newreponame is the name of your new repository being added); add yourself with members = yourlogin@yourhost line; also add writable = newreponame line:
   

   [group newreponame]
   members = yourlogin@yourhost
   writable = newreponame

4. based on my assumption of a correctly setup gitosis-admin repository, you should already have the appropriate public key in the keydir directory, but if not – copy your user’s ssh public key to keydir in the form of yourlogin@yourhostname.pub, then do git add keydir/yourlogin@yourhostname.pub
5. git commit -am ‘new repository: newreponame’; git push;
6. now that you have the new repo permissions configured, let’s actually create it. Navigate to the directory holding the files of your project (e.g. cd ~/newreponame), and do git init; git add . – this initializes empty git repository, and then adds all the files to it. If you have no files – you can skip the ‘git add .’ command, as it will do nothing for you.
7. git commit -m ‘initial commit’. If you had no files added to the commit, git will complain that it cannot create an empty commit. In this case use the command git commit ––allow-empty -m ‘initial commit’
8. git remote add origin ssh://gitosis@yourGitosisServerName/newreponame.git
9. git push ––all
10. final thing: git config ––add branch.master.remote origin && git config ––add branch.master.merge refs/heads/master; alternatively, cd .git && $EDITOR config, and then add these lines:
    

    [branch "master"]
    remote = origin
    merge = refs/heads/master

    Without these lines, you won’t be able to git pull.

Once I accidentally added circa 300 MiB of archive files to one of my git repositories (which was as small as 5 MiB). I removed those files as soon as I noticed them, but the .git directory still preserved commits with those files, and still occupied over 300 MiB.

I have found the solution at stackoverflow (see also this question).

This method worked for me, but I couldn’t push my rebased repository to the gitosis. I would need to re-init the gitosis repository from my rebased, but I’m not yet prepared to do that.

There is also a slightly different method (which relies on a temporary tag instead of a temporary branch), documented in Git online manual pages; I prefer the temporary branch method.

Below is a full copy-paste of the winning answer by Charles Bailey:

# create and check out a temporary branch at the location of the bad merge
git checkout -b tmpfix

# remove the incorrectly added file
git rm somefile.orig

# commit the amended merge
git commit –amend

# go back to the master branch
git checkout master

# replant the master branch onto the corrected merge
git rebase tmpfix

# delete the temporary branch
git branch -d tmpfix

Also, in my case this thread at stackoverflow was highly useful. I start enjoying the concise and compact style of Charles Bailey :
Read the rest of this entry »

One of my projects – COTRASIF – has grown complex enough to necessitate the use of version control system (VCS).

The most frequently mentioned is definitely SVN (SubVersion).

However, with a characteristic scrupulosity, I decided to run my own comparison of the available tools. I had a look at Darcs, Mercurial, SVN, and Git. Of these, only SVN is not a distributed VCS (but there is SVN addon which adds distributed features to SVN). Unfortunately, I didn’t take any notes during comparison, so there will be no details on how the choice narrowed down to Mercurial vs Git. These dVCSs are quite similar, with the following major differences: Mercurial is better documented and (much?) easier to use than Git; Git is more feature-rich, and Git currently has more add-on modules. Here the differences almost end. I decided that learning curves never were an obstacle, so Git is currently my first distributed VCS of choice (please note: I’ve never before used any version-control systems).

After choosing Git, I had to install Git central repository on a server. (Yes, Git is distributed, but central repository on the always-on server is a convenience worth the trouble; and again, this adds yet another backup copy.)

This is a collection of resources I found useful when setting up my Git repository:

1. Hosting Git repositories, easy and secure way (note: do not create the user manually, installation of gitosis package does that for you automagically).
2. Setting up Git repository on Dreamhost.
3. gitosis: how to add new repository

Some more resources on how to use Git:

1. Git user manual
2. Git guide
3. Git recipes (branching and merging in examples)
4. everyday Git with 20 commands
5. version control with git – tutorial

Update: Git is simple enough to get started in minutes. So far I had only used clone/push/pull/commit/gc commands, but I’m familiar with tag/branch/checkout commands. The drawback of insufficient documentation (as mentioned above) isn’t really a problem now. I’m not using any GUIs for git (as sometimes I’m working on a remote server via ssh), but of the three locally tried GUIs I liked gitk the most; both git-gui and qgit feel less convenient than gitk, but are approximately equal. I wish I had some SVN/Mercurial/Darcs experience to be able to recommend Git – but I don’t have that