tommarshall / git-good-commit Goto Github PK

The project should have a Changelog, ref: http://keepachangelog.com

Validation should ignore trailing spaces, as git strips these from the commit message.

This is an issue for all of the length related rules:

• Separate subject from body with a blank line
• Limit the subject line to 50 characters
• Wrap the body at 72 characters

I am constantly having an issue committing with messages that do start with imperative but contain non imperative ones along the message. For instance writing something like:

• Fix a merge issue causing an error in login
• Change the order of some fixes
• Add code that removes the known issue

will trigger rule number 5 and give an error message. Shouldn't the imperative rule only match the first word?

Git config allows users to specify an editor:

By default, Git uses whatever you’ve set as your default text editor ($VISUAL or $EDITOR) or else falls back to the vi editor to create and edit your commit and tag messages. To change that default to something else, you can use the core.editor setting.

Currently the hook simply uses $EDITOR. It should instead favour core.editor and mirror the fallback approach of Git itself, ref:

https://github.com/git/git/blob/v2.11.0/editor.c#L10-L30

The e (edit commit message) option is not working in v0.6.0.

Selecting e should re-open the commit in the user's editor again. This is not happening. Instead it simply causes the hook to prompt the user for input again.

git-commit uses fixup! and squash! prefixes on the subject line for the --fixup <commit> and --squash <commit> arguments.

git-good-commit should ignore the fixup! and squash! prefixes when validating:

• Limit the subject line to 50 characters
• Capitalize the subject line

Support for semantic commits seems to be easy to implement. See https://seesparkbox.com/foundry/semantic_commit_messages

Sem-Ver is a way to add meta-data information about commit types that is growing more and more popularity.

A project using adopting Sem-Ver in comments, would be able to:

• auto-generate next version number
• auto-generate meaningful changelists

Mainly this is based on the concept that each commit should fix in one of these categories:

I was not able to find an official specification regarding recognized SemVer keywords (symbols) but so far this list seems to be supported by all implementations I found so far:

• feature (or new feature)
• api-break -- suggested use of sem-ver: .*break.* regexp
• deprecation
• bugfix -- seems to be default

Please note sem-ver seems to allow multiple keywords separated by commands, which means that the verification should not enforce a specify syntax: it should raise an error only if it failed to match any known strings.

Few resources:

• http://docs.openstack.org/developer/pbr/
• https://specs.openstack.org/openstack/oslo-specs/specs/juno/pbr-semver.html
• http://autosemver.readthedocs.io/en/latest/usage.html

It think it would be much better to use ~/.config/git location instead of creating a new folder inside the user home directory, even if it is a hidden one.

That location is already prefered by git ignored, see https://git-scm.com/docs/gitignore

Hi,

I try to use this hook but I have a couple of questions :

• Best Practice recommande to not use -m option for commit, but how to check if message conform to the rule when i use $ git commit ?

• I use a custom editor who is defined in .gitconfig but when i want to edit commit message I have the following error : ./git/githooks/commit-msg: ligne 251: .git/COMMIT_EDITMSG: Permission denied

Can you help me ? Thx.

The recommended installation method is to download the script directly. This felt like the simplest approach given that you only need the single script, however git init will not overwrite an existing hook, which makes updating less trivial than it should be.

The README should include a clear and easy path for updating.

When using numbers and special characters in the first word, git-good-commit is not able to recognise the capital letter. Using git-good-commit v0.6.1 and git v2.19.1.

I discovered that current version of the hook blocks some git (GUI) clients because it prompts for user input.

The current behaviour for the hook is to avoid any interactions on non-tty consoles.

Add popular URL Schemes in URL_REGEX.
e.g.

ws, wss, git, ssh, data, irc, dat

It seems that is not possible to use git-good-commit alongside git-review (gerrit) because both are installing the same hook: commit-msg.

We need to find a working solution for this so we can use both and eventually with other hooks.

I already made a CR for gerrit itself for adding this kind of functionality:
https://gerrit-review.googlesource.com/#/c/103362/

The same code could be added to git-review-hook in order to enable call of other hooks. The first hooks that gets installed is supposed to create the commit-msg.d folder and next hooks will be able to deploy themselves into this folder.

I'm getting strange behavior when I go to edit my commit message. I think read is capturing key codes meant for movement.

Here is my environment as it relates to line 306 of the script:

$ tty >/dev/null 2>&1 && echo true
true

$ echo $EDITOR
/opt/homebrew/bin/nvim