After I have written some commits, I very often
git rebase -i over them, in order to test them, if necessary split them, take parts form one commit and
squash them to another, more appropriate one.
But there is a problem. Say, today I am hunting for a bug, that 5 recent commits are causing. I rebase interactively on the last known to work (bear with me, not using
git bisect for a reason). The next commit introduces the bug, but is a big mess some unrelated code.
git reset HEAD~ and then form several internally logical commits.
Here is the problem. I do not know which is the first problematic commit. So I select
edit for all commits when rebasing. After I am done with the problematic commit, I have a couple of commits in the past, that I would like to test further.
Currently, I do
git rebase --continue many times, until the rebase is complete, and then rebase interactively again. This has a few problems:
- It is tedious. At the very least, I would like a command that rebases to the top of the branch, skipping all
- Neverending merges. I need to merge often, and would prefer to first do the meaningful job of splitting the original commit, and only after that
git commit --ammendthe latter commits in order to be compatible with the edited hystory.
How can I achieve this bi-directional traversal on a branch, while at the same time, creating, removing and amending commits? Or is this workflow conceptually wrong?