merging special txt files
Steve Borho
steve at borho.org
Tue Oct 19 06:39:16 UTC 2010
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
--
Steve Borho
More information about the Mercurial
mailing list