Describe the bug
When performing an interactive rebase (as a result of conflicts during a cherry-pick), lazygit attempts to do something with neovim, but fails, giving the following error:

To Reproduce
For reference, most of the error appears to be part of the original commit message:
Implement udiskie into config.yml and i3 config
- Add config.yml for udiskie to ignore snap app mounts
- i3 config: launch udiskie on startup
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# Date: Sat Nov 23 19:09:46 2019 -0700
#
# interactive rebase in progress; onto ec9e90f
# Last command done (1 command done):
# reword 81e0d2d Implement udiskie into config.yml and i3 config
# No commands remaining.
# You are currently editing a commit while rebasing branch 'YogaManjaro' on 'ec9e90f'.
#
# Changes to be committed:
# modified: .config/i3/config
# new file: .config/udiskie/config.yml
Expected behavior
I'm new to lazygit, so I'm not sure exactly what it was supposed to do, but I'm guessing it's supposed to submit a commit message identical to the cherry-picked one to finish of the rebasing
Desktop (please complete the following information):
This might have something todo with this issue: #437
You could try changing your git config to this:
[core]
editor = nvim -es
I can confirm that doing git config --local core.editor 'nvim -es' did the trick.
For connections to #437, note that for commits it is doing as expected (stdout from neovim/git is displayed after editing and the "press enter to return to LazyGit" is displayed), but it doesn't do this for the rebase commits*. So maybe that logic just needs to be implemented for rebase/merge stuff?
*that is, after doing the fix mentioned above.
I think this is actually indicative of a flaw in how things are currently handled in lazygit with regards to interactive rebasing. When we switch to a subprocess, we currently lose all information about the current app state and we start from scratch when we come back. For that reason, the code currently tries really hard to avoid opening up an editor for a commit message when halfway through a rebase, because if we leave lazygit we lose track of what remaining commands there are to run. It seems like in this case git had decided to bring up the commit message editor but lazygit isn't aware of that and so we get the weird clash.
I think the solution will be to either find some way of switching to a subprocess more gracefully where we just suspend the app and then return, or having a different way of storing the fact that we're halfway through a semi-automatic process and there are X steps remaining.
the code currently tries really hard to avoid opening up an editor
Are you saying the code is... lazy?
Sorry, I had to.
Note I'm also getting similar errors when I try and squash commits together.
I'm now having an issue where neovim auto-exits without allowing me to make edits to commits for some reason. This also occurs outside of lazygit as well; I can't simply run git commit without neovim auto-closing.
@jesseduffield Along your line of thinking, something I do a decent bit in neovim is use Ctrl+z to make neovim a background process, where Ctrl+z sends a SIGTSTP to the terminal process. Then use fg (or do Ctrl+z with a zsh setting I run) to return it back.
I tried doing that with lazygit, but it does respond to the SIGTSTP signal for whatever reason. I think if lazygit could respond to a SIGTSTP, then it'd be fairly simple to implement the solution you're talking about.
the ctrl-z to return to shell prompt being ignored is annoying, is there a trick to change that ?