1

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?

2
  • 3
    What is the reason why you're not using git bisect to isolate the commit that first introduced the bug? You didn't really give a clear explanation of that in your question. Jun 16 '14 at 16:48
  • @Cupcake, 1) some commits do not compile at all (debugging someone else's code) 2) some commits need to be split up, because they contain many unrelated changes and isolating a bug to that commit is rather useless.
    – Vorac
    Jun 17 '14 at 8:23
2

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.

1
  • 2
    +1 the biggest problem is probably what the OP already knows: "commits need to be split up, because they contain many unrelated changes". Consequently, the better way to do it would be do smaller commits of only related things to avoid all the problems that stem from that self-created mess.
    – JensG
    Jul 5 '14 at 1:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.