Autarchy of the Private Cave

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.
7. git commit -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.

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. Hosting Git on Dreamhost; in the light of GoDaddy now offering SSH access for shared hosting plans, instructions for Dreamhost get even more value.
4. 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

CodeCodex Wiki.

Found this one useful when looking for string conversion to uppercase – CodeCodex has it for 10 languages (alas, Ada isn’t among them – but it’s present in tiny pieces here and there, when searching for it at CodeCodex).