Repository navigation
PR merge should switch to the base branch instead of the default branch. #1096
Description
Activity
@vilmibm I have similar thoughts! Lots of people might have different expectations here. I think could be a reasonable default, let's leave this issue open to see if others chime in with the same expectation. If there's not a strong push, I think leaving it as is is reasonable.
The fact that there keep being dupes of this issue at least points to many folks wanting the option :)
Two cents: what's the workflow where you say "after merging this branch, I want to switch to a branch that doesn't have my changes on it"? Or "... to an unrelated branch"? I'll certainly acknowledge such workflows may exist even if I can't think of them, but "switch to a branch that doesn't have my work" seems like it'd be much less common than switching to the base branch of the PR.
as a maintainer, I review and merge a lot of pull requests from other people. I run through them like a checklist, expecting that after i merge each one i am back to a "neutral" state to either check out and review another PR or start some work of my own. In this mode (which is where I do most of my merging) I wouldn't want to go "back" to anything but the neutral home base of my repo: the default branch.
In general, depending on the project, the base branch probably is the default branch for the most part, and a change like the one this issue is suggesting would be invisible to most people. I'm concerned about the bitter surprise, though, when someone ends up unexpectedly on a non-default branch and then accidentally bases new work on it.
It's possible I"m overestimating 1) how often this would happen and 2) how bitterly one would react to this surprise.
@mislav @samcoe thoughts? i'm starting to lean towards just switching to the base branch of a merged PR.
I've actually got an oddball case. I'm using 'gh pr merge' in a worktree and I have the base branch checked out in another worktree. I get a "git 128" error when using the "-s -d" options with "gh pr merge" because the base (or default) branch is already checked out in another worktree.
I'd like to vote for the least surprising user experience is being left detached on the commit that used to be the branch you deleted. That way, nothing is changing for anybody :)
This is now open to contributions! The starting point for editing this functionality would be here:
Lines 324 to 330 in 2c981b7
Reacted by Boston CartwrightI think this is a great suggestion. I would love to start working on this :)
Describe the bug
When merging a pull request, currently the CLI switches to the default branch of the repository instead of switching to the base branch of the PR.
gh --version
Steps to reproduce the behavior
gh pr create --base other-branchgh pr mergeghwill take you back tomasterExpected vs actual behavior
I would think it would be more convenient to switch to the base branch of the PR (
other-branch) instead of the default branch of the repository (master). More often than not you'll probably want to either view the merged code with the rest of the code, or start working on another PR off that same base branch, be it an epic, etc.I classified this as a bug because I would consider it a UX bug as the behavior wasn't what I was expecting.
Original PR: #1095