On Wed, Oct 28, 2009 at 2:36 AM, David Aguilar <davvid@xxxxxxxxx> wrote: > I tested on 10.5, so there's definitely some difference in > behavior since difftool.p4merge.path is all that was needed here > (with an absolute path as I mentioned). There are two issues here: 1) Is it necessary to use launchp4merge, or is calling p4merge directly okay: Calling p4merge directly works, but the advantage of calling launchp4merge instead is that it works a little more elegantly: - If p4merge is already running, using launchp4merge opens a new window inside the running instance, instead of launching p4merge anew. - After performing the merge, it is sufficient to just close the merge window, as opposed to having to quit the p4merge application (which you have to do if you run p4merge directly). 2) Does p4merge/launchp4merge require absolute paths for its arguments. I found that it does. So I wonder whether possibly you tested with difftool, which uses absolute arguments, as opposed to mergetool, which uses relative arguments. You'd only see the issue with mergetool. > We've stayed away from hard-coding any platform-specific paths > in mergetool--lib in the past. It's a practicality thing -- > trying to guess all of the possible installation locations is > simply untenable. > > Here's an old thread where we talked about this in the context > of ecmerge: > > http://thread.gmane.org/gmane.comp.version-control.git/118125/focus=118182 > > Let me know what you think. Disagree with the conclusion of that thread. On Linux, PATH is very likely to have the merge/diff binary in it. On OS X, this is highly unlikely, but there are two very common/likely locations we can look, /Applications and $HOME/Applications. j. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html