Recommended work flow with git to send in patches

Hi,

Compressing my "life long story" into a single question -- what's the recommended work flow to work with git and send in patches, when upstream might be slow in respond, and require squashing relevant patches into one?

You can use my following message as a start point, and please answer my last question, which I've been asking twice (in different ways) with no answer.

Please CC me when replying.

Thanks

---------- Forwarded message ----------
From: Tong Sun <suntong@cpan.org>
Date: Sun, Jun 6, 2010 at 8:56 PM
Subject: Working with git and sending in patches
To: grml-devel@ml.grml.org

Hi,

Just trying to put all jigsaw puzzle together here. Please correct me if I'm wrong.

First of all, philosophy for version control with git:

. While developing, small/independent commits are good thing, so that it's easy to decouple different changes.

. But when integrating something in a main branch, commits should contain all logical/related changes.

Steps (using grml-debootstrap as an example):

- do initial git pull into grml-debootstrap

  git pull git://git.grml.org/grml-debootstrap master

- Go into grml-debootstrap and start a new branch

  git checkout -b t/my-working-branch

- work on the code, commit, hack, commit, hack, commit -- commit often
& commit small

- when AOK and need to integrate patches into main branch, squash all
patches into one

  git rebase -i origin/master

- send in patches via email (to grml-devel@ml.grml.org)

  git format-patch origin
  git send-email --to grml-devel@ml.grml.org ...

Please correct me if anything above is wrong.

Now, question, having done above, if I start to work some logically unrelated patches, what steps should I take? (I don't want 'git rebase' to pick up patches that I've already sent in).