Hello, I’m having some issues with using server-side hooks when pushing to a non-bare repository. In my git config, I have `receive.denyCurrentBranch` set to `updateInstead`, which behaves as expected, and updates the current working tree when the current branch is pushed to. However, attempting to process those changes with pre-receive and post-receive hooks results in some unexpected behavior regarding the current working directory of the scripts and using git commands. I’ve tested these issues using both git 2.11 and 2.12 on various systems (macOS and CentOS), and get the same behavior each time. Essentially, my problem boils down to two things: 1. When using a non-bare repository, I would expect the the working directory of the hook to be the root directory of the working tree, as this mirrors the behavior of “client”-side hooks like pre-commit. Instead, the working directory is set to the .git directory. That in and of itself is not a huge deal, but it leads into #2: 2. While running the hooks, git treats the repository as being bare, regardless of whether it actually is. For instance, changing the working directory of the scripts to the actual root of the working tree and attempting to run any git commands (for instance, `git rev-parse --abbrev-ref HEAD` to get the current branch name) results in "fatal: Not a git repository: ‘.’” being returned to the client-side `git push` command. I’ve found a workaround to this, which is to explicitly set the “GIT_DIR” to the .git directory, and make sure that is passed to any external scripts as well. However, this is very unintuitive behavior, as the working tree is still there and either unmodified or done being updated, depending on which hook is being called. At the very least, this behavior should be in the documentation somewhere so that users can write their hooks accordingly. TL;DR: it seems that server-side hooks don’t account for the repository being non-bare, which is no longer a valid assumption with the `receive.denyCurrentBranch=updateInstead` configuration value introduced in 2.3.0. Thanks, and I’d be happy to provide any other information that anyone needs to take a look at this. Mike Lewis