[PATCH 3 of 3] rebase: prevent creating divergence

Laurent Charignon lcharignon at fb.com
Tue Jan 12 13:06:22 CST 2016


On Jan 6, 2016, at 11:32 AM, Martin von Zweigbergk <martinvonz at google.com<mailto:martinvonz at google.com>> wrote:


On Wed, Jan 6, 2016 at 11:05 AM Laurent Charignon <lcharignon at fb.com<mailto:lcharignon at fb.com>> wrote:
# HG changeset patch
# User Laurent Charignon <lcharignon at fb.com<mailto:lcharignon at fb.com>>
# Date 1452106972 28800
#      Wed Jan 06 11:02:52 2016 -0800
# Node ID d485b9498a154777904c3b3dee56daa0bdc79527
# Parent  b237d9ad188bfffd8a42a8ace3fd1558a95ad2b3
rebase: prevent creating divergence

Before this patch rebase would create divergence when you were rebasing obsolete
changesets on a destination not containing one of its successors.
This patch introduces experimental.rebaseallowdivergence to explicitly allow
divergence creation with rebase.

Why is the config option in [experimental]? If we think preventing divergence is right, then shouldn't this be in [rebase] or something? If we are not sure if it's right, it seems like the default should be True, so users have to opt in to the safer behavior. It seems odd to force users to enable an experimental option. But perhaps we are quite sure we want to fail when there is divergence, and it's the existence of the config option that's experimental? I.e. we want to give ourselves the freedom to remove the config option later?

You are definitely right, I will make it permanent by moving it to 'rebase' instead. I believe that the default should be 'False' because we want users to opt out for the riskier behavior.

Thanks!

Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20160112/1f964ea4/attachment.html>


More information about the Mercurial-devel mailing list