[Bug]: After a partial stack merge, the auto-rebase commits with the account's default email instead of the email chosen in the merge dialog #585

Describe the bug

When part of a stack is merged from the web UI with Merge stack, the merge commit uses the commit email chosen in the confirm dialog, which is correct. But the automatic rebase GitHub runs on the remaining PRs right afterwards creates commits whose committer is the merging user with the account's default email, not the email chosen in the dialog.

Many people keep a personal address as their GitHub default and pick their work address when merging in a work org. The merge dialog's email picker suggests that's supported, but the follow-up rebase silently writes the other address into the org's branches. Undoing it means rewriting those branches locally and force-pushing again, and unstacking first so the next merge doesn't repeat it.

The rebase happened after a merge in the github.com web UI; the extension wasn't involved. Separately, gh stack merge (0.2.1) has no way to choose the merge commit email either (compare gh pr merge --author-email), so an API stack merge can only use the default.

Related, but a different code path: #371 (squash-merging a stack mixes the PR author's name with the merger's email).

Affected command

None: github.com web UI "Merge stack" (gh stack merge also has no commit-email option)

gh-stack version

gh stack version 0.2.1 (the rebase bug itself is in the web UI)

GitHub CLI version

gh version 2.103.0 (2026-10-21)

Operating system

macOS 15.7.7

Shell

bash 5.2

Steps to reproduce

1. Use an account with two verified emails, with the default set to address A.
2. Create a stack of three or more PRs.
3. From the web UI, merge the bottom part of the stack with Merge stack → Create a merge commit, choosing address B in the confirm step's Commit email dropdown.
4. Compare the commits on the remaining PRs' branches before and after: git log --format='%h %ae %ce' <default-branch>..<branch>

Expected behavior

The commits created by the follow-up rebase use the commit email chosen in the merge dialog (address B), or the dialog offers a separate choice for them.

Actual behavior

The merge commit on the default branch correctly uses address B. Within seconds, the remaining PRs are rebased onto the default branch and force-pushed. Their commits keep the original authors, but every commit's committer is now the merging user with address A, the account default.

Observed on a six-PR stack, merging the bottom three: all 14 commits on the remaining three branches got the default address as committer.

Terminal output

N/A (web UI)

Preflight checks

• I searched the existing issues for duplicates.
• I ran gh extension upgrade stack and reproduced this issue on the latest stable release.