Skip to main content

Frequently Asked Questions

The docs talk about the commit header, description, types… What are those?​

If you are using Conventional Commits, the commit message is divided into these parts:

  • Type: The first word of the header. It describes the kind of change that the commit is introducing (e.g. feat or fix).
  • Scope (optional): The part of the codebase that is affected by the change (e.g. docs or cli).
  • Description: The rest of the header, after the type and scope.
  • Body (optional): Separated from the header by a blank line, it contains a more detailed description of the changes.
  • Footer(s) (optional): A word token followed by either the separator :<space> or <space>#, followed by a string value (e.g. BREAKING CHANGE:, Closes, Fixes).

For non-conventional commits users, the commit message is divided into three parts:

  • Header: The entire first line of the commit message.
  • Description: Same as the header (sans Gitmoji, if present).
  • Body: Anything after the first line.

How do I force a commit in spite of linting errors?​

You can use the --force flag:

git sumi --force 'wip'

My team has very specific requirements not covered by the rules. What can I do?​

You can use a custom pattern that commit headers must match. For example, if you want to enforce the use of a JIRA issue key as the first element in the commit header, you can use the following (regex) pattern:

header_pattern = '^JIRA-\d+: +'

If this is still not enough, please open an issue.

Can I enforce the rules only on the main branch?​

Yes. If you're using the commit-msg hook (git sumi --init commit-msg), modify it so it only runs on the main branch:

.git/hooks/commit-msg
#!/usr/bin/env bash

# Commit-msg hook generated by git-sumi.
# For more information and documentation, visit: https://sumi.rs

set -e  # Exit on any error.

get_current_branch() {
    # Check if HEAD exists (i.e., if there are any commits).
    if git rev-parse --verify HEAD >/dev/null 2>&1; then
        git rev-parse --abbrev-ref HEAD
    else
        echo "main"  # Assume 'main' for initial commit.
    fi
}

current_branch=$(get_current_branch)

# Check if the current branch is 'main'.
if [ "$current_branch" != "main" ]; then
    exit 0  # Exit successfully without running git-sumi.
fi

# Check if git-sumi is installed.
if ! command -v git-sumi &> /dev/null
then
    echo "git-sumi is not installed. Please install it. See https://sumi.rs for instructions."
    echo "Alternatively, edit or remove the commit-msg hook in .git/hooks/commit-msg."
    exit 1
fi

# Run git-sumi on the commit message if on the 'main' branch.
git-sumi -- "$(cat $1)"  # Exit with error if linting fails.

If you are using squash-and-merge pull requests, you can use git-sumi to lint the pull request title, which will be used as the merge commit message.

How do I enable shell completion?​

The --generate-shell-completion flag generates a shell completion script for the specified shell.

For example, to generate a completion script for bash:

git sumi --generate-shell-completion bash

This command will print the completion script to the console. You can save it to a file and source it in your shell's configuration file (e.g. ~/.bashrc).