Recommended work flow with git to send in patches

[Tong Sun <suntong@cpan.org>]

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).