Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

can't open external merge tool

Paul Wirth June 17, 2012

Using Lion, I have no problems running opendiff from the terminal. But choosing "Launch External Merge Tool" from Sourcetree shows me a brief window notifying me that I'll need to quit the external merge tool to complete the merge process, then the window closes and the merge tool is never launched.

4 answers

1 accepted

1 vote
Answer accepted
stevestreeting
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
June 17, 2012

My guess is you've updated your PATH to find opendiff so it works from the terminal, but PATH is not used by GUI apps in OS X.

Please refer to this KB article which should solve your problem: https://confluence.atlassian.com/pages/viewpage.action?pageId=267258218

Paul Wirth June 17, 2012

Still no go. I added

/Developer/usr/bin

to /etc/paths and I added

export PATH=${PATH}:/Developer/usr/bin

to ~/.bash_profile

Still the same problem

stevestreeting
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
June 17, 2012

Did you restart as per the notes? Also, the first option (symlinking) is faster.

Paul Wirth June 17, 2012

I'm re-installing developer tools just in case that helps. Any ideas are welcome. Thanks.

stevestreeting
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
June 17, 2012

Hmm, that's odd then - if it's in /usr/bin it should work (that will have been from a previous install). You can make sure that works by calling /usr/bin/opendiff manually, and if it doesn't work, remove it and symlink to the newer one instead.

Otherwise, you could check your ~/.gitconfig to make sure that opendiff is being used there (assuming this is git)

Paul Wirth June 17, 2012

Yes, I restarted. On my mac, opendiff exists (not a symlink) at both locations (/usr/bin and /Developer/usr/bin) so terminal refused to symlink from one to the other. The opendiff in /Developer/usr/bin is from May 2011. The one in /usr/bin is from December 2011. Strange.

Paul Wirth June 17, 2012

running /usr/bin/opendiff manually works. ~/.gitconfig has these lines:

[difftool "sourcetree"]

	cmd = opendiff \"$LOCAL\" \"$REMOTE\"

	path = 

[mergetool "sourcetree"]

	cmd = /Applications/SourceTree.app/Contents/Resources/opendiff-w.sh \"$LOCAL\" \"$REMOTE\" -ancestor \"$BASE\" -merge \"$MERGED\"

	trustExitCode = true

and the opendiff-w.sh file within the Sourcetree app path has the following:

#!/bin/sh

opendiff "$@" | cat

Paul Wirth June 17, 2012

by the way, external diff works fine. it's just external merge that won't run.

1 vote
agravier July 24, 2016

The issue on my machine was that the `opendiff` utility was confused by some misconfiguration of XCode. It looked like that:

 

$ opendiff
xcode-select: error: tool 'opendiff' requires Xcode, but active developer directory '/Library/Developer/CommandLineTools' is a command line tools instance

The solution was to run 

$ sudo xcode-select -s /Applications/Xcode-beta.app/Contents/Developer

Replace /Applications/Xcode-beta.app by your XCode path, of course

 

0 votes
Tommy K January 2, 2015

One cause of this problem is that SourceTree fails to quote the path to the opendiff-w.sh helper script, which in my case is at ~/Library/Application Support/SourceTree/...

The space between Application and Support causes SourceTree to fail to launch the helper.

In my .gitconfig, I manually added \" surrounding the path-to-helper part, and things are back to working for me.

YMMV?

0 votes
stevestreeting
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
June 17, 2012

Hmm, that all looks fine, and if the External Diff is working then SourceTree can see opendiff OK.

I just ran a couple of tests here and merging with FileMerge is working for me on 1.4.4.x both on merge conflicts and rebase conflicts. Can you give some more detail on the file that's being merged? Is it possible that there's actually nothing that needs merging? Git will not bother to launch the tool if so.

Paul Wirth June 17, 2012

Thanks Steve. I'm new to Git, using it to develop a wordpress site. Perhaps I'm doing something wrong.

In essence, I'm trying to resolve conflicts after a merge using the external merge tool.

In more detail, here's the path I've taken as a Git novice trying to merge with conflicts: I merged one branch into another, and wound up with about 19 conflicts. I started sifting through the conflicts using the Sourcetree GUI, discarding and staging changes, but staged changes created artifacts like this: "<<<<<<< HEAD" in the files. After a lot of googling, I found no answer as to why I should have to remove these by hand, and so I'm running on the assumption that using the external merge tool won't leave these artifacts.

Any advice would be appreciated. Thank you for replying so promptly.

stevestreeting
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
June 17, 2012

That's right - the 'chevrons' are there to indicate conflicts, and you can edit the files manually to remove the conflicts (basically the section between <<<<<< and ======== is one side, then from ======== to >>>>>>> is the other), subsequently using 'Mark resolved' to indicate you've fixed the conflict, or you can use an external merge tool to get a more user-friendly view of it.

I've never seen this fail for FileMerge when the tool is correctly launchable so I'm short of ideas now - the presence of the chevrons indicates there is in fact something to resolve. Again I've tested this here with a merge conflict and rebase conflict and all is as expected.

Just one thing to check: in Preferences is the box "Allow SourceTree to modify your global Mercurial and Git files" checked? Your .gitconfig indicates it was checked at one point, but if it's been unchecked since then then SourceTree assumes you've configured the external merge tools yourself.

If it is checked, you might get more information by running this on the command line:

git mergetool -y --tool=sourcetree -- filename

Paul Wirth June 17, 2012

Okay, I tried that command with a file that had a conflict and this is what I got back (I replaced the long path in the response with /path/to)

Normal merge conflict for 'footer.php':
  {local}: created
  {remote}: created
2012-06-18 09:57:31.848 opendiff[16037:c07] /path/to/footer.php.BASE.15978.php does not exist

The command created an edited footer.php and a footer.php.orig. It didn't launch anything, and running the command took footer.php out of the conflicts list in Sourcetree.

Sourcetree also creates a new copy and an original copy when i try to use the external merge tool, but then nothing happens and the file stays in the conflicts list.

Also, does using the external merge tool make it easy to get rid of all the chevron markers or does that still have to be done manually? Seems tedious.

Paul Wirth June 17, 2012

One added piece of info, Steve: I don't know if it's normal but every time I click resolve using external merge tool, console produces a message like this:

opendiff: /path/to/footer.php.BASE.30697.php does not exist

Just like I got with the terminal command you suggested.

stevestreeting
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
June 17, 2012

Yes, the external merge tool means you don't have to deal with the chevrons yourself. Some people like to just resolve these things with a text editor though, which is why they're there.

About the 'does not exist' error, at least I know this isn't a SourceTree problem then since naked git does it too. This usually only happens if one side of the merge doesn't exist, which might be because one or other side of the merge deleted it, or perhaps moved the file. While git does try to be sensible with renamed files, merges often can't handle files moving around very easily, it's usually best to avoid them. You may have to resolve this case manually if that's the issue, but it's worth noting that this is not a commonplace occurrence, usually the visual merge is very easy to use to resolve this.

Paul Wirth June 17, 2012

Thanks for working through this with me, Steve. You're right: I set up a little test repo and had no problem launching the external merge tool.

Any thoughts as to why this is happening with the project I'm working with?

stevestreeting
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
June 18, 2012

My guess would be that it's the file itself, either a rename or a deletion on one side of the merge.

Paul Wirth June 18, 2012

thanks, yes, i worked it out. thanks for your help.

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events