Question

Question: How do I push my local commits to my development server if that worktree is not bare?

My Situation:

1. I set up git on my development server so that when I push local changes, they are added to a detached working tree (as described here and much like this post).
2. I then experienced problems running git on the dev server (eg, git status) because git could not find the working tree.
3. I asked around SO and got the tip off that I needed to set bare = false in my config file and specify the worktree. Sweet.

But now when I try to push my commits to the dev server I get this error:

$ git push origin master
[e-mail]'s password:
Counting objects: 26, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (18/18), done.
Writing objects: 100% (18/18), 2.56 KiB, done.
Total 18 (delta 8), reused 0 (delta 0)

remote: error: refusing to update checked out branch: refs/heads/master
remote: error: By default, updating the current branch in a non-bare repository
remote: error: is denied, because it will make the index and work tree inconsistent
remote: error: with what you pushed, and will require 'git reset --hard' to match
remote: error: the work tree to HEAD.
remote: error:
remote: error: You can set 'receive.denyCurrentBranch' configuration variable to
remote: error: 'ignore' or 'warn' in the remote repository to allow pushing into
remote: error: its current branch; however, this is not recommended unless you
remote: error: arranged to update its work tree to match what you pushed in some
remote: error: other way.
remote: error:
remote: error: To squelch this message and still keep the default behaviour, set
remote: error: 'receive.denyCurrentBranch' configuration variable to 'refuse'.

To ssh://[e-mail]/xxx/xxx/xxxxxx.git
 ! [remote rejected] master -> master (branch is currently checked out)
error: failed to push some refs to 'ssh://[e-mail]/xxx/xxx/xxxxxx.git'

I see that this other user had the same problem. Unfortunately, the solution that worked for him was setting bare = true in his config, which would recreate the problem I was having in step 3 above.

The error message says

You can set ‘receive.denyCurrentBranch’ configuration variable to
remote: error: ‘ignore’ or ‘warn’

In my case, is it ok for me to do this? It sounds good to me, but I’m not familiar enough with git yet to recognize a bad idea when it comes around…

EDIT

Just to be clear, I have already added a post-receive hook and it’s working smoothly. The problem is that I seem to have to choose between bare=true (and being able to push to the dev server) and bare=false (and being able to run git commands on the dev server).

Answer 1

I’ve worked out a solution that is acceptable, but not quite ideal. Basically, I am just circumventing the problem by editing my config file when I need to push dev changes to my live server.

Config file which allows developers to push local changes to dev:

[core]
        repositoryformatversion = 0
        filemode = true
        bare = true

Config file when pushing dev changes to live:

[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        worktree = /var/www/example.com/httpd/

Pros

1. Works
2. Once I have changed the config file to push to live, the repo is ‘locked’ and other developers cannot push changes
3. Not a huge problem since I have to login to dev to handle database migration anyway

Cons: basically just that it’s work that I’m sure could be automated, if I knew how to do it correctly.

Note: I like @vonC’s suggestion of setting up the post-recieve hook to conditionally also push to the live server. Making the changes to the post-recieve hook is simple enough, but I do not understand what the trigger would be that the hook would respond to. I’d love to hear suggestions though : )