Git::MoreHooks::CheckIndent Released

Git::MoreHooks::CheckIndent is a plugin for the Git::Hooks framework. It checks that indentation is correct in the committed files. Please read Git::Hooks documentation on how to use plugins.

Stop the press! Git Already has …

Yes, it does indeed! The not-so-well-known Git configuration parameter core.whitespace is quite versatile in this respect. It supports different values, even tabwidth to tell how many space characters an indentation (tab) must be equal to.

core.whitespace : A comma separated list of common whitespace problems to notice. git diff will use color.diff.whitespace to highlight them, and git apply --whitespace=error will consider them as errors. You can use prefix “-” to disable any of them (e.g. -trailing-space):

• blank-at-eol treats trailing whitespaces at the end of the line as an error (enabled by default).
• space-before-tab treats a space character that appears immediately before a tab character in the initial indent part of the line as an error (enabled by default).
• indent-with-non-tab treats a line that is indented with space characters instead of the equivalent tabs as an error (not enabled by default).
• tab-in-indent treats a tab character in the initial indent part of the line as an error (not enabled by default).
• blank-at-eof treats blank lines added at the end of file as an error (enabled by default).
• trailing-space is a short-hand to cover both blank-at-eol and blank-at-eof.
• cr-at-eol treats a carriage-return at the end of line as part of the line terminator, i.e. with it, trailing-space does not trigger if the character before such a carriage-return is not a whitespace (not enabled by default).
• tabwidth= tells how many character positions a tab occupies; this is relevant for indent-with-non-tab and when Git fixes tab-in-indent errors. The default tab width is 8. Allowed values are 1 to 63.

CheckIndent options

Git core.whitespace doesn’t allow fine-tuning. If your repository has several different policies active for different files, then you are out of luck. Unless you use CheckIndent.

CheckIndent has only two configuration options, file and exception.

githooks.checkindent.file File Type Specific.

A regular expression matches against the file name. If config has several file items they are used in their order of appearance until a match is found. When a match is found, the parameters are applied to check the file.

Parameters are indent-char (allowed values: space, tab, both) and indent-size (allowed content: an integer number).

[githooks "checkindent"]
    file = ^proj1/old/.* indent-char:both indent-size:2
    file = \\.(c|h|cpp|hpp)$ indent-char:tab
    file = \\.py$ indent-char:space indent-size:4

Every file in directory :prog1/old support indentation with both space and tab characters, but indent size is only 2. If file name matches this regexp (= is located in directory prog1/old), then the following lookups are skipped. If file is located somewhere else and is a C/C++ file, then tab is the only allowed indent character. If space is not allowed, then parameter indent-size is meaningless and skipped over. Python files however get the opposite treatment: only space is allowed and indent size is strictly 4 spaces.

githooks.checkindent.exception Exceptions to the rule

After finding the faulty lines ever line is matched against the exceptions. If a match is found, then we skip the error. The parameter exception consists of two parts. The first part is the same regular expression as in file. The second is another regexp. This regexp defines the allowed exceptions.

[githooks "checkindent"]
    file = \\.(c|h|cpp|hpp)$ indent-char:tab
    exception = \\.(?:c|h|cpp|hpp)$ ^[[:space:]]{0,}[\\s]{1}\\*

In the above example the C/C++ files allow a comment to be indented with one extra whitespace. This is according to the Doxygen comment pattern.

[ This entry simultaneously published at author’s blog Exercises in Restful Integration and Continuous Delivery. ]