[PATCH RFC] update: prevent merge of files with uncommitted changes (issue4404)

Matt Mackall mpm at selenic.com
Fri Jun 17 16:40:58 EDT 2016


On Tue, 2016-06-14 at 15:28 +0200, Denis Laxalde wrote:
> # HG changeset patch
> # User Denis Laxalde <denis.laxalde at logilab.fr>
> # Date 1465833221 -7200
> #      Mon Jun 13 17:53:41 2016 +0200
> # Node ID 7c0a16bdf21e7228a1843fe5fca3000bb179d309
> # Parent  60621cecc8c53d3a27e9984fb06fefc1f99797b3
> update: prevent merge of files with uncommitted changes (issue4404)

I'm afraid the answer here is no. Changing update's behavior (copied from CVS
and thus literally predating Mercurial itself) is not an option.

HOWEVER, there is a way forward for broken commands:

- implement a new command with a different name with sane behavior
- eventually deprecate (hide) the old command

As it happens, I have an idea for precisely this, which I've been calling the
"goto" command. We can make a bunch of changes:

- aborts if the working copy is dirty
- use --merge to allow a merge or --clean to discard changes
- no need for the confusing --check flag
- allow merging working changes across branches
- no auto-advancing the active bookmark with no args

As a bonus, the common beginner mistake of thinking "update" only goes forward
and then trying to use "revert" to go backwards will probably go away.

As for the "merge-if-trivial" mode (which I agree is useful), I'd prefer to do
that by refactoring the merge code. There are lots of places where we'd like to
do such merges (via --tool, perhaps) and even a few places where we'd like to
ask the question of whether a merge is trivial without touching the working
copy.

-- 
Mathematics is the supreme nostalgia of our time.



More information about the Mercurial-devel mailing list