[PATCH RFC] update: add an option to allow to merge local changes when crossing branches

Laurens Holst laurens.nospam at grauw.nl
Fri Feb 22 07:24:54 CST 2013

Op 22-02-13 13:26, Angel Ezquerra schreef:
> On Fri, Feb 22, 2013 at 11:22 AM, Gilles Moris <gilles.moris at free.fr> wrote:
>> # HG changeset patch
>> # User Gilles Moris <gilles.moris at free.fr>
>> # Date 1361528509 -3600
>> # Node ID 567106adefd309717d8f0538197dc7dde45d34f1
>> # Parent  013fcd112f13f31a35ea6a40d8cd1c6923cdaf20
>> update: add an option to allow to merge local changes when crossing branches
>> Normally, it is not possible to update to another branch with local changes.
>> One have to use "hg update --clean" to discard changes and force the update.
>> One workaround is to update to the common ancestor of the branches, and then
>> to the other branch. This workaround is not well known by users.
>> I introduce an update --merge option that enables to rebase the local changes
>> in one step.
>> However, I have still some questions about how to design it:
>> I/ option naming
>> * I used --merge as it seems pretty but though could be confused with
>>    changesets merge
>> * --rebase could be used, may be ,ore accurate, but IMO too tied to the rebase
>>    extension
>> * --crossbranches would not be a good idea, as we probably don't want to allow
>>    crossing branches if a revision is not explicitely provided, whether there
>>    are some local changes or not
>> * other possibilities: --reseat, --move, ...
>> * last possibility: no option, allow by default to merge local changes, we've
>>    got --check if we want to block. By the way, this would greatly simplify both
>>    the code and the help content. The help content is currently partially lying:
>>      "If the changeset is not a descendant or ancestor of the working
>>       directory's parent, the update is aborted."
>>    Was true before, but since many releases we allow to cross branch for clean
>>    working directory and an explicit release.
>>      "-c --check     update across branches if no uncommitted changes"
>>    Again wrong, this option aborts on any dirty working dir, whether we cross
>>    branches or not.
>>    So no option might be more consistent with the evolution of the CLI.
> What about --force? It would let you do an update where the regular
> update would not let you...

I’m not entirely clear why this isn’t the default? Any update with local 
changes is performing a merge anyway (with all its risks for conflicts), 
so why would updating across branches need to be prohibited? It’s just a 
matter of setting base to the common ancestor instead of working copy 
parent, right?


More information about the Mercurial-devel mailing list