tags:

views:

52

answers:

1

When I have a fix for a change that was a few commits earlier, I always wind up running rebase twice in a row. Is it possible to do this workflow all in one step? Let's say I have 4 new commits.

* (master) D
* C
* B
* A
* Base

I find a bug in B so I create a branch and fix it.

* (master) D
* C
| * (fix) Fix.
|/  
* B
* A
* Base

Next I run git rebase --onto fix B D to move C and D onto B.

* (master) D'
* C'
* (fix) Fix.
* B
* A
* Base

Finally I run git rebase --i fix^^ to see the last few commits and I squash B and Fix into a single commit.

* (master) D'
* C'
* B'
* A
* Base

Is there a faster way to accomplish the same workflow? I imagine that merging would be easier, but merging is out for me because I'm using git svn which requires a linear history.

+2  A: 

Are you aware of the --squash option to git merge?

--squash

Produce the working tree and index state as if a real merge happened (except for the merge information), but do not actually make a commit or move the HEAD, nor record $GIT_DIR/MERGE_HEAD to cause the next git commit command to create a merge commit. This allows you to create a single commit on top of the current branch whose effect is the same as merging another branch (or more in case of an octopus).

Greg Bacon
+1 because I did not know about --squash. However this requires the same number of steps. After I've created the fix, instead of two rebases, I would need to do git merge --squash, then git commit at the head, and then git rebase -i to reorder and squash the fix into the commit with the bug.
Craig P. Motlin