Branch shuffling after 1.6.6 release plans

Here is a list of short-term branch shuffling I plan to do.

 - Kick a few topics back to 'pu'.  They were merged to 'next' in the hope
   of them either getting discussed to form a consensus or perfected, but
   they ended up in limbo for a long time without progress (pre-release
   freeze didn't have any impact on them),

   This involves applying a few reverts directly on top of 'next', which
   I've already done privately.  People _could_ vote to bring them back by
   working on perfecting them and/or discussing them to reach concensus.

     * je/send-email-no-subject (2009-08-05) 1 commit
      - send-email: confirm on empty mail subjects

     The existing tests cover the positive case (i.e. as long as the user says
     "yes" to the "do you really want to send this message that lacks subject",
     the message is sent) of this feature, but the feature itself needs its own
     test to verify the negative case (i.e. does it correctly stop if the user
     says "no"?)

     * tr/maint-merge-ours-clarification (2009-11-15) 1 commit
      - rebase: refuse to rebase with -s ours

     I do not think we reached a concensus for solving conflicts between "give
     them rope" and "protect users from clearly meaningless combinations".  The
     author obviously is for the latter (and I am inclined to agree); Dscho
     seems to think otherwise.

     * tr/reset-checkout-patch (2009-11-19) 1 commit
      - {checkout,reset} -p: make patch direction configurable

     I do not particularly like a configuration like this that changes the
     behaviour of a command in a drastic way---it will make helping others
     much harder.

 - Graduate the following topics to 'master':

     * sr/vcs-helper (2009-12-07) 14 commits
     * jc/1.7.0-send-email-no-thread-default (2009-08-22) 1 commit.
     * jc/1.7.0-push-safety (2009-02-09) 2 commits.
     * jc/1.7.0-diff-whitespace-only-status (2009-08-30) 4 commits.
     * gb/1.7.0-diff-whitespace-only-output (2009-11-19) 1 commit

   Also possibly:

     * jk/1.7.0-status (2009-12-11) 16 commits
     * jc/1.7.0-status (2009-09-05) 4 commits

   For these topics, we would need to decide what to do with the
   "submodule summary" stuff in the --porcelain format output, which we
   promised will never change in the documentation.  My current thinking
   is to keep the current code and don't show anything; Porcelains can
   choose to run "git log" inside submodule directories if they so desire.

 - Rebuild 'next' on top of the updated 'master' with remaining topics.

   I actually won't do this step before the new year, so that people who
   based their topics on 'next' can still fast-forward, but with many
   topics for 1.7.0 graduating this week to 'master' hopefully it would be
   easier for them to rebase on top of 'master'.