Preorder, not chronological
Parent-before-child nesting outranks global ordering. Roots sort by their own updatedAt — never by their newest child — so a stack doesn't jump the list because someone pushed to its tip.
Native macOS 14+ · Swift 6
Review the
whole stack
Stacked pull requests are a dependency graph, but every code host flattens them into a list. MergePulse rebuilds the graph on your Mac — parent before child, ancestors preserved through filters — and gives you the diff, the discussion and the review in one native window.
> GitHub.com & Enterprise Server · Device-flow auth · Tokens stay in Keychain
100%
Native SwiftUI + AppKit
0
Backend servers involved
2
Hosts: .com & Enterprise
500MiB
LRU offline diff cache
// Stack detection
Branch names lie.
Repository identity doesn't.
MergePulse indexes every PR by (host, head repository, head ref) and matches it against each child's base. Equality of branch name alone is never enough — it breaks across forks and mirrored repositories. When a parent is genuinely ambiguous, you get a warning and the candidate set, not an invented answer.
Filters keep ancestors
Filter to your own PRs and the non-matching parents stay as dimmed context rows. You never lose the thread of what a change sits on top of. Unrelated descendants stay out.
Cycles surface as cycles
A dependency loop shows every affected PR as a root with a cycle indicator. Deleted or inaccessible source repositories get an explicit unresolved state instead of silently vanishing.
Note — these are inferred branch dependencies, not verified commit ancestry. MergePulse does not rebase your stack or sequence merges for you.
// Review surface
Comment where the code is
Unified or split, your call — ⇧⌘D toggles. Inline threads sit beneath their code and span both columns in split view. An AppKit canvas virtualizes the rows, so a 4,000-line diff scrolls like a text editor.
payments-api · #418 ledger writes · Ledger.swift
| 41 | func post(_ entry: Entry) throws { |
| 42 | − try ledger.append(entry) |
| 42 | + try ledger.append(entry, idempotencyKey: entry.id) |
| 43 | + try audit.record(.posted, entry.id) |
| 44 | } |
Pending review
line 42 · right side
Idempotency key is the entry id — if a retry reuses the id after a partial write, does append still return the original result?
Local
Held in memory. Never sent until you submit.
Pending
Saved on GitHub as an unsubmitted review. Survives a restart.
Published
Live on the PR. Toggle them off to read your own notes.
Merged
Merge with an expected head revision, or it refuses.
// Device authorization
No client secret. No middleman.
MergePulse uses OAuth device flow against your host directly. There is no MergePulse server between you and GitHub, and there is no embedded secret to leak. Tokens live in the macOS Keychain, scoped to the signing team identifier so they survive a rebuild.
-
01
Enter your host
GitHub.com, or an Enterprise Server origin with an admin-registered client ID.
-
02
Copy the code
The app shows a user code and opens the verification page in your browser.
-
03
Authorize
Approve on GitHub. MergePulse polls at the server's interval and handles slowdown.
-
04
Pick repositories
Select from your accessible repos. The choice is remembered per account.
Settings → Authorization
> host github.com
> device code BFD2-4K7Q
> status authorized · token stored in Keychain_
// Reviews and comments
Frequently asked
▸ What is the difference between local comments and pending comments?
Local comments are stored only in MergePulse's memory. They are not sent to GitHub until you explicitly submit them, and they are lost when you quit or sign out.
Pending comments are saved on GitHub as part of an unsubmitted review. They survive restarting MergePulse and await review submission.
▸ Does submitting a review use an existing pending review?
Yes. If the signed-in user already has a pending review on the same pull request, MergePulse adds the local comments to that review and submits them together.
Fresh reviews are created and submitted in one request. MergePulse uses the pending-review path only when you already have a pending review. If adding local comments to that pending review is interrupted before submission, those comments may remain pending. Recovering the review helps prevent duplicates.
▸ Should pending comments appear in code view?
Yes. MergePulse loads your pending review's comments and displays them beneath their matching code, labeled Pending review. Comments whose code no longer matches appear beneath the file instead.
If a pending review targets an older revision, resolve it on GitHub before submitting against the new revision.
▸ Is a review summary required?
No. The review summary is optional for commented reviews, approvals, and requests for changes.
▸ Can I hide published comments in code view?
Yes. Use the comment icon to the left of Unified/Split in the PR header. Published comments are shown by default, with a green border around the icon. Turning it off hides published comments while keeping local comments and pending-review comments visible.
Get MergePulse
Requires macOS 14 or later. Signed with a Developer ID certificate. Read-only review ships today; inline threads, writes and the virtualized diff engine are on the roadmap.
> Not yet notarized · built per-architecture