Thanks for the feedback! This is now merged.

I also don't use the pipelines and have no objection to merging this.

Then I'm fine with this change; like Malte, I don't actively use the pipelines.
(I like the reminder to run uncrustify and code tests before the final merging,
though.)

Exactly.

> Bitbucket would merge the default branch into the issue branch before running
the tests.
But it wouldn't commit that merge; this would be for testing only, right?

I don't really have a stake in the bitbucket pipelines, so I am not the right
person to review this.

If none of the others complains (given some time to react), perhaps you can
assume that everyone is fine with it. If you want to speed things up, perhaps
directly ask those who use this feature more actively.

It seems the new feature is already working nicely: no build was triggered when
I pushed the new branch, but it immediately started when I made the pull request.

I made a pull request at 
https://bitbucket.org/jendrikseipp/downward/pull-requests/115 .

The diff only changes three words, but the YAML file needs two extra spaces of
indentation now.

We currently run the Bitbucket pipelines for each newly pushed head revision.
This means that Bitbucket runs tests for pushes to the default branch, feature
branches that may never end up in the master repo (e.g., for papers), and even
commits that close branches (even if the branch was developed by others). Due to
all these build triggers, I usually run out of the 500 free build minutes per
month after around 10 days (each run takes 10-15 minutes). To use the free build
minutes for testing things we are actually interested in, I propose to use a new
Bitbucket pipelines feature: builds for pull requests 
(https://confluence.atlassian.com/bitbucket/configure-bitbucket-pipelines-yml-792298910.html#Configurebitbucket-pipelines.yml-ci_pull-requests).

The new setup would run the pipelines only for head revisions on branches that
have an active pull request. Also, in contrast to the current setup, Bitbucket
would merge the default branch into the issue branch before running the tests.
This would give us convenient warnings whenever a pull request needs updating
because of a failing automatic merge.