Home/ Questions/Q 8198037
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-07T05:51:59+00:00

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

  • 0

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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0