author | Andreas Ericsson <exon@op5.se> | |
Tue, 15 Nov 2005 23:31:25 +0000 (00:31 +0100) | ||
committer | Junio C Hamano <junkio@cox.net> | |
Wed, 16 Nov 2005 00:02:57 +0000 (16:02 -0800) | ||
commit | 8e49d50388211a0f3e7286f6ee600bf7736f4814 | |
tree | f28dc659b25e44f228ffbe560ad2040718d34050 | tree | snapshot |
parent | c0bbbb1ba93154e31f05eab69fee70006fe7acb2 | commit | diff |
C implementation of the 'git' program, take two.
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>
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>
Makefile | diff | blob | history | |
git.c | [new file with mode: 0644] | blob |
git.sh | [deleted file] | blob | history |