You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add an option to disable the stacked-branch push prompt #6144
Is your feature request related to a problem? Please describe.
Since the stacked-branch push support introduced in v0.66.0 (#6045), pushing the current branch can show an additional prompt asking whether to push branches stacked below it too.
For example, when pushing master, Lazygit detects a local wip branch below it with unpushed commits and offers:
Push all these branches in addition to the current one
Push only 'master'
Cancel
I only want to push the current branch in this workflow. Repeatedly choosing “Push only” adds friction to an otherwise routine action. The first/default choice also offers to push additional branches that I did not intend to publish as part of that action.
Describe the solution you'd like
Please add a configuration option to disable the stacked-branch push prompt and always push only the current branch, restoring the previous single-branch behavior.
The existing stacked-branch behavior could remain the default. Opting out should retain Lazygit's normal upstream-selection and force-push confirmation handling; it should only skip offering to push other branches.
Describe alternatives you've considered
Selecting “Push only” each time, which is the repetitive interaction I would like to avoid.
Replacing the push keybinding with a custom command that runs git push. This bypasses Lazygit's normal upstream-selection and force-push dialogs as well, so it is not an equivalent replacement.
Additional context
Observed on Lazygit v0.66.1, Linux, installed through Nix.
The example you give involves master. Can you think of examples that don't involve master, and where you still want to avoid the prompt? I'm asking because I wonder if excluding branches that are stacked below a main branch might be a better solution than an opt-out config. I generally try to avoid adding options that only very few people have a use for, and this one seems to be such a case to me.
But I have to admit that I don't understand your example really. Lazygit should only offer the wip branch if the tip of wip is contained in master. Has it been merged to master? Could you post an ASCII-art sketch of the topology you are talking about? We may also simply have a bug here.
Thanks for looking into this—and thank you for all your work on Lazygit! It’s an amazing application, and I really appreciate how much easier it makes working with Git.
To clarify the original example: yes, the tip of wip was contained in master after a merge. So the detection seems correct; I just wasn’t thinking of those branches as a stack that I wanted to push together. I only intended to push master, leaving the remote wip branch unchanged.
Honestly, I don’t have a strong preference for a config option versus another solution—I suggested an opt-out because the new prompt added an extra step to my usual push workflow.
My expectation when pressing P is to push the current branch. I wasn’t intentionally working with a branch stack, so being asked about pushing other branches was unexpected.
Excluding main branches would address my original example, and I’d be happy with that improvement.
Good, in that case I can think of two possible mitigations: 1. stop looking for more branches to push once we reach master, and 2. when there are merge commits, only consider branches reachable through the first parent but not the second. Either of these would have fixed your example, but I'll probably do them both. I think it's a reasonable restriction, because the feature is really only meant for linear stacks of feature branches.
It will take a little while because I'm on vacation right now, but I'll try to get this fixed before the next release.
I ended up doing only the first of the proposed two fixes (see #6169 in case you want to review or test it); claude tells me that the second is a valid scenario that some people might use, where stacks of branches are updated by merging rather than rebasing. I personally find this crazy, but I don't want to break people's workflows unnecessarily.
Activity
stefanhaller commentedon Oct 20, 2026
The example you give involves master. Can you think of examples that don't involve master, and where you still want to avoid the prompt? I'm asking because I wonder if excluding branches that are stacked below a main branch might be a better solution than an opt-out config. I generally try to avoid adding options that only very few people have a use for, and this one seems to be such a case to me.
But I have to admit that I don't understand your example really. Lazygit should only offer the wip branch if the tip of wip is contained in master. Has it been merged to master? Could you post an ASCII-art sketch of the topology you are talking about? We may also simply have a bug here.
lassebuur commentedon Oct 21, 2026
Thanks for looking into this—and thank you for all your work on Lazygit! It’s an amazing application, and I really appreciate how much easier it makes working with Git.
To clarify the original example: yes, the tip of
wipwas contained inmasterafter a merge. So the detection seems correct; I just wasn’t thinking of those branches as a stack that I wanted to push together. I only intended to pushmaster, leaving the remotewipbranch unchanged.Honestly, I don’t have a strong preference for a config option versus another solution—I suggested an opt-out because the new prompt added an extra step to my usual push workflow.
My expectation when pressing
Pis to push the current branch. I wasn’t intentionally working with a branch stack, so being asked about pushing other branches was unexpected.Excluding main branches would address my original example, and I’d be happy with that improvement.
stefanhaller commentedon Oct 21, 2026
Good, in that case I can think of two possible mitigations: 1. stop looking for more branches to push once we reach master, and 2. when there are merge commits, only consider branches reachable through the first parent but not the second. Either of these would have fixed your example, but I'll probably do them both. I think it's a reasonable restriction, because the feature is really only meant for linear stacks of feature branches.
It will take a little while because I'm on vacation right now, but I'll try to get this fixed before the next release.
stefanhaller commentedon Oct 31, 2026
I ended up doing only the first of the proposed two fixes (see #6169 in case you want to review or test it); claude tells me that the second is a valid scenario that some people might use, where stacks of branches are updated by merging rather than rebasing. I personally find this crazy, but I don't want to break people's workflows unnecessarily.
lassebuur commentedon Nov 2, 2026
Thank you for responding to my crazy request so fast 🫶. Appreciate it.
Don't offer to push or pull branches merged into a local main branch (j…