Can it land?
How Limn decides if a pull request can merge, and what each blocker means.
Every place in Limn that tells you whether a pull request can merge gives the same answer: the Open pull requests list, the Pending board, the Timeline and the pull request’s own Overview tab. Limn reads it from GitHub’s own merge state, which takes your branch protection rules into account, and turns it into one plain status. When GitHub only says “blocked”, Limn lists the likely reasons.
#The statuses
| Status | What it means | Can merge? |
|---|---|---|
| ready to merge | Nothing is in the way. | Yes |
| checks failing | Some checks that are not required are failing. GitHub will still merge it. | Yes |
| behind base | The repository requires branches to be up to date. Update the branch first. | No |
| blocked | Required checks or reviews are not satisfied. Limn lists the likely reasons. | No |
| conflicts | It conflicts with the base branch. Resolve the conflicts first. | No |
| draft | Mark it ready for review to merge. | No |
| lands after #N | It targets the branch of another open pull request, #N, which must merge first. | No |
| in merge queue | GitHub’s merge queue has it and will merge it in turn. | Queued |
| auto-merge armed | Limn will merge it once the blockers clear. | Armed |
| mergeability unknown | GitHub has not worked it out yet. It usually knows within a minute. | — |
#Why is it blocked?
GitHub folds many different rules into the one word “blocked” and does not say which one applies. Most people cannot read a repository’s branch protection settings either. So on the pull request’s Overview tab, the Blocked row lists the likely causes from what Limn already knows, the surest first:
- From GitHub itself (certain): “a reviewer requested changes” or “required reviews aren’t in yet”.
- From the pull request’s facts (likely): “CI is red on the head commit”, checks that have not reported yet, or review threads not resolved on GitHub (with how many of them look addressed).
- When none of these explains it, Limn says so, rather than leaving “blocked” on its own. Other rules, such as signed commits or required deployments, may be the cause.
Limn never states that unresolved threads are the blocker. Many repositories do not require threads to be resolved, and Limn cannot see that setting.
#What you can do
- Open the pull request and stay on the Overview tab.
- Press Show actions. The actions are hidden until you ask, so a click cannot write to GitHub by accident.
- If it is ready, press Merge and choose Create a merge commit, Squash and merge or Rebase and merge (only the methods the repository allows).
- If it is behind, press Update branch. Where both are allowed, first choose Rebase onto main or Merge main in (with your base branch’s name in place of main).
- If something must clear first, press Merge when ready (see Merge when ready).
- If it conflicts, press Resolve conflicts (see Resolve conflicts by hand).
On the Pending board
Cards on Ready to land show Merge only when the stored state says it can merge. The board never asks GitHub when it opens; the live merge options load only when you press. A pull request already in a merge queue never shows Merge.
Withdraw approval on the Overview tab dismisses your own latest approval, if you gave one.
#Why it helps
GitHub’s “mergeable” only means “no conflicts”. A pull request with failing required checks is still “mergeable”. Limn’s status uses the state that respects branch protection, says it the same way everywhere, and tells you what to do next. For failing checks, see Read CI logs.