merging special txt files
Steve Borho
steve at borho.org
Wed Oct 20 14:49:12 UTC 2010
On Wed, Oct 20, 2010 at 1:16 AM, TK Soh <teekaysoh at gmail.com> wrote:
> On Wed, Oct 20, 2010 at 1:09 PM, Steve Borho <steve at borho.org> wrote:
>> 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
>
> I already am downloading the nightly installer from here.
> Specifically, this is the file I downloaded:
>
> tortoisehg-stable-1.1.41007.41005-x86-0e8707d6-63b3-43cb-ba6b-0fd57c393a69.msi
>
> It comes with Qt package.
Yikes, I've deleted those. I must have built them with the wrong
branch of thg-winbuild.
>> The Qt port doesn't use HGMERGE. In fact I have a queued patch that
>> uses the new tool argument to resolve.
>
> I am not clear what you really mean. Are you saying the Qt port in
> that installer will be able to pick up my custom script the way hgtk
> commit does (after my patch)?
>
The Qt port will, though it may take a bit more work.
--
Steve Borho
More information about the Mercurial
mailing list