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

Gilles Moris gilles.moris at free.fr
Fri Feb 22 08:54:18 CST 2013


On Friday 22 February 2013 02:27:08 pm Laurens Holst wrote:
> 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
>

I think the rationale is that there are more probabilities to run into 
conflicts when jumping to another branch. This is questionable though, as if 
you are going far back in the past, the risk of conflicts is even higher, but 
you are allowed as this is linear.
And I am not aware of any way to abort the merge of a working directory once 
started. If you screwed your merge, you're done.

So I would rather be consistent and be able to always merge local changes by 
default as you said, and find a way to abort and revert a merge of the 
working directory. May be saving the current changes in an .hg/undo.update 
file before updating...

Regards.
Gilles.


More information about the Mercurial-devel mailing list