Problems while merging using the latest beta of TortoiseHg

[Mads Kiilerich]

Steve Borho wrote, On 02/24/2011 03:00 AM:
> On Wed, Feb 23, 2011 at 7:27 PM, Mads Kiilerich<mads at kiilerich.com>  wrote:
>> The merge tool selection will only influence merging of file content, not
>> cases where there isn't two files with content to merge, and not
>> (necessarily) subrepos. That is bad for tools building on top of Mercurial.
>> IIRC Steve has some clever workarounds (his own merge code?) and dreams
>> about making Mercurial more flexible in this area.
>>
>> But since you are asking here I guess the problem is with Mercurial and we
>> can leave TortoiseHg out of the equation?
> We're talking about TortoiseHg 2.0's approach of passing --tool
> internal:fail to all commands that might try file merges (rebase,
> backout, merge, etc) so that Mercurial never attempts file merges on
> the first pass.  Instead the GUI detects unresolved files and launches
> the resolve tool so the user can deal with file conflicts in a
> deliberate and orderly manner.

What do you do with the promptchoices in merge.py and subrepo.py?

>> Sometimes, if .hgsubstate diverged, a merge in the outer repo will perform a
>> merge in the subrepo of the two revisions.
>>
>> That is obviously the right thing to do if the repo is homogeneous across
>> the subrepo borders and subrepos should be as invisible as possible.
>>
>> If the subrepo has a different policy (for example if it is a shared or
>> external repository) then it is probably not the right thing to do.
> I take it that today hg assumes that the former is always the case?

Yes - mercurial/subrepo.py:134/465

/Mads