9

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.

Craig P. Motlin
  • 26,452
  • 17
  • 99
  • 126
  • 2
    maybe the `fixup` and `autosquash` options could help here? http://stackoverflow.com/questions/2302736/trimming-git-checkins-squashing-git-history/2302947#2302947 – VonC Jul 15 '10 at 04:15
  • @VonC Thanks, that will at least make these steps a little faster. – Craig P. Motlin Jul 15 '10 at 12:36
  • excellent (for a start). You could post an answer illustrating how the steps are faster with those options. – VonC Jul 15 '10 at 12:47

2 Answers2

5

When the editor for the commit list in an interactive rebase shows up, you are free to add, remove or reorder commits to your liking. It's basically a way to influence the cherry-picking-in-a-loop that is going to take place (that's what rebase boils down to).

user502515
  • 4,346
  • 24
  • 20
3

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
  • 134,834
  • 32
  • 188
  • 245
  • +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 Jul 14 '10 at 22:46