Re: RFC: a plugin architecture for git extensions?

[Jonathan Nieder <jrnieder@gmail.com>]

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.