'm' instead of 'M' for merge

[AndrewSav]

I'd like to re-bind 'M' to 'm' for merge in the branches context. This conflicts with 'm' in the commits context for the rebase options, but I cannot think of why would I want that for branches. So two question:

1. is it possible to re-bind in the branches context only, so that rebase options are unaffected for commits
2. is there anything very useful for rebase options while in branches? Am I going to shoot myself in the foot with this change?

Thanks!

[jesseduffield]

the 'm' keybinding is defined globally so unfortunately we can't rebind it just for one context. I'm open to changing this so that when we're not merging/rebasing, pressing 'm' on a branch asks you if you want to merge, but then while a merge/rebase is in progress, pressing 'm' gives you the option to continue/abort. This sounds like a more intuitive interface. Based on my googling, it's not possible to start a merge/rebase while already merging/rebasing.

The downside would be that the same sequence of keys would yield a different result given the context (e.g. pressing m+enter when not merging/rebasing gives a different result to when you are merging/rebasing) but I doubt that would be a problem in reality.

What are your thoughts on this @stefanhaller @mark2185 ?

[mark2185]

If we know before pressing m whether we're in a rebase or not (and we do), I see no reason why should we ever pop up the Rebase options menu if both of the options are going to lead to "You are currently neither rebasing nor merging".

The downside would be that the same sequence of keys would yield a different result given the context but I doubt that would be a problem in reality

Depends on the perspective, I see that as an upside from the usability viewpoint 😅

[stefanhaller]

I'm not super excited about the proposal, but that's only because of my own personal preferences of how I work. It's not a huge deal, and if it's an improvement for some people, I'm not opposed.

To elaborate: I never, ever merge branches locally, so I'm happy that M and m are different shortcuts. If I accidentally hit m thinking that I could continue a rebase, it would be confusing if this tried to randomly merge some arbitrary branch that happens to be selected. Here's a real-world situation that I have run into a few times:

• In my fork I keep an integration branch of all my open branches, each one squashed into a single commit
• To create such a squashed commit, I use the following custom command in the branches panel: git merge --squash --ff {{.SelectedLocalBranch.Name}} && git commit -m "[SQUASHED] {{.SelectedLocalBranch.Name}}"
• If this fails with a conflict, and if resolving the conflicts takes a while, I might then forget that I'm not in a rebase and try to hit m to continue.

Admittedly, it's kind of unlikely that the focus is in the branches panel when I do that, so maybe it's just fine in practice.

[jesseduffield]

I've tested this out locally and I'm not sold on it. Here's the branch if anybody wants to test it out: https://github.com/jesseduffield/lazygit/tree/test-m-keybinding

@AndrewSav in answer to your second question:

is there anything very useful for rebase options while in branches? Am I going to shoot myself in the foot with this change?

The rebase options are also merge options. That is: the continue/abort options will work whether you're in the middle of rebasing or merging. So while you're merging/rebasing a branch you will indeed want to have access to the 'm' keybinding.

[AndrewSav]

the 'm' keybinding is defined globally so unfortunately we can't rebind it just for one context.

Is there anything fundamental here that makes it so? It appears we can have same keystroke bound differently in different context, why cannot a context binding override global binding? @jesseduffield

[jesseduffield]

To fix this we would need to define (in the code) a keybinding in the branches panel with its own key that invokes the global handler. There's no fundamental reason we can't do this beyond it requiring us to define per-panel keybindings for each global keybinding, which would require a lot of extra maintenance.

With that said, you can actually create a custom command for git merge (which does take precedence over the global keybinding) like so:

customCommands:
  - key: 'm'
    context: 'localBranches'
    command: 'git merge {{ .SelectedLocalBranch.Name | quote }}'
    after:
      checkForConflicts: true

With the caveat that checking for conflicts afterwards is only supported on the current lazygit master branch so you'd need to clone the repo and build from source (which is pretty easy if you have go installed: you just do go install in the root of the repo).

[AndrewSav]

@jesseduffield

it requiring us to define per-panel keybindings for each global keybinding

I'm not sure I can understand why. Intuitively, it should only be required if a global keystroke overlaps with a panel keystroke, and only for the panel where there is an overlap, not for every panel. This sounds like something that could be detected in the code. Is that not so?

[AndrewSav]

Sorry never mind, it looks like it is already working like that. And even if it does not I think that I can find a re-mapping that will work for me. Please consider this enquiry closed and thank you very much for your attention and guidance.