Re: [PATCH] commit: Add -f, --fixes <commit> option to add Fixes: line

From: Duy Nguyen <pclouds@gmail.com>
Date: Oct 31, 2013, 06:28 UTC
Message-ID: <CACsJy8DVSpmmDw-jGJoJK171u5UeJR7GKPuX7QAK4=7yYn6n8Q@mail.gmail.com>
In-Reply-To: <CALKQrge8T8R7roUUYyLcu_QnL1afeqTATOp+0n_OOsZZoJXF4Q@mail.gmail.com>

On Thu, Oct 31, 2013 at 1:12 AM, Johan Herland <johan@herland.net> wrote:

Show 17 quoted lines

> Yes, we do lack a good infrastructure for managing Git hooks from
> multiple sources. It makes people afraid to use them, because they
> might conflict with hooks from another source. There are (off the top
> of my head):
>
>  - "personal" hooks ("I want this behaviour in my repo(s)")
>  - "project" hooks ("In this project we follow these conventions")
>  - "system" hooks ("This host runs gitolite (or whatever) which needs
> these hooks...")
>  - "default" hooks (Some of the core Git code could have be
> implemented as hooks (e.g. "--signoff"), but is instead put into core
> Git)
>
> Maybe if we solved that problem, we could actually make use of hooks
> instead of adding "code" to our git configs (by which I mean config
> directives that are flexible enough to encode all kinds of semantics
> and behaviors that are probably better expressed in real code...).

OK how about, if $GIT_DIR/hooks/something is a directory, then the directory must contain a file named "index", listing all the hooks of type "something". All the hooks in "index" will be executed in the listing order. There could be directories inside .git/hooks/something to help categorize the scripts, so project hooks stay in "project" subdirectory and so on.

With this we could provide "git hook" command to manipulate hooks and test out the new combination of hooks. We could even select what scripts not to run for a particular run, say you don't want the s-o-b hook active when you commit this thing, you could run

  git commit --exclude-hooks=pre-commit-msg/s-o-b

You could exclude hooks by pattern as well

  git commit --exclude-hooks="pre-commit-msg/projects/*"

Or run an unsinstalled hook just one time

  git commit --include-hooks=/path/to/my/hook

Hooks like "Fixes" may need input from the user. The hook could bail out if the required input is not given. But it maybe a good idea for git to check and reject before running hooks, if the input is not specified (e.g. from command line). I guess those extra info has to be in .git/config and be added to .git/config by "git hook" command, unless we have some convention to express those without running the hook.

For old Git versions that does not support this scheme, as directories usually have u+x, the hook directory should be mistaken as an executable and rejected when executed (permission denied in my test), which gives user a good warning that this repo should not be used with this git version.

-- 
Duy