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

Thanks for 1.6.6!

Junio C Hamano wrote:

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

I can try hacking some internal option into the merge helpers, by
which they declare to be (in)compatible with rebasing.  I think this
what Dscho or Sverre mentioned in the corresponding thread, but I
forgot about it when I noticed you had already promoted the above to
'next'.

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

I think it's not quite as drastic as you make it sound ;-)

But I don't need this feature, and Peff mentioned something about
being happy except for the patch editing mode.  Unfortunately the
above pretty much hits the limits of add--interactive's flexibility,
so an interactive direction toggling feature would need some rewiring.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

On Fri, Dec 25, 2009 at 12:30:34PM +0100, Thomas Rast wrote:

I can try hacking some internal option into the merge helpers, by
which they declare to be (in)compatible with rebasing.  I think this
what Dscho or Sverre mentioned in the corresponding thread, but I
forgot about it when I noticed you had already promoted the above to
'next'.

If you do that, maybe do all relevant flags (such as "no fast forwards"
and "no trivial merging") at the same time. That would allow external
strategies to use those flags.

-Ilari

On Fri, Dec 25, 2009 at 12:30:34PM +0100, Thomas Rast wrote:

quoted

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

I think it's not quite as drastic as you make it sound ;-)

But I don't need this feature, and Peff mentioned something about
being happy except for the patch editing mode.  Unfortunately the
above pretty much hits the limits of add--interactive's flexibility,
so an interactive direction toggling feature would need some rewiring.

Let's drop it for now. I'm reasonably happy, and I don't want to waste
your time trying to do something more invasive. And I haven't seen any
evidence that anybody else is dissatisfied with what's in master.

-Peff