On Thu, Jul 17, 2008 at 02:49:04PM -0400, Len Brown wrote: > One thing I wish I had in git is a way to make this sequence easier... Linus's answer (with rebase -i) is probably better, but my habit is to do what you describe, with some minor shortcuts: > Say I have a big topic branch with 30 patches in it. > The 3rd patch turns out to have a bug in it, but the > rest of the series is okay. Today I invoke gitk on > the branch and keep that open. > Then I create a new topic branch at the broken patch. > > I always consult ~/src/git/Documentation/git-reset.txt > so I can remember the following sequence... > > $ git reset --soft HEAD^ > $ edit > $ git commit -a -c ORIG_HEAD Instead of the above three steps, you can do just: $ edit $ git commit -a --amend > Now I've got the fixed 3rd patch checked in, > but 27 patches in the original branch are hanging > off the original broken 3rd patch. > So I git-cherry-pick 27 patches > I hope I get them in the right order and don't miss any... > > It would be nice if we could somehow git rebase those > 27 patches in a single command, but if we do, > that pulls with it the broken 3rd patch. At this point I do git rebase --onto HEAD old-sha1 name-of-branch-to-rebase (where old-sha1 is the name of the commit we just replaced, which I usually cut-n-paste out of gitk). That rebases the commits in the range old-sha1...name-of-branch-to-rebase onto the new HEAD commit that you just created, and replaces the named branch with the result. > come to think of it, I can probably export 4..27 as > an mbox and then import it on top of the new 3, > maybe that is what others do. That works too. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
