Solution: Interactive git rebase doesn’t work
Solve problem with interactive rebase
Problem:
When running the git rebase -i @~2 command, we get a message that the command completed successfully, but the command does nothing, and the editor that opens does not even have a list of commits being processed.
Side observations:
Only one empty git-rebase-todo file is created in the .git/rebase-merge directory. In this case, git goes into a state of incomplete rebase, and the only way out of it is by deleting the rebase-merge directory (rm -rf .git/rebase-merge). The git rebase — continue and git rebase — abort commands give a message about the absence of head-name, and onto files. If you manually create the files onto (indicating commit) and head-name (indicating commit), then the rebase will complete, but nothing will be done.
Reason:
The problem is related to the “features” of how VScode works as the default editor for git.
Decision:
Change the default editor git to any other (for example vim). This will not affect the ability to work with the project from VS-Code in any way, except that when you run the git rebase -i command, the vim editor will open.
Explanation:
Let’s deal with rebasing commits. I know of at least three uses for it, and let’s start with the most obvious one — the usual rebase. Many people use it as a way to move their commits to an updated master branch.
So the usual rebase mode is:
We started working on our branch and made several commits in it. During this time, our colleagues also did not sit still and added several of their commits to the main development branch (master). As a result, our development is “somewhat behind” and we need to add these commits to our branch. You can do it with cherry-pick command, but it’s not exactly pretty. Therefore, the rebase command comes to our aid, and we rebase our entire branch to the new top of the main development branch (e.g. master). Under the hood, git will recreate all of our commits on our branch on the new top of master (and the old ones will dry out on their own over time).
The second use case for rebase is interactive rebase . In this case, we rebase commits on our own branch, or edit them (change their number, content, name ..). It can be useful to do this before merging into the main development branch in order to “clean up” our shortcomings, or before handing over the code to the customer. In this mode, we ask git to go back a few commits and re-do some work on our commits. This can be done for example with the command: git rebase -i @~2 or git rebase -i 123456. In the first case, we ask git to go back two commits, and in the second, we explicitly point to the commit before the start of the changes. The result of the execution will be the same: git will open the editor and offer us a list of actions with the commits that we indicated to it.
The first two lines indicate our two commits and the action (e.g. pick) that will be performed on them. The third line is the range of commits that git is going to process. We can change pick to edit (for example), and after closing the editor, git will execute the commits that were specified as pick and stop at the commits that were specified as edit. We can make changes to our commits (and even remove them), add them to new commits, and continue with the rebase.
And finally, the third way to use interactive rebase is a special case of the second — changing the commit description. The same can be done with the git commit — amend command. If we run git rebase -i , then we can edit the latest commit, including its description with the reword command.
