Autarchy of the Private Cave

Tiny bits of bioinformatics, [web-]programming etc

    • Archives

    • Recent comments

    Free private git repository hosting

    29th August 2012

    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.)

    Providers \ Features
    Repositories
    Users
    Space
    Paid plans?
    BitBucketUnlimited5Unlimited+
    AssemblaUnlimitedUnlimited1 GB+
    GIT EnterpriseUnlimited101 GB+
    ProjectLocker120.2 GB+

    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!

    Share

    Posted in *nix, Links, Software | 1 Comment »

    How to truncate git history (sample script included)

    28th March 2011

    Under a few assumptions (most importantly – you do not have any non-merged branches,), it is very easy to throw away git repository commits older than an arbitrarily-chosen commit.

    Here’s a sample script (call it e.g. git-truncate and put into your ~/bin or whichever location you have in PATH).


    #!/bin/bash
    git checkout --orphan temp $1
    git commit -m "Truncated history"
    git rebase --onto temp $1 master
    git branch -D temp
    # The following 2 commands are optional - they keep your git repo in good shape.
    git prune --progress # delete all the objects w/o references
    git gc --aggressive # aggressively collect garbage; may take a lot of time on large repos

    Invocation: cd to your repository, then git-truncate refspec, where refspec is either a commit’s SHA1 hash-id, or a tag.

    Expected result: a git repository starting with “Truncated history” initial commit, and continuing to the tip of the branch you were on when calling the script.

    If you truncate repositories often, then consider adding an optional 2nd argument (truncate-commit message) and also some safeguards against improper use – currently, even if refspec is wrong, the script will not abort after a failed checkout.

    Thanks for posting any improvements you may have.

    Source: Tekkub’s post on github discussions.
    See also: how to remove a single file from all of git’s commits.

    Share

    Posted in how-to, Notepad | 12 Comments »

    gitosis: how to add new repository

    20th February 2009

    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.

    Share

    Posted in *nix, how-to, Software | 16 Comments »

    Git: how to remove file and commit from history

    13th February 2009

    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 »

    Share

    Posted in how-to, Links, Programming | 2 Comments »

    Using GIT version control system

    25th December 2008

    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 :)

    Share

    Posted in *nix, Links, Software | No Comments »