6

Possible Duplicate:
git push error '[remote rejected] master -> master (branch is currently checked out)'

Im trying to push my repository to the "origin", but I get this error when i run "git push"

Counting objects: 5, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (4/4), 485 bytes, done.
Total 4 (delta 0), 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
Auto packing the repository for optimum performance.
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'.
/usr/local/git/libexec/git-core/git-sh-setup: Zeile 235: uname: Kommando nicht gefunden.
warning: There are too many unreachable loose objects; run 'git prune' to remove them.
To ssh://XXXX@XXXXXX.typo3server.info/html/typo3
 ! [remote rejected] master -> master (branch is currently checked out)
error: failed to push some refs to 'ssh://XXXXXXX@XXXXXX.typo3server.info/html/typo3'

What is wrong?

Community
  • 1
  • 1
Enrique Moreno Tent
  • 24,127
  • 34
  • 104
  • 189
  • 1
    What isn't clear from the message? You're pushing to a non-bare repo (there's a checkout on the other end), and there's no special configuration to let the other end automatically update its working copy. By default, git won't let you do that. – Asherah Jul 09 '12 at 12:56
  • It's one without a working tree. This might help http://sitaramc.github.com/concepts/bare.html – Wivlaro Jul 09 '12 at 13:00
  • But my "origin" is actually the webserver where the website is being shown. Making it a bare repo wouldnt render the live server unviewable? – Enrique Moreno Tent Jul 09 '12 at 13:01
  • Yes, so then you need to do some special configuration to let the other end update its working copy. Note it talking about `receive.denyCurrentBranch`. I'll post an answer, hold on. – Asherah Jul 09 '12 at 13:16

1 Answers1

18

You're trying to push to a non-bare repo (i.e. a repo with a working tree, just like your local clone), but there's nothing done at the other end to account for this specially.

You look like you're trying to let a git push deploy your site. Here's how to do that:

  1. Ignore the error message git is giving you now by running this in the repo on your server:

    git config receive.denyCurrentBranch ignore

    This tells git "I'll work it out, trust me."

    Now if you push, it'll update the repo, but the index and working copy will be left untouched. This means it'll always look like you've staged changes to revert everything you've pushed.

    We need a way to update the index and working copy whenever a push occurs. Sounds like it's time to …

  2. Set up a post-receive hook. Add the file .git/hooks/post-receive on the server's repository:

    #!/bin/bash

# Drop the env var given to post-receive by default, as it'll mess up our
# attempts to use git "normally."
export -n GIT_DIR

# Move back to the base of the working tree.
cd ..

# *Drop all changes* to index and working tree.
git reset --hard

    Note that this assumes you only ever want your tracked changes live—anything you change directly on the live site will disappear when you next push (excepting untracked files, but you shouldn't have those either).

I add a git status at the end so I can see what the lay of the land is after a push (as it gets transmitted back to the client)—this is particularly so I can catch untracked files and either add them to .gitignore, or track them.

Don't forget to mark post-receive as executable!

Aside: why shouldn't you have untracked files?

  1. Ability to rollback: this is for deploying a live site. If you want to be able to really rollback a failed deployment, then you need everything that went together to make that deployment.

    That definitely includes the core CMS. Right now, it's only on the server, and it's untracked, so you've got no hope of detecting an error.

  2. Ability to redeploy: if your server's harddrive goes down, you get to unzip the core CMS, layer your git repo over it again, and hope it works.

  3. Ability to notice what's accidentally untracked: if you have several dozen untracked files, and they're all "meant" to be untracked, it's easy for a new file to sneak in and get lost in the noise.

    If your git status is clean by default, then you'll notice unexpected untracked files as soon as they pop up.

Asherah
  • 18,948
  • 5
  • 53
  • 72
  • Why do you say I shouldnt have untracked files? Im using a CMS and im not tracking the CMS core files, because its useless and they are huge. – Enrique Moreno Tent Jul 09 '12 at 13:29
  • @Dbugger: I've added an aside to deal with that question. Besides, it's not a big deal; they'll get stored and packed away in an object and left there. – Asherah Jul 09 '12 at 13:48