merge wizard work
Steve Borho
still has a number of rough edges that I'll be working through over
the next week, but I would like people to make a point to always use
the merge wizard when doing merges, so we can give it some good
testing.
The biggest change I made was to break up the merge into two stages.
The merge command is run with ui.merge=internal:fail. This tells
Mercurial that if there are any files modified on both branches, they
should be marked unresolved instead of trying to run a merge tool
immediately. At the end of the merge, if there are any unresolved
files the wizard switches to a "Resolve" page where the user can
resolve conflicts at their leisure. If there were no conflicts, the
wizard jumps directly to the commit page.
This is similar to the workflow of merges with perforce, and I think
it's one of the few parts of their user interface we should mimic.
Merge tools are only opened at the direct request of the user, and
they have complete control over the resolve process. This interface
exposes the power of the resolve command, in that they can restart the
merge of any file they wish until they get all the files just as they
want them.
The resolve page is designed such that the user can press the 'auto'
button right away to make Mercurial try to do a "simplemerge" of all
unresolved files at once. This will resolve most files, unless there
is a real conflict on one or more lines.
Three known issues:
1 - there's a reference counting issue somewhere in the tool, it can
cause crashes
2 - launching commit from merge, when merge is launched from workbench
causes bad behavior
3 - the cmdui.Widget console will not grow in size in the resolve
page, no idea why
Let me know if you run into any surprising behavior.
--
Steve Borho
James McKay
> The biggest change I made was to break up themergeinto two stages.
> should be marked unresolved instead of trying to run amergetool
> resolve conflicts at their leisure. If there were no conflicts, the
> wizard jumps directly to the commit page.
>
> This is similar to the workflow of merges with perforce, and I think
> want them.
Team Foundation Server works the same way, and while I can see that
there are advantages to this approach, I'm a bit concerned about
making it the only option. Up to now, the Mercurial workflow has been
the same as with Git and Subversion: automatically merge everything as
far as possible, and only bring up a conflict dialog when the merge
algorithm can't proceed any further. While the TFS/Perforce approach
will be more reassuring to people used to that workflow, I worry that
it might prove to be a big turn-off to Subversion and Git users, and
even many existing Mercurial users, for whom this will be a fairly big
breaking change in their workflow and quite possibly viewed as a step
backwards. From a marketing perspective, we could well be scoring an
own goal here.
My suggestion is to give users the choice which strategy to adopt on
the first screen of the merge wizard: I'd prefer to see the git/hg/svn
approach being the default. That way we get the best of both worlds.
I've pushed a change to implement this to http://bitbucket.org/jammycakes/thg/changeset/ac8ab0561087
Steve Borho
I'll allow that long-time Mercurial users may find this limiting, so
I've assumed that we'll eventually add a back door to revert to
default Mercurial behavior. But I have heard from many new users over
the years that this is the one part of the Mercurial interface that is
unsettling, having kdiff3 thrown at them at seemingly random
occasions, so I want the internal:fail approach to be the initial
default.
How about a new boolean setting: tortoisehg.autoresolve - set to True
to get Mercurial's default behavior. Rather than toggling between
internal:fail and internal:merge, this switch should remove the --tool
argument entirely, allowing Mercurial to use ui.merge and all the rest
of its tool selection machinery.
There are more dialogs that would need to be aware of this switch
(rebase, sync, update, backout).
--
Steve Borho
André Sintzoff
I agree with you. Most of the new users I know are somehow disturbed
by the "old" merge behaviour.
When I show them the "new" behaviour, they are enthusiast.
> How about a new boolean setting: tortoisehg.autoresolve - set to True
> to get Mercurial's default behavior. Rather than toggling between
> internal:fail and internal:merge, this switch should remove the --tool
> argument entirely, allowing Mercurial to use ui.merge and all the rest
> of its tool selection machinery.
Good idea.
> There are more dialogs that would need to be aware of this switch
> (rebase, sync, update, backout).
André
James McKay
> > I'll allow that long-time Mercurial users may find this limiting, so
> > I've assumed that we'll eventually add a back door to revert to
> > default Mercurial behavior. But I have heard from many new users over
> > the years that this is the one part of the Mercurial interface that is
> > unsettling, having kdiff3 thrown at them at seemingly random
> > occasions, so I want the internal:fail approach to be the initial
> > default.
>
> I agree with you. Most of the new users I know are somehow disturbed
> by the "old" merge behaviour.
> When I show them the "new" behaviour, they are enthusiast.
>
> > How about a new boolean setting: tortoisehg.autoresolve - set to True
> > to get Mercurial's default behavior. Rather than toggling between
> > internal:fail and internal:merge, this switch should remove the --tool
> > argument entirely, allowing Mercurial to use ui.merge and all the rest
> > of its tool selection machinery.
>
> Good idea.
>
> > There are more dialogs that would need to be aware of this switch
> > (rebase, sync, update, backout).
>
> André
usability testing behind this.
Just to clarify: I too am enthusiastic about the new conflict
resolution dialog box. It's one of the few features of Team Foundation
Server's source control that I actually like, and I'm glad that we're
going to be getting something like that for Mercurial. It does make
conflict resolution much easier and much less disconcerting than the
existing TortoiseHg behaviour.
I'm also fine about having the option to merge everything manually if
they so desire. I have a colleague who absolutely refuses to use TFS's
"auto merge" feature and insists on bringing up the diff tool every
time. Also, there are times when I'd prefer to do it this way myself,
especially on more complex merges.
What I was asking for though was the ability to choose to auto-resolve
all files at the outset of the merge. That's why I implemented an
alternative with a couple of radio buttons, though a single check box
would do just as well. For simple merges when both branches have
edited the same file but you know beforehand there aren't any
conflicts (perhaps the majority of the merges that I do), being told
that there are conflicts is something of an irritation. It could be
even more annoying on the rebase wizard where you're likely to find
the conflict resolution dialog thrown up repeatedly.
I'm less enthusiastic about the configuration setting approach, since
that doesn't give you the option to choose between the two
alternatives on a case by case basis: it makes it an all-or-nothing
affair. Having said that, if the configuration setting had a "choose"
option, I'd be happy with that.
I've also encountered a few bugs in the merge and file resolution
dialogs -- I'll send some patches for these separately over the next
few days as and when I get the time to look at them.
Steve Borho
I'm fine with a checkbox or radio on the merge page so long as it
reads the default value from the configuration setting - and we use
the configuration setting in the other dialogs that need it.
> I've also encountered a few bugs in the merge and file resolution
> dialogs -- I'll send some patches for these separately over the next
> few days as and when I get the time to look at them.
Great, thanks.
--
Steve Borho
James McKay
> I'm fine with a checkbox or radio on the merge page so long as it
> reads the default value from the configuration setting - and we use
> the configuration setting in the other dialogs that need it.