Updates to fix the nits found during the list discussion.
- Lose PATH_TO_MAN; just rely on execlp() to find whereever the
"man" command is installed.
- Do not randomly chdir(), but concatenate to the current
working directory only if the given path is not absolute.
- Lose use of glob(); read from exec_path and do sorting
ourselves -- it is not that much more work.
Signed-off-by: Junio C Hamano <junkio@cox.net>
It's by design a bit stupid (matching ^git rather than ^git-), so as
to work with 'gitk' and 'git' as well.
Signed-off-by: Andreas Ericsson <ae@op5.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch provides a C implementation of the 'git' program and
introduces support for putting the git-* commands in a directory
of their own. It also saves some time on executing those commands
in a tight loop and it prints the currently available git commands
in a nicely formatted list.
The location of the GIT_EXEC_PATH (name discussion's closed, thank gods)
can be obtained by running
git --exec-path
which will hopefully give porcelainistas ample time to adapt their
heavy-duty loops to call the core programs directly and thus save
the extra fork() / execve() overhead, although that's not really
necessary any more.
The --exec-path value is prepended to $PATH, so the git-* programs
should Just Work without ever requiring any changes to how they call
other programs in the suite.
Some timing values for 10000 invocations of git-var >&/dev/null:
git.sh: 24.194s
git.c: 9.044s
git-var: 7.377s
The git-<tab><tab> behaviour can, along with the someday-to-be-deprecated
git-<command> form of invocation, be indefinitely retained by adding
the following line to one's .bash_profile or equivalent:
PATH=$PATH:$(git --exec-path)
Experimental libraries can be used by either setting the environment variable
GIT_EXEC_PATH, or by using
git --exec-path=/some/experimental/exec-path
Relative paths are properly grok'ed as exec-path values.
Signed-off-by: Andreas Ericsson <ae@op5.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
