Making rebase --detach the default

Pierre-Yves David pierre-yves.david at ens-lyon.org
Fri May 11 08:45:12 CDT 2012


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/



More information about the Mercurial-devel mailing list