Hooks support

[petrzpav]

For example Node packages have version in package.json. You may want to configure some command or hook to run when OMGF increments version.

[jnv]

See hooks and filters for AVH gitflow: https://github.com/petervanderdoes/gitflow-avh/wiki/Reference:-Hooks-and-Filters

[jnv]

Also see https://github.com/petervanderdoes/git-flow-hooks

[petrzpav]

I just start with hooks implementation (based on PR #79)

[petrzpav]

@jnv @jiripavelka @alkuna Hooks proposal:

Location: .git/hooks/

Name [prefix]-omgf-[keyword]-[suffix]:

• Prefix: {pre,post} -- before and after action
• Keyword: {feature,hotfix,release} -- optional
• Suffix: {create,merge,changelog,version,conflict,delete,request}

Suffixes:

• create: create branch
• merge: merge branch
• changelog: update changelog
• version: increment version -- makes sense only for hotfix and release keywords
• conflict: resolve conflict by merge destination branch to current branch
• delete: delete branch
• request: get pull request url

Example of hook name: post-omgf-release-version

---

Edit: add request suffix Edit2: keyword is optional

[alkuna]

I'd like to make two suggestions:

1. extend the location to

• ~/.git_hooks/ for user hooks,
• ./git_hooks/ or .git_hooks in a project directory for project hooks, and
• directory(ies) defined in hooks.global configuration option for global hooks

like in the git-hooks project (https://github.com/icefox/git-hooks).

2. run custom shell scripts placed in directories with proposed names, for example

• a global script ~/.git_hooks/pre-omgf-[hotfix|release]-version/autoreconf.sh for updating version number in any autoconf/automake project,
• a project script ./git_hooks/pre-omgf-[hotfix|release]-version/dch-v.sh for updating version number in debian/changelog file, or
• ./git_hooks/pre-omgf-[hotfix|release]-merge/dch-r.sh to finalize version number in debian/changelog file before hotfix or release is merged.

[jnv]

I recommend keeping it simple and sticking with plain Git conventions, anything else can be enforced or supported by respective hooks management software. Users can build their own abstractions upon that.

Starting with Git 2.9 there is core.hooksPath config variable, which is automatically propagated. All you need to do is run git rev-parse --git-path hooks/$hook_name which gives you a full path to the hook file (though you need to check whether it really exists). (sources: 1, 2)

[jnv]

@petrzpav BTW, if you decide to build upon the --git-path feature, it'd be a breaking change since it requires newer Git version.