On 27/02/11 23:37, Sebastian Schuberth wrote: > On Sun, Feb 27, 2011 at 06:50, Chris Packham <judge.packham@xxxxxxxxx> wrote: > >>> + ecmerge) >>> + echo guimerge >>> + ;; >>> emerge) >>> echo emacs >>> ;; >> >> I think this is another case of linux/windows versions of the >> application having different executable names. >> >> chrisp@laptop:~> tar -tf Download/ecmerge-2.3.123.linux.x86.tbz >> /usr/local/bin/ecmerge >> /opt/elliecomputing/ecmerge/guimerge >> /opt/elliecomputing/ecmerge/guimerge.exe > > Indeed, well except that Linux has both "ecmerge" and "guimerge", > whereas Windows only has "guimerge", which is why I went with the > latter. Giving it a second thought, my patch is a little inconvenient > for Linux users, as it will stop making ecmerge work out of the box > (without first setting mergetool.ecmerge.path), whereas Windows users > need to set mergetool.ecmerge.path anyway. > > I've also contacted the makers of ECMerge and asked them to unify the > naming across platforms. Maybe we should just drop this patch until > they did. > > Chris, what do you think? If the ecmerge makers can get 'ecmerge' to be a valid command on windows then that'd be the best solution for now. I have a different idea for handling this going forward (maybe for v1.8.0). One benefit of having built-in knowledge of a mergetool, as opposed to using config variables, is git knows when to do a 2-way merge vs a 3-way merge. So instead of having a single mergetool.cmd maybe we need mergetool.cmd2way and mergetool.cmd3way, all of the existing supported mergetools could then be expressed as a set of config variables (maybe installed in system or global configs by the git installation process). I'll try to write that up as a proper v1.8.0 proposal when I get a chance. -- 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