Allow rewording in interactive rebase

[jesseduffield]

Is your feature request related to a problem? Please describe. We do not currently allow arbitrary commits to be marked for re-wording as part of an interactive rebase.

Describe the solution you'd like A child lazygit process will be invoked by git to determine the content of a commit message, and it will talk to the parent lazygit process to get the new commit message from the user (via a prompt panel).

The parent lazygit process will choose a random TCP port to listen on and will serve requests to that port. When invoking git rebase, the parent process will pass some extra env vars:

• GIT_EDITOR=<path-to-lazygit>
• LAZYGIT_DAEMON_KIND=editor
• LAZYGIT_PORT=<some TCP port>

If you look in pkg/app/daemon/daemon.go you'll see we have some precedent for running lazygit as a daemon i.e. a separate process from the parent gui process. In this case we'll be using lazygit as our GIT_EDITOR and when lazygit starts with LAZYGIT_DAEMON_KIND=editor it will use an RPC request to the parent lazygit (using LAZYGIT_PORT) passing the path of the file that needs to be edited (i.e. .git/COMMIT_EDITMSG). The child process will block until it gets the response from the parent process. The parent process will prompt the user to edit the message and afterwards, will send a response to the child process.

Additional context We did some similar work for this a while back when thinking up ways to get lazygit to handle credential prompts from git (by setting GIT_ASKPASS=) but we ended up parking that work as we had security concerns. By contrast, this feature shouldn't have any security concerns given you'll only be editing commit messages.

One tricky question is: how do we know if the user wants to edit the message from within lazygit or from within an editor? Some options:

• have a way of jumping from the prompt panel to an external editor via some keybinding
• assume the user wants to use the within-lazygit prompt panel
• allow the config file to specify what should happen.

I'm leaning towards the second option just because it's easier to implement for the sake of this initial feature.

[stefanhaller]

Hm, somehow I'd expect lazygit to ask me for a new commit message right at the moment when I change a todo to "reword". That's the moment when I'm thinking about that commit; the rebase --continue might happen sometime later, and I might have had to resolve conflicts in between, so I might have forgotten what I thought I'd want to reword it to by the time it gets there.

And it also seems easier to implement. We'd bring up an editor panel right away (or a text editor if they used shift-R), and then we "just" have to remember the message somewhere. Probably not in the commit struct itself in order to not make it bigger, so probably in some map of sha to message in the model. We'd then have to pass this entire map in an environment variable down to the editor daemon.

I'm not sure the UX is perfect, but it's closer to what I'd expect. One detail question is how I change the message again after I set one, and before continuing. You could hit r (or shift-R) again, and that would bring up the editor again to let you enter a new version. It's unclear whether that panel should start with the original message or the last one that you typed; I could see arguments for both.

---

On the other hand, this approach would only work for reword, but not for squash. Asking for the message during the rebase would work for squash too, which could be an argument for that approach.

[jesseduffield]

Good point: the existing git CLI flow is to mark a commit as 'reword' and then later decide on the message, but if we can find a better flow for lazygit we should do that.

Admittedly, I never actually reword commits as part of a larger rebase so I don't have a good grasp on the ideal flow.

I take your point about squashing though: it sounds like this functionality should be implemented regardless of how we end up handling rewords.

[stefanhaller]

We could do both: set up an RPC channel like you suggested; then, when the time comes to reword a commit, the daemon passes the SHA of the original commit to the RPC call. The parent lazygit looks if it has a stored message for this and returns it if so, or opens an editor if not. This way it will work for rewords done from lazygit, but also for squashes, or for rewords that were initiated outside of lazygit.

We could also do it iteratively; do the simpler version first (which always asks for the message at rebase time), and add the fancier "ask-immediately-for-the-message" later. Maybe we end up not wanting it badly enough and will never add it.

[jesseduffield]

I completely agree on both points

[jesseduffield]

Playing with Fork right now and they get you to specify the new commit message at the time that you mark a TODO commit as 'reword' so that's good to know

[stefanhaller]

Yes, I was a long-time Fork user before I discovered lazygit, so that probably influenced some of my opinions above.

[ZaymonFC]

Good point: the existing git CLI flow is to mark a commit as 'reword' and then later decide on the message, but if we can find a better flow for lazygit we should do that.

Admittedly, I never actually reword commits as part of a larger rebase so I don't have a good grasp on the ideal flow.

I take your point about squashing though: it sounds like this functionality should be implemented regardless of how we end up handling rewords.

Personally, I'm okay with marking a commit as 'reword' and popping the default editor to edit the commit when the rebase gets to it. This is something I do fairly often and would love for lazygit to support it.

[lothemar]

Hi, first time user of lazygit here. This is something I tried to do & was surprised when I couldn't