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.
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
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Did you restart as per the notes? Also, the first option (symlinking) is faster.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I'm re-installing developer tools just in case that helps. Any ideas are welcome. Thanks.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
by the way, external diff works fine. it's just external merge that won't run.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
My guess would be that it's the file itself, either a rename or a deletion on one side of the merge.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.