Making rebase --detach the default

[Joshua Redstone]

+1 for making --detach the default.  I just got bitten by the forgetting
of --detach yesterday.

Would it help ease the pain of switching the default if we temporarily add
a warning msg to rebase that is printed when the semantics of the
operation have changed because of the default switch?

Josh

On 5/11/12 3:45 PM, "Pierre-Yves David" <pierre-yves.david at ens-lyon.org>
wrote:

>At the sprint we talked about making 'rebase --detach' the default
>behavior.
>
>Matt ask some archeology about initial design, here is some.
>
>
>TL;DR; This behavior seems to have been picked because it was simple to
>       implement and nobody objected again it.
>
>
>(1) The default behavior is explained here:
>http://mercurial.selenic.com/wiki/RebaseExtension#rebase_G_onto_I
>
>(2) The --detach flag is discussed in issue1950. Where Matt say: "rebase
>can't currently handle that,"
>
>    http://mercurial.selenic.com/bts/issue1950#msg11237
>
>(3) In the initial discussion about the rebase Gsoc:
>
>    (a) Here parren says:
>http://selenic.com/pipermail/mercurial-devel/2008-March/005533.html
>
>        >  echo -e "\n-- User a wants to cherry-pick just the Y-feature"
>        >  # Something like:
>        >  # cd $BASEDIR/user_a
>        >  # hg rebase user_b -r 2
>
>        This would probably be "hg transplant" rather than rebase, but
>with
>        transplant augmented to do proper three-way merge. This is part of
>        what your work would encompass.
>
>    (b) Here patrick says:
>http://selenic.com/pipermail/mercurial-devel/2008-March/005535.html
>
>        I would not focus too much about cherry-picking in the beginning,
>a
>        working branch rebasing command looks like a good first milestone
>to
>        me.
>
>    (c) Here stephano schedule the "cherry-picking case" as the last part
>of his gsoc:
>
>        
>http://selenic.com/pipermail/mercurial-devel/2008-March/005551.html
>
>
>(4) In first discussion during the gsoc:
>
>    Andrei Vermeil says:
>http://selenic.com/pipermail/mercurial-devel/2008-May/006341.html
>
>        Rebasing a merge changeset is probably only worth the trouble if
>it gets 
>        rebased together with it's ancestors.
>
>    (but we are not talking about merge there)
>
>
>(5) There is a lot of email that talk about "nested revision" but with
>links to
>    the old gsoc pages which is now dead.
>
>
>Conclusion
>--------------
>
>I did not find any killing argument for the default behavior.  I couldn't
>find
>any real discussion on the topic either. The main reason for the current
>default behavior seems to be that is was much more easy to implement.
>--detach behavior was initially planned but delayed.
>
>
>I +1 for making --detach the default after 3 years of confusing people to
>death.
>
>As a bonus, it would match the Git behavior.
>
>
>-- 
>Pierre-Yves David
>
>http://www.logilab.fr/
>
>_______________________________________________
>Mercurial-devel mailing list
>Mercurial-devel at selenic.com
>http://selenic.com/mailman/listinfo/mercurial-devel