I managed to write the correct .htaccess in order to allow git-http-backend without changing apache main config file. The git-http-backend contains description only of a scenario where you have to change the apache config file.
This was tested on hostmonster, but supposed to work on others like bluehost or dreamhost etc.

First you have to make sure that at least git version 1.6.6 is installed on your system. You may build it yourself. We assume that is installed to

$HOME/system/usr/


Now create a script git-http-backend.sh in the directory

$HOME/public_html/website.com/git/


with the following content:


#!/bin/sh
#first we export the GIT_PROJECT_ROOT
export GIT_PROJECT_ROOT=$HOME/gitprojects/
#and run your git-http-backend
$HOME/system/usr/libexec/git-core/git-http-backend

#uncomment the following line if you want to see environment variable values
#echo $REMOTE_USER $QUERY_STRING $REQUEST_METHOD $PATH_INFO >> $HOME/logs/log

the .htaccess file should contain:

Options +ExecCgi
AuthName "Private Git Access"
AuthType Basic
#you need to add users and passwords to the .htpasswd file
#you have to add the same user and password on the client machine under ~/.netrc
AuthUserFile <<YOUR HOME DIR>>/public_html/website.com/git/.htpasswd
Require valid-user
RewriteEngine on
RewriteBase /git
SetHandler cgi-script
RewriteRule ^([a-zA-Z0-9._]*\.git/(HEAD|info/refs|objects/(info/[^/]+|[0-9a-f]{2}/[0-9a-f]{38}|pack/pack-[0-9a-f]{40}\.(pack|idx))|git-(upload|receive)-pack))$ /git/git-http-backend.sh/$1


note that:
1. <<YOUR HOME DIRE>> needs to be replaced by your home directory (or other folder you have access…)
2. the $HOME/public_html/website/git is the physical address of the website, and $HOME/gitprojects is the directory where you host the projects
3. you will be able now to clone your projects under:

4. do not forget to add a file git-daemon-export-ok in the *.git directory you want to “export”

5. make sure that both on your local computer and on your shared host you have at least git 1.6.6 with curl and expat

git clone http://website.com/git/myproject.git

Update:

the solution is there (here : ) : http://www.mobiphil.com/2010/03/git-on-shared-hosting-with-git-http-backend

Unfortunatelly the descriptions found on http://progit.org/2010/03/04/smart-http.html and http://ftp.sunet.se/pub/Linux/kernel.org/software/scm/git/docs/git-http-backend.html DO NOT work on a shared hosting. The apache configuration directives mentioned can be used only inside the global http.conf, but not on per directory .httaccess, where shared hosting users might have access. I will try to hack around to find a solution with rewrite, etc. that could be configured through .htaccess.

I more than welcome the git smart http transport extension. I was deeply disappointed that my new shared hosting provider does not support webdav, so I could not pull my software there for sharing. An fcgi version of the cgi would me more than welcome, as I am sure that most people will use this on shared hosting, like me.

I have git repositories in several places. Considering different forces I came to some personal conventions, that will, I hope help me to pull push from/to the correct place. I have for all the git repositories basically 4 categories of locals/remotes:

1. the working area. The working area can be on different machines, therefore I call these remotes as the machine name as well. It makes sense to have such remotes, as working on machine X, the Y will be a remote to X. So on each copy/mirror of the git repo, I will have a remote X, Y, Z…, where X,Y,Z… are the machine names I am working on. So far I am not sharing repos with other users on same machine. If that would be the case <machine>.<user> would probably make sense.

2. Git bare space. I call it simply “bare”. This is a remote for all other copies/mirrors that is somewhere on my local network. In my work-flow, I normally always pull/push here. I have some cron jobs, that do frequent pull push (if it is the case) with main repositories like github, or the projects origin.

3. Github and Gitorious.

4 Origin. I use this name for remote for projects that I do not keep a local copy/mirror bare repository. For these ones it really makes sense to think about the abstract remote pull/push.

Well the experience with umview was interesting, but too complicated . Working with GIT_WORK_TREE or core.worktree in .git/config, solves the problem, but you are not “inside” the directory.

***** old post follows ****

Under this name I will try to write a few articles about my design and experience in using git on top of clearcase in order to achive two things:

• make the enterprise happy by keeping the sources in a central repository
• make my work flow much easier by using the power of git and avoiding dead times when waiting for the slow clearcase to do operations like view setup, align with baseline, create branch, merge etc. The goal is to do all necessary development steps fast with git (including collaboration with other developers), and let the computer do the rest of required formalism against clearcase (checkout, “edit”, merge, etc)

At the enterprise where I would like to deploy this design, one of the first handicaps I faced is that the there is no place in the filesystem hierarchy before the clearcase vob, where I could place the .git folder, to map it over the cleracase views. One of the solutions came to my mind is to aske sysadmins to install the fuse module, but my request was refused for system security reasons.

Another alternative seemed to me was to run myself a virtual machine and mount there the vobs under a subfolder of a folder that contains .git. Running whatsoever virtual machine was not a choice do to my access limitations, so only UML could come in question. Uml would mean build a kernel, build a minimal filesystem with necessary tools, etc, etc.

Accidentally however I came across a simpler solution. And that is called virtual square umview. Virtual Square’s “main goal is to create an unified environment that allows virtual machines, systems and networks to communicate and interact”. Umview is a tool that is part of the project. It traps practically any system calls issued by any program that a user runs, and transform them as instructed. For example you can configure it to transform “read /mydiskspace/project.git/clearcase/vob1/module1/src/file1.c” into “read /clearcase/vob1/module1/src/file1.c”. That is to mount virtually “/mydiskspace/project.git/clearcase”  to “/clearcase” inside the virtual environment. Once having that in place you may create the mirroring .git repository in /mydiskspace/project.git. You will feed with source data from the virtually mounted /mydiskspace/project.git/clearcase/vob1/module1/src/file1.c.

How would you concretelly issue your commands? Here are they (see comments)

#>umview $SHELL #start a shell under the virtual environment

#>#you are now in the virtual environment but you have the “same” view

#>#until you start to “manipulate” it

#>um_add_service viewfs #load the module that handles virtual mounts

#>mount -t viewfs /clearcase/vob1/ /mydiskspace/project/git/clearcase

#>cd /mydiskspace/project.git

#>git init  #if this is the first git action

#>git add . #fill the repository with your files from the clearcase view

It is obvious that in the example above you are in the context of a view. You might be able to create wrapper commands around git, that will execute always in this “manipulated” environment view.

In following articles I will describe how I feed the git repo with history from clearcase. To start to work it is not strictly necessary to have the history. It is a nice convenience if you would want to access the history from git.

Note:

• It is mentioned on the umview website that the viewfs module is in early development phase, so it might be a bit buggy. If that does not work for you, try umfuse module
• The umview version that comes with Ubuntu Jaunty does not work well on my test machine, so I had to build one from the sources