"Todo not found in git-rebase-todo" error when we try to drop merge commit

[waffleboot]

Describe the bug

I tried to drop merge commit. And I see error message:

Todo 0b698733598bb407c83e116eacd7abb24ac1cbff not found in git-rebase-todo.
error: There was a problem with the editor /opt/homebrew/bin/lazygit

To Reproduce
Steps to reproduce the behavior:

1. Take any git repo.
2. Make some commits in main and feature branches.
3. Make merge main branch into feature branch.
4. Try to delete merge commit.
5. See error

Expected behavior

Commit should be dropped.

Version info:
Run lazygit --version and paste the result here

commit=, build date=, build source=homebrew, version=0.40.2, os=darwin, arch=arm64, git version=2.43.0

Run git --version and paste the result here

git version 2.43.0

Additional context

The reason is EditRebaseTodo tries to find pick command instead of merge.

This is git-rebase-todo:

reset 05c3ae7 # message 1
pick c232d36 message 2
merge -C 84da9cb onto # Merge branch 'master' into feature

The latest command is merge while we try to find pick command to drop it.

[mark2185]

Just to confirm, the merge commit is HEAD?

[stefanhaller]

I can reproduce it. This command is currently only available for regular (non-merge) commits, because of the way it's implemented (as you noticed, it is looking for a "pick" commit). The same is true for "move commit up/down", "fixup", and "squash down". It would be nice if these were all disabled instead of failing with a cryptic error message, as long as we don't support them.

As for whether it makes sense to support them: "drop" is probably the only one for which the answer is yes. "Fixup" and "Squash down" don't make sense for merge commits, and "move down" is dangerous because you might move the commit to before the commit it's merging in. I'd probably disable that just to be safe, and then disable "move up" as well for consistency.

As long as "drop" is not supported directly in the normal commits view, as a workaround you can press "e" on the last commit before the branch, and then drop it there; this works. Note that this is a bit dangerous though, because lazygit's rebase view doesn't show the complete picture; it omits the "label" and "reset" commands that you can see by doing git rebase --edit-todo. Because of that, it's impossible to tell for the "pick" commands whether those are regular commits on your branch, or commits that will be brought in by a later merge. If you drop a merge from this view, it will also implicitly drop all the "pick" commits that are brought in by the merge, but it's impossible to see, and it may or may not be what you intended (maybe you wanted to "flatten" the merge as if you had rebased without --rebase-merges). So the whole thing is a bit confusing, and it would be nice if we could find ways to improve all this.

Final word of advice: just don't merge master into feature branches (rebase them onto master instead), you can avoid a lot of hassle and confusion this way.

[khaled4vokalz]

@stefanhaller ,
will it be fixed ?

[redoxahmii]

Same issue here anything on this ?

[dexter0201]

Same issue here.
MacOs M1

$ lazygit --version
commit=, build date=, build source=homebrew, version=0.44.1, os=darwin, arch=arm64, git version=2.39.5 (Apple Git-154)

[stefanhaller]

Here's a PR for those who want to test it: #4094. Please read the PR description for some limitations (which were also discussed in the long comment above).

[7adidaz]

same problem here, any updates on this?

[mark2185]

@7adidaz the comment above yours linked a PR about it.

[stefanhaller]

And it would be nice if those requesting the fix could try out the linked PR to see if it works the way you expect. Thanks!