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

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.