tags:

views:

82

answers:

2

I'm using a box as a shared repo, and my team connects to it via ssh.

What I do is:

  1. Create an empty git repository on the central machine git init

  2. Then from each workstation do something like git clone ssh://user@central-box/Users/user/Projects/my-project/.git/

This works nice, but git keeps yelling at me every time I make a push something like this:

alt text

Is there a better way of sharing a repo over ssh.

IMPORTANT: I'm well aware of the existence of gitosis and tools like that, I do not want anything fancy. Just sharing a .git repo over ssh.

Thanks

+2  A: 

On the host machine you should do

git init --bare

Because you don't need the actual files, just the repo.

If the warning message is on a FIRST push to a repo, and no one has touched it, do a

git push -f

Otherwise, this error means your branch scheme isn't correct. You should NOT be editing the branch origin/branchname. You want your own local branch called branchname, then when you are ready to check in your code you do

git commit
git pull
git push

And you will push from your local branchname to origin/branchname.

Edit

I would like to see the output of this command in your local repo:

git branch

You should not see the word origin or your server name anywhere in the output

bwawok
Nope, `git branch` on my machine (not the "bare" repo) yields *master
Pablo Fernandez
Is there a way to "fix" the central box now that I've already created the repo without passing --bare as an argument? :S
Pablo Fernandez
Your local repo should have everything the remote repo does. Pull it down to make sure, then just blow away the repo, make a bare one, and push everything back up.
bwawok
@bwawok it work perfectly with `--bare` the only change I need to make was renaming origin to the path without the `.git` subfolder. Thanks!
Pablo Fernandez
A: 

In addition to bwawok's solution, you'll need to watch out for permission issues. By default, when git creates files on a user's behalf, their permissions are sourced from the user's umask and their group is set to the user's default group. For common umasks and default groups, this will break a shared repo, since such files will be unmodifiable by other users.

Fortunately, git can be configured to do the right thing in this situation: Take a look at the --shared option to git init (or the core.sharedRepository setting). The simplest option is probably --shared=group, which grants write access to all users in the "git" group.

dhaffey