[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:27:08 CST 2013


Op 22-02-13 14:24, Laurens Holst schreef:
> 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
>>>
>>> *NOT READY FOR INCLUSION*
>>>
>>> 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?

Sorry, I said something stupid there, please ignore that last sentence :).

Anyway, my point is, why can’t it do it this by default.

~Laurens



More information about the Mercurial-devel mailing list