"W. Trevor King" [off-list ref] 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.
On Wed, Mar 28, 2012 at 12:11:27PM -0700, Junio C Hamano wrote:
"W. Trevor King" [off-list ref] writes:
quoted
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.
Hopefully patches v8+ will be cleaner ;).
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
On Wed, 28 Mar 2012, W. Trevor King wrote:
On Wed, Mar 28, 2012 at 12:11:27PM -0700, Junio C Hamano wrote:
quoted
"W. Trevor King" [off-list ref] writes:
quoted
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