On Wed, 28 Mar 2012, W. Trevor King wrote: > On Wed, Mar 28, 2012 at 12:11:27PM -0700, Junio C Hamano wrote: > > "W. Trevor King" <wking@xxxxxxxxxx> writes: > > > > > Grr. Thanks. I'm getting lots of rebase practice on this patch set, > > > but I'm still missing things… > > > > How do you "rebase"? > > > > It often is the easiest to check out the tip of the previous iteration, > > fix all issues that were brought up in the working tree, eyeball the > > output from "git diff HEAD" to make sure you addressed all the comments,o > > and then make separate commits, using "add -p" to sift the fix-ups > > according to which commit in the previous round they need to update. > > > > And then finally you run "rebase -i" to squash these fix-ups in. > > Ah, that makes a lot of sense. I had been running `rebase -i`, > editing the earlier commits, and using `commit -a --amend` to squash > them on. The problem with that approach is that you need to check the > changes vs the previous release before each amend, while with your > suggestion there's a single diff to look through. BTW. I personally use StGit (a patch management interface on top of git) instead of interactive rebase. Just in case, and to be able to write differences to previous version, I use git-format-patch to generate patches to a subdirectory, e.g. mdir.gitweb.v7/, and compare with previous version. -- Jakub Narebski Poland -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html