What is this Git warning message when pushing changes to a remote repository?

Question

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'.    

Answer 1

With Git 2.3.0 (After February 2015)

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 (dscho):

receive-pack: add another option for receive.denyCurrentBranch

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:

updateInstead 

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.

With Git < 2.3.0 (Before February 2015)

The most common approach is to create a bare repository from the non-bare repository and have both the remote/local non-bare git repos point at the newly created bare repository.