echasnovski / mini.nvim

Library of 40+ independent Lua modules improving overall Neovim (version 0.8 and higher) experience with minimal effort
MIT License
4.54k stars 175 forks source link

ci: ignore lines after the scissor line #854

Closed gpanders closed 2 months ago

gpanders commented 2 months ago

When using git commit --verbose (or when the commit.verbose git config option is set), the diff of the commit is placed into the buffer when writing the commit message after a so-called "scissor line". This can cause the commit linter to fail because of long lines. However, anything below the "scissor line" is removed from the commit message by git (see help git commit) so should not be validated by the commit linter.

Quoting the text from the git-commit man page:

--cleanup=<mode>
    This option determines how the supplied commit message should be cleaned up before committing. The <mode> can be strip, whitespace,
    verbatim, scissors or default.

    strip
        Strip leading and trailing empty lines, trailing whitespace, commentary and collapse consecutive empty lines.

    whitespace
        Same as strip except #commentary is not removed.

    verbatim
        Do not change the message at all.

    scissors
        Same as whitespace except that everything from (and including) the line found below is truncated, if the message is to be edited. "#"
        can be customized with core.commentChar.

            # ------------------------ >8 ------------------------

    default
        Same as strip if the message is to be edited. Otherwise whitespace.
echasnovski commented 2 months ago

Thanks for the PR!

I also remember wanting to allow trailing whitespace because it looks like usually being removed. However, if commit was done as git commit --cleanup=verbatim, the 'lintcommit.lua' script needs to detect that it still contains some improper lines.

So if there is a reliable and robust way to force commits to always be done with proper cleanup, I am all for this change. Otherwise I'll take time thinking about what is best here.

echasnovski commented 2 months ago

I've decided to make a more fundamental change and introduce the "strict" (line already done commits) vs "not strict" (editing commit) contexts. This also allowed to fix a slightly annoying issue of commit linting failing on git commit --amend which adds trailing blank lines (and previously failed).

Thanks for pointing the issue!