Peter Bergner <berg...@linux.ibm.com>:
> At this point, I get a little confused. :-) I know to submit my patch
> for review, I'll want to squash my commits down into one patch, but how
> does one do that? Should I do that now or only when I'm ready to
> push this change to the upstream repo or ??? Do I need to even do that?
If you want to squash a commit series, the magic is git rebase -i. You
give that a number of commits to look back at at and you'll get a buffer
instructing you how to squash and shuffle that series. You'll also be able
to edit the commit message.
I like to write really fine-grained commits when I'm developing, then
squash before pushing so the public repo commits always go from "tests
pass" to "test pass". That way you can do clean bisections on the
public history.
> Also, when I'm ready to push this "change" upstream to trunk, I'll need
> to move this over to my master and then push. What are the recommended
> commands for doing that?
There are a couple of ways. I usually squash as described above
then use "git cherry-pick". But that's because I have philosophical
reasons to avoid long-lives branches.
> I assume I need to rebase my branch to
> current upstream master, since that probably has moved forward since
> I checked my code out.
Yes, in general you'll want to do that.
> Also, at what point do I write my final commit message, which is different
> than the (possibly simple) commit messages above? Is that done after I've
> pulled my local branch into my master? ...or before? ...or during the
> merge over?
I do it at rebase -i time along with the squash of the series.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
