Remove this.

So the method you're doing here will work, but it does modify existing files (which we probably do not want to do).
Instead how about the following approach:

Make a new directory .git/hooks/{SCRIPT_TYPE}.d, where SCRIPT_TYPE is e.g., post-commit
If .git/hooks/{SCRIPT_TYPE} exists, move it to .git/hooks/{SCRIPT_TYPE}.d/00-original
Install our hook script as .git/hooks/{SCRIPT_TYPE}.d/99-rbgateway:
Create a new .git/hooks/{SCRIPT_TYPE} with the following template (see here):


#!/bin/sh

for HOOK in { .ScriptType }.d/*; do
    if [ -x "${HOOK}" ]; then
        /bin/sh -c $HOOK
    fi
done


This allows us to install our own hooks without modifying the hooks already installed, as well as allows the maintainers to add multiple hooks.
Also, since git by default has a hooks directory full of examples that are not marked +x, we can safely copy them into the hooks/{SCRIPT_TYPE}.d/ directory. In your original implementation, if the original git hook is made by git and non-executable, the code won't run.
Additionally we can chmod +x .git/hooks/{SCRIPT_TYPE}/99-rbgateway with os.Chmod.

Git hooks should be named post-commit, etc. without the .sh.

Should the last character (',') be truncated from the error message?

Are their constants/enums for HTTP methods somewhere?

Do assignments in Go not return tha value? i.e. could this be (err = watcher.Add(config.DefaultConfigPath)) != nil?

Interesting way to do error handling. Certainly cleaner than try/catch

Is there a way to not hardcode this here? Perhaps move it somewhere else in (or out of) the code?

Can you rewrite the summary in the imperative mood, e.g.:

// Register a wehook.

This should return 201 Created.

Likewise here.

Unnecessary, as thats the default behaviour of the HTTP standard.

Care to put the body param before the t?

} on next line.

Is that a single space or is it a tab character? IMO we should use two (my preference) or four space indent or tab.

Missing a period.

I think we should either manage webhooks exclusively via the API or exclusively via config.json. If the former, we should store them in a separate file so that adding a webhook does not cause cause the server to restart (as fs notifier currently will notice we wrote the file and).
Or we manage them excusively via config.json, in which case a restart is to be expected.

We really just need the ID. Everything else we can get if we need it.

Comments should be in proper sentences beginning with capitals and ending with periods.
Same goes for all comments throughout.

Can you write your doc-comments in the imperative mood, e.g.
"Return whether or not the webhook has valid fields."

remove this line.

Can be one statement

Ideally we can have this as a template string inside go and then replace (1) the path to rbgateway and (2) the reponame ourselves when we install it. It also would mean we don't need to include this text file when distributing rb-gateway

So this isn't strictly correct if you're not pushing to master.
You will want to read from standard input the data about the changes received. (This links to the pre-receive hook but they get the same input).
e.g.

read OLD NEW REF_NAME

echo "$OLD $NEW $REF_NAME" | $rbgatewaypath -send-webhook=post-commit -repository=$reponame


where REF_NAME is the name of the ref being updated (e.g., master) and OLD and NEW are the new revisions.

This should live in the hooks package

Can we move the code thats executed when triggeredByHookscript is true into another function?
That way we can do:

if triggeredByHookscript {
    return executeHook(...)
}
// server stuff here

Testing code?

You should use "${HOOK}" here in case it contains a space.

As an FYI, you can use touch filename to modify the mtime (last modified time) of filename or create filename if it doesnt exist.

No blank line here.

No comments, just questions. This is my first encounter with Go, but your code is very readable!

I've never read or worked with Go before, but I think it's pretty cool how readable some of it is. Would this syntax allow you to chain multiple methods?

Another question, what does the syntax for the parameter t *testing.T mean?

I'm not familiar with go lang at all really so I'm just wondering, how come sometimes you use "if err == " and other times it's "if err = "?