* "git push" into a repository with a working tree normally refuses
       to modify the branch that is checked out.  The command learned to
       optionally do an equivalent of "git reset --hard" only when there
       is no change to the working tree and the index instead, which would
       be useful to "deploy" by pushing into a repository.

Nice! This sounds like something that I expected Git to do since the first time I used it, which means that I ran straight into the unfriendly error messages that result from pushing to a checked-out repository.

Using hooks for simple deployments has always seemed clumsy compared to the thing that I originally imagined Git could do. I'm glad to hear that Git now supports this use case.

Wait, is this saying that `git push` can now change your local working tree, instead of changing the remote you are pushing to? That doesn't sound like what i'd expect, but I think maybe I'm misunderstanding what it does when?

Git push gained the ability to change the remote working directory - but only if that copy of the repo has been set up to allow it.

I didn't know there was such a thing as a 'remote working directory', so clearly I am confused!

There are a couple of scenarios I can think of to help it make more sense:

1) You're pushing to a remote server which has a checkout of the working copy as the live version of something, e.g. a webapp.

2) You're pushing to a co-workers repository to allow them to see updates (though probably a less likely scenario)

Yep, I've been using a post-receive hook alongside "receive.denyCurrentBranch ignore"

  read oldrev newrev ref
  branchname=${ref#refs/heads/}
  git --git-dir=. --work-tree=$PWD/.. checkout -f ${branchname}
  git --git-dir=. --work-tree=$PWD/.. reset --hard $newrev