HanZephyr Merge Dependent Pull Requests
A stack is a dependency chain: the lowest pull request targets the destination branch, and each higher layer depends on the one below. Use the repository's supported workflow and merge policy. Native stack tooling is useful when available, but a particular hosting service, API, or extension is not required.
Establish the live dependency chain
Read current pull-request metadata and fetch relevant Git refs. Record each layer's repository, base, head branch and exact OID, open or merged state, and required review and check status. Branch names alone are insufficient, especially across forks. If the host provides stack metadata, compare it with the base chain and Git history; resolve contradictions before changing the affected layers.
Determine the requested landing range. Landing a dependent layer also requires its unlanded dependencies; do not silently include unrelated pull requests. Ask only when conflicting metadata or an unspecified boundary changes the authorized merge scope.
Preserve local work. Use a clean checkout or isolated worktree when branch operations would interfere with existing edits. Record old parent tips before rewriting or landing lower layers; they may be needed to isolate a child's own commits later.
Choose the supported path
Discover available tools, their documented operations, merge methods, and concurrency guarantees. Do not invent host API fields or assume a stack command is installed. Follow any repository requirement to use a merge queue or stack manager.
- With a supported stack manager, verify the selected range and its effects on upper layers before invoking it. Do not rebuild or relink a stack merely because the tool can do so.
- Without one, merge sequentially from the bottom up, updating and validating each remaining dependency as described below.
Different authors or fork locations are not inherently blockers. Check actual permission to update every branch that needs adjustment. If a required mutation is unavailable, finish independent preparation and report the precise blocked operation.
Refresh and validate affected layers
Refresh only when required by mergeability, repository policy, or the requested work. Use the project's permitted merge-forward or rebase strategy and propagate necessary changes from parents to children in order.
For a rewritten push, capture the exact remote OID and require an explicit --force-with-lease=refs/heads/<branch>:<observed-oid> or a verified equivalent. A concurrent update requires inspection; raw force is not a substitute. Rewrites and conflict resolutions invalidate prior evidence for affected commits: inspect each layer's diff against its live base and rerun applicable checks, then refresh reviews, approvals, and merge status.
Some stack tools publish rewrites before local validation is possible. Confirm that behavior first, and inspect and validate every affected layer immediately afterward. Do not merge while required evidence is pending or failing.
Land from the bottom upward
Immediately before submitting each merge or supported stack range, recheck current head OIDs, dependency order, non-draft/open state, and required gates. Use a head-match condition when the host supports it. If a head moves, reassess that change instead of merging based on stale review evidence. Do not bypass required reviews or checks.
For sequential landing:
- Merge the lowest ready layer with the repository's permitted merge method. If queued, wait for its actual landing before depending on that result.
- Fetch the resulting destination and inspect remaining pull requests; hosts may have retargeted or rewritten them automatically.
- Retarget the next dependent to the correct live base where necessary. Verify that its diff contains its intended changes and does not replay already-landed work.
- When the parent landed through squash or rebase, its original commits may no longer be ancestors of the destination. Merely changing the pull request base may duplicate changes or produce conflicts. Use the recorded old parent boundary to isolate the child's own commits and replay them onto the new base when needed. Inspect the resulting tree and diff; do not blindly rebase the entire old chain.
- Validate the updated layer and recheck required host gates before merging it. Continue only through the authorized range.
For a native range operation, verify every selected layer's result independently; submission success does not prove atomic or completed landing. If a failure occurs partway through either path, inspect the actual merged, queued, and open states before retrying. Preserve successful landings and repair only the remaining range.
Verify completion and remaining dependencies
Confirm every selected pull request is merged and its intended changes are present in the destination. Merge and squash strategies require different ancestry evidence; a missing original commit alone does not mean a squashed change is missing.
For partial landing, verify the remaining base chain, each live head and diff, and any reviews or CI invalidated by retargeting or rewriting. Keep pending queues and checks explicitly pending.
Delete branches only within authorized cleanup, after their corresponding changes are confirmed landed and no open pull request or remaining dependency still needs them. Report what landed, what remains, the relevant verification, and any cleanup not performed.