Easily moving both direction of time during a rebase

Question

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.

So I 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 edit declared commits.
• 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 --ammend the latter commits in order to be compatible with the edited hystory.

---

TL;DR;

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?

Answer 1

This is my opinion, based on my experience.

Debugging is one process. Rebasing is a different process. If you try to combine the two of them you get a mess.

At the point that you start your rebase, you should have working code. If you don't have working code, stop what you're doing and fix the code. If this is code that someone else has submitted to you, this is their problem, not yours. If your job is to integrate other people's code, it's perfectly reasonable to kick the problem back to them. Otherwise you just make more work for yourself.

@Cupcake has already asked why you're not using git bisect. Your answer tells me that you're working on too large a chunk of code. "Large" is not defined by number of lines, but rather by functionality. If someone is submitting code for you to integrate then they should be breaking it up into the right chunks, not you. If a chunk of code deals with multiple unrelated features then it's too large. (I'm using the word "chunk" to mean a logical changeset, which may include more than one commit. There's nothing wrong with working on multiple commits as long as they're logically related.)

I personally would not recommend your workflow. I think you should be using pull requests. I use this at my day job. Basically one person maintains a repository and other people submit requests to add commits to the repo. If the maintainer approves the change, great. If not, not. Each request has to stand on its own, and each request should add a very well-defined piece of functionality.

The nice thing about pull requests (and forking a repository) is that it makes a very clear separation of who is responsible for doing what. It sounds like that separation is missing from your current workflow.

If you're in the mood to dig in more deeply, I found Vincent Driessen's article on Gitflow to be very useful.

This is not what you asked, but you might also want to look into unit testing and continuous integration. Those things will make it harder for bugs to hide and ultimately save you some time as well.

Good luck! Git can be tricky to learn and it took me months to feel comfortable with it.