Git - post-receive hook not working on remote windows server

Question

I\'m trying to get a git post-receive hook working on Windows.

I\'m using Git 1.7.9 (Msysgit) and have a repo locally and a bare repo on a remote server. I can fetch, co

Answer 1

When using msysgit on the server and pushing via a file share hooks work without problem now. Maybe this was fixed in mysysgit since the answer was written. I didn't look into it.

I also noticed that the original question stated git dot aspx and Bonobo were being used which use GitSharp.dll. This would mean the application is not shelling out to the git.exe and hooks would not be handled the same way.

For example, the GitSharp.dll used in git dot aspx has it's own hook post-receive hook implementation which could be performed in C#:

public void Receive(Stream inputStream, Stream outputStream) 
{
    using (var repository = GetRepository()) 
    {
        var pack = new ReceivePack(repository);
        pack.setBiDirectionalPipe(false);

        //setup post receive hook here
        pack.setPostReceiveHook(new PostRecieveHook());

        pack.receive(inputStream, outputStream, outputStream);
     }
}


public class PostRecieveHook : IPostReceiveHook 
{
    public void OnPostReceive(ReceivePack rp, ICollection<ReceiveCommand> commands) 
    {
        //Do PostRecieve Hook Work Here
    }
}

I hope to help others with confusion between libraries that are implementations of Git and applications that call out to the actual git.exe.

Answer 2

You are going to have to patch git to make this work. The checks in builtin/receive-pack.c are for access(path, X_OK). In msysgit this diverts to mingw_access which throws away the X_OK bit as it is simple not supported on Windows.

On windows, we have no flag to specify a file is executable. Systems often do some emulation of this. For instance, tcl will look for any extension in the PATHEXT environment variable to decide that a file is executable. We can't do that here as the hook names are hardcoded without any extensions.

Instead, I suggest changing the access test to just check the file exists and then call execv on the path. The mingw version of this (in compat/mingw.c) looks for script files and will read the shbang line and launch an appropriate interpreter (sh, perl etc). So modifying builtin/receive-pack.c:run_update_hook should let this work for you. Currently the hook running uses start_command and I think that should call down to execv for you.

In short, change the access test and it will probably work.