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@xxxxxxxx> Date: Sun, Jun 6, 2010 at 8:56 PM Subject: Working with git and sending in patches To: grml-devel@xxxxxxxxxxx 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@xxxxxxxxxxx) git format-patch origin git send-email --to grml-devel@xxxxxxxxxxx ... 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). -- 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