[littlenano]

Mergify is configured in the dashboard for this repository; there is no .mergify.yml in main. That is why the merge queue behaves inconsistently on pull requests: #17 and #18 got

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

while #16 got

This pull request does not currently match the merge queue conditions, so it cannot be queued from here.

Nothing in the repository says what those conditions are. This adds the configuration as code, holding only what differs from Mergify's defaults:

• merge_conditions: check-success = check — re-evaluated when the pull request reaches the front of the queue, so a green run from before a rebase does not count;
• merge_method: rebase with update_method: rebase — linear history, since squash would replace the commit message with the pull request title and drop the Co-authored-by trailer, and merge would keep producing merge commits;
• commands_restrictions.queue: sender-permission >= write, which is the default, written down so it is obvious that only maintainers can queue.

Everything else is left to the defaults: entry into the queue requires only Mergify's own -closed, -conflict, -draft, autoqueue stays off so nothing enters on its own, and batch_size stays 1. A maintainer ticks the box on Mergify's comment, or comments @mergifyio queue, and the queue merges once check is green.

Because no queue_conditions are set, the queue also accepts pull requests targeting other base branches (Mergify creates one queue per branch); add base = main if that should be restricted.

Note this takes effect only once it is merged into main; until then the dashboard configuration keeps applying. Mergify validates the file on this pull request.

[mergify]

This pull request does not currently match the merge queue conditions, so it cannot be queued from here. The box comes back if it matches again.