edit

The whitespace hook

To prevent spurious trailing whitespace in the source code (which is frowned upon by the code style), a git hook checks for such whitespace automatically.

TLDR: Always run one of the following commands after cloning a core repository:

dunecontrol vcsetup # Performs setup actions related to the version control system

dunecontrol all # Complete module build, runs "dunecontrol vcsetup" as first step

The details

Lines with trailing whitespace are not allowed in the Dune source code. Unfortunately, trailing whitespace can easily creep into commits unnoticed, and not everybody uses an editor that recognizes the indentation hints. In order to keep that kind of changes out of the repositories, the server checks all pushed commits for a simplified version of the whitespace policy. Note that every version is checked, so you cannot fix a rejected commit by adding an extra commit that resolves the whitespace problem in the original commit1.

Due to the distributed nature of Git, the server cannot check your commits as you create them in your locally cloned repository. Instead, you should install our local whitespace hook that checks every commit at creation time and immediately rejects it if there are whitespace problems. Then you can easily fix those problems, stage the additional changes and re-commit.

As Git hooks contain executable code, they are not transferred during a clone operation for security reasons, so you normally have to install hooks manually. Unfortunately, that’s just another thing to remember when cloning a repository (which tends to happen quite often with Git), so we extended dunecontrol to take care of this step for you: When you run dunecontrol all on a Dune core module, it will automatically install the most recent version of our local whitespace hook from dune-common/bin/git-whitespace-hook into that module. If you only want to install the hook without starting a complete build, you can also run

dunecontrol vcsetup # Performs setup actions related to the version control system

Footnotes


  1. Instead, you have to amend the original commit. If the broken commit isn’t the most recent one, things quickly get hairy (basically, you have to create little commits that fix the problem for each broken original commit and then use git rebase --interactive to reorder your commits and then combine the original commits with those bandaids using the <fixup command during interactive rebasing). See the man page of git rebase and this GitHub article for further information. Yes, this can be just as scary as it sounds… ↩︎

Creative Commons License   |  Legal Statements / Impressum  |  Hosted by TU Dresden & Uni Heidelberg  |  generated with Hugo v0.131.0 (Sep 25, 14:17, 2026)