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