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.

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 :

# detach head and move to D commit
git checkout

# move HEAD to A, but leave the index and working tree as for D
git reset –soft

# Redo the D commit re-using the commit message, but now on top of A
git commit -C

# Re-apply everything from the old D onwards onto this new place
git rebase –onto HEAD master

Note: this example is for a branch of commits R–A–B–C–D–E–HEAD, where commits B & C should be removed from commit history.

Another option is to use git rebase –interactive (for the same example):

git rebase -i HEAD~5

Unfortunately, rebasing on a public (pushed out) branch has no effect for other users of the current gitosis repository.

An alternative to re-initializing gitosis repository from rebased scratch could be switching to a different (rebased) branch, and deleting the outdated master branch; but I haven’t investigated if this works.

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