David Aguilar, 03.05.2009: > Markus Heidelberg <markus.heidelberg@xxxxxx> wrote: > > David Aguilar, 02.05.2009: > > > I installed ecmerge on a mac today and gave this a try. > > > ecmerge is indeed better with this patch. > > > > > > After configuring the path it all "just works": > > > > > > $ git config --global mergetool.ecmerge.path \ > > > /Applications/ECMerge.app/Contents/MacOS/guimerge > > > > Would it make sense to set merge_tool_path to guimerge by default then? > > > > Markus > > On Linux, ecmerge is "ecmerge". > Macs are weird. Windows--even worse. And the ecmerge developers are even more worse or is there a reason to have different names for the binaries? > We could test $(uname) = "Darwin" and do the user-friendly thing by default, > but that might not be a good idea. Or use "type" there already to test whether guimerge exists, else default to ecmerge. > The user-friendly thing is actually > "/Applications/...lots.of.stuff.../guimerge", and that's a lot more > platform-specific than just "guimerge". Why is the whole path more user friendly, because of guimerge not being in PATH? Is the /Applications/... directory always the same for ecmerge for each Mac user? But we don't care in other diff/merge tools about the exact location and I think we shouldn't begin it here. > The usability fairy says we should be nice to users and turn > translate_merge_tool_path() into a massive platform-specific > hack. The lazy person in me would rather list the tweaks > on the git wiki and silently reward linux users since > the defaults work fine there as-is. > > What do you think? Not sure, leaving it as is is still an option. -- 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