merging special txt files

[Steve Borho]

On Tue, Oct 19, 2010 at 11:51 PM, TK Soh <teekaysoh at gmail.com> wrote:
> On Tue, Oct 19, 2010 at 2:39 PM, Steve Borho <steve at borho.org> wrote:
>> On Tue, Oct 19, 2010 at 1:27 AM, TK Soh <teekaysoh at gmail.com> wrote:
>>> On Tue, Oct 19, 2010 at 12:00 PM, Steve Borho <steve at borho.org> wrote:
>>>> On Mon, Oct 18, 2010 at 7:00 PM, TK Soh <teekaysoh at gmail.com> wrote:
>>>>> On Tue, Oct 19, 2010 at 7:36 AM, TK Soh <teekaysoh at gmail.com> wrote:
>>>>>> On Sun, Oct 17, 2010 at 1:56 AM, Steve Borho <steve at borho.org> wrote:
>>>>>>> On Sat, Oct 16, 2010 at 2:53 AM, TK Soh <teekaysoh at gmail.com> wrote:
>>>>>>>> On Sat, Oct 16, 2010 at 12:37 PM, TK Soh <teekaysoh at gmail.com> wrote:
>>>>>>>>> On Sat, Oct 16, 2010 at 11:53 AM, Steve Borho <steve at borho.org> wrote:
>>>>>>>>>> On Fri, Oct 15, 2010 at 10:37 PM, TK Soh <teekaysoh at gmail.com> wrote:
>>>>>>>>>>> On Fri, Oct 15, 2010 at 7:09 PM, Mads Kiilerich <mads at kiilerich.com> wrote:
>>>>>>>>>>>> On 10/15/2010 06:31 AM, TK Soh wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> One thing I can think of is to add a --merge-tool option to 'hg
>>>>>>>>>>>>> resolve'. In my case, most the time the merge will result in conflicts
>>>>>>>>>>>>> (or I can perhaps fake one if necessary), so I can then try resolve
>>>>>>>>>>>>> the conflict using the custom merge tool via --merge-tool option. To
>>>>>>>>>>>>> me this option sound like a reasonable one, since most conflict
>>>>>>>>>>>>> probably mean the default (pre-configured) tools are not able to
>>>>>>>>>>>>> handled it, and hence another tool or solution is required.
>>>>>>>>>>>>
>>>>>>>>>>>> It is already possible with
>>>>>>>>>>>>  HGMERGE=tool hg resolve file
>>>>>>>>>>>> or
>>>>>>>>>>>>  hg resolve --config ui.merge=tool file
>>>>>>>>>>>
>>>>>>>>>>> This is actually what I am doing already. But it's clumsy and only
>>>>>>>>>>> possible on command line (a significant of our users are on Windows)
>>>>>>>>>>>
>>>>>>>>>>>> A mere elegant syntax could however be nice.
>>>>>>>>>>>
>>>>>>>>>>> Indeed. But ultimately I'd like to see something more flexible,
>>>>>>>>>>> including a way to allow user to select the merge tool via some
>>>>>>>>>>> configurable mean and/or interactively. Perhaps the TortoiseHg team
>>>>>>>>>>> can work out something magical.
>>>>>>>>>>
>>>>>>>>>> I'm working on a patch that adds --tool arguments to merge and
>>>>>>>>>> resolve.  With any luck it will make it into 1.7.
>>>>>>>>>
>>>>>>>>> hg resolve works on files, so the --tool args will have a more
>>>>>>>>> meaningful use. I wonder how it help on hg merge, which does not
>>>>>>>>> operate on files.
>>>>>>>>>
>>>>>>>>>> TortoiseHg has supported a similar feature for ages.  You just need to
>>>>>>>>>> make the initial merge fail (setting ui.merge = internal:fail in your
>>>>>>>>>> config is the canonical way).  Then from the commit tool you can chose
>>>>>>>>>> any detected merge tool to resolve each file, via the file's context
>>>>>>>>>> menu.
>>>>>>>>>
>>>>>>>>> I'll take a look. But offhand making the merge fail (on all files)
>>>>>>>>> using ui.merge = internal:fail isn't very practical, since only some
>>>>>>>>> (in my case, only a small number of them) files require special merge
>>>>>>>>> tool.
>>>>>>>>
>>>>>>>> I just did a quick trial. Pretty nice. At least it should serve my
>>>>>>>> purpose for now. I wonder if you use the ui.merge trick also, or
>>>>>>>> something more interesting.
>>>>>>>
>>>>>>> Last I looked, it actually used the HGMERGE environment variable.
>>>>>>
>>>>>> Looks like hgtk commit tries to execute the command name directly,
>>>>>> instead of using the the value defined in .executable. This causes an
>>>>>> issue since my custom Perl script comes with a .pl extension. And I
>>>>>> can't add the .pl extension into the command name in merge-tools
>>>>>> key-value pairs.
>>>>>
>>>>> I manage to work around it with this the patch below. Not sure if I
>>>>> miss anything:
>>>>
>>>> Ah, right.  HGMERGE bypasses the normal merge-tools tool detection
>>>> machinery so your patch is correct.  Very timely, I need to revisit my
>>>> --tool patch.
>>>>
>>>>> # HG changeset patch
>>>>> # User TK Soh <teekaysoh at gmail.com>
>>>>> # Date 1287444370 -28800
>>>>> # Branch stable
>>>>> # Node ID 308e0552cb4d2e9d62816ca84726328aa6daca3b
>>>>> # Parent  d61c318a9e0aa6ee23e0fcbc9e38ebb5f5dccaad
>>>>> commit: respect merge-tools' .executable settings
>>>>>
>>>>> diff --git a/tortoisehg/hgtk/status.py b/tortoisehg/hgtk/status.py
>>>>> --- a/tortoisehg/hgtk/status.py
>>>>> +++ b/tortoisehg/hgtk/status.py
>>>>> @@ -15,7 +15,7 @@
>>>>>  import threading
>>>>>
>>>>>  from mercurial import cmdutil, util, patch, error, hg
>>>>> -from mercurial import merge as merge_
>>>>> +from mercurial import merge as merge_, filemerge
>>>>>
>>>>>  from tortoisehg.util.i18n import _
>>>>>  from tortoisehg.util import hglib, paths, hgshelve
>>>>> @@ -1211,8 +1211,9 @@
>>>>>             self.reload_status()
>>>>>         def resolve_with(stat, tool, files):
>>>>>             if tool:
>>>>> +                exe = filemerge._findtool(self.repo.ui, tool)
>>>>>                 oldmergeenv = os.environ.get('HGMERGE')
>>>>> -                os.environ['HGMERGE'] = tool
>>>>> +                os.environ['HGMERGE'] = exe
>>>>>             resolve(stat, files)
>>>>>             if tool:
>>>>>                 if oldmergeenv:
>>>>>
>>>>
>>>> Pushed, thanks.
>>>
>>> Thanks. When will the nightly build pick up this change. I need the
>>> Windows installer.
>>
>> Tomorrow
>
> Looks like the nightly build only comes with Qt package. Does it come
> with the fix on .executable also? And the hgtk version is not
> available?
>

hgtk nightlies have always been at:
http://bitbucket.org/tortoisehg/thg-winbuild/downloads

The Qt port doesn't use HGMERGE.  In fact I have a queued patch that
uses the new tool argument to resolve.

-- 
Steve Borho