What is this Git warning message when pushing changes to a remote repository?
The description is a bit terse. I simply added a file on my local master branch and pushed it back to a remote repo. Any idea why this is coming up?
warning: updating the current branch warning: Updating the currently checked out branch may cause confusion, warning: as the index and work tree do not reflect changes that are in HEAD. warning: As a result, you may see the changes you just pushed into it warning: reverted when you run 'git diff' over there, and you may want warning: to run 'git reset --hard' before starting to work to recover. warning: warning: You can set 'receive.denyCurrentBranch' configuration variable to warning: 'refuse' in the remote repository to forbid pushing into its warning: current branch. warning: To allow pushing into the current branch, you can set it to 'ignore'; warning: but this is not recommended unless you arranged to update its work warning: tree to match what you pushed in some other way. warning: warning: To squelch this message, you can set it to 'warn'. warning: warning: Note that the default will change in a future version of git warning: to refuse updating the current branch unless you have the warning: configuration variable set to either 'ignore' or 'warn'.
- Can I have a workspace that is both a git workspace and a svn workspace?
- hiding part of a git repo from untrusted users
- Can I safely edit a renamed file in perforce
- How to tell git that my local directory is a specific directory in the remote tree
- Tips for merging large changes between branches
- Understanding Git Graphs
3 Solutions collect form web for “What is this Git warning message when pushing changes to a remote repository?”
Actually, it means pretty much exactly what it says: somebody is working in the repository that you are pushing to, and that somebody has currently checked out the exact same branch that you are pushing to.
This is very confusing, because now he thinks that he has checked out the latest version of the branch, when, in fact, you have just updated the branch to a newer version. So, when he now runs
git commit, his commit will essentially revert all the commits that you just pushed. And when he runs
git diff he will see the opposite of everything you just pushed, even though he maybe hasn’t even changed anything.
For that reason, it is generally considered bad practice to push to a non-bare repository; you should only ever push to bare repositories, i.e. repositories that do not have an attached working copy. At the very least you should make sure that you do not push to the currently checked-out branch, but generally you shouldn’t just shove your code into someone else’s repository, you should ask them to pull from you instead.
In some special cases, like when you are serving a website from a Git repository and you want to update the website by pushing to it, it actually makes sense to push to the currently checked-out branch, but in that case you must make sure that you have a hook installed that actually updates the checked-out working copy, otherwise your website will never be updated.
If nobody is working in that remote non-bare repo, then it should be possible to push to a checked out branch.
But to be more secure in that operation, you now can (with Git 2.3.0, February 2015), do in that remote repo:
git config receive.denyCurrentBranch updateInstead
It is more secure than config
receive.denyCurrentBranch=ignore: it will allow the push only if you are not overriding modification in progress.
See commit 1404bcb by Johannes Schindelin (
receive-pack: add another option for
When synchronizing between working directories, it can be handy to update the current branch via ‘
push‘ rather than ‘
pull‘, e.g. when pushing a fix from inside a VM, or when pushing a fix made on a user’s machine (where the developer is not at liberty to install an ssh daemon let alone know the user’s password).
The common workaround – pushing into a temporary branch and then merging on the other machine – is no longer necessary with this patch.
The new option is:
Update the working tree accordingly, but refuse to do so if there are any uncommitted changes.
The commit 4d7a5ce adds more tests, and mentions:
The previous one tests only the case where a path to be updated by the push-to-deploy has an incompatible change in the target’s working tree that has already been added to the index, but the feature itself wants to require the working tree to be a lot cleaner than what is tested.
Add a handful more tests to protect the feature from future changes that mistakenly (from the viewpoint of the inventor of the feature) loosens the cleanliness requirement, namely:
- A change only to the working tree but not to the index is still a change to be protected;
- An untracked file in the working tree that would be overwritten by a push-to-deploy needs to be protected;
- A change that happens to make a file identical to what is being pushed is still a change to be protected (i.e. the feature’s cleanliness requirement is more strict than that of checkout).
Also, test that a stat-only change to the working tree is not a reason to reject a push-to-deploy.
This is the same problem as This question, the solution is to use
git init --bare or
git clone --bare.