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

[Duy Nguyen <pclouds@gmail.com>]

On Thu, Oct 31, 2013 at 1:12 AM, Johan Herland <johan@herland.net> wrote:
> 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