Jon Seymour wrote: > Partly because that is second guessing &/or reverse engineering the > distribution's decisions and Well, no --- that's what /usr/local is _for_: http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY > it won't work for a Windows install where there is no /usr/local That's true. I believe command-line users on Windows who install by unzipping to a directory are used to having to set a PATH for themselves. Perhaps it would be convenient for git to learn to add a specific standard directory to its private PATH as a Windows-specific extension, though. If your goal is to make installing new commands for git easier than installing native apps --- why? It seems backwards. Consider that the end result ought to be easy not only for the app developer but for the end user, and if every program with the ability to call other programs sets up its own better replacement for standard operating system facilities, that will make for a complicated system to administer indeed. So with that in mind, it might be simpler to take advantage of existing project that simplifies installation of native apps, like <http://zero-install.sourceforge.net/>. The development environment for git on Windows (mysgit) does provide a directory hierarchy complete with /usr et al, so people using that very well might want to install to /usr/local. Likewise with Cygwin. > Not that I currently, have a need, but Junio did mention the case > where someone wants to enhance an existing git command with a wrapper > of some kind. For reasons you've hinted at before, Git deliberately does not allow that (similarly, it does not allow git aliases to override existing commands). $GIT_EXEC_PATH comes first on the PATH that git uses internally. That's a feature, not a bug, imho. -- 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