Skip to content

Add an option to disable the stacked-branch push prompt #6144

Closed

Description

@lassebuur

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.

Activity

  1. stefanhaller commented on Oct 20, 2026

    @stefanhaller
    Collaborator

    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.

  2. lassebuur commented on Oct 21, 2026

    @lassebuur
    Author

    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.

  3. stefanhaller commented on Oct 21, 2026

    @stefanhaller
    Collaborator

    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.

  4. stefanhaller commented on Oct 31, 2026

    @stefanhaller
    Collaborator

    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.

  5. lassebuur commented on Nov 2, 2026

    @lassebuur
    Author

    Thank you for responding to my crazy request so fast 🫶. Appreciate it.

  6. added a commit that references this issue on Nov 3, 2026
    0002c03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions