Since Git 1.6.0 and later is heading towards moving the dash form
of commands out of the user's $PATH and into the libexec directory
we may not have 'git-upload-pack' or 'git-receive-pack' in $PATH
when the JRE tries to startup C Git for a local transport.  Instead
we should use the git wrapper, as it can select the right libexec
directory and start the correct helper program, or perform the task
internally if it is a builtin command.

In the future we should eliminate this reliance on C Git for any
sort of local transport operation.  We have direct filesystem IO
available to read from the source repository, so there is little
execuse for us to be invoking C Git for this special case.  Until
we fix it, we should at least try to ensure it works for any user.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
 .../org/spearce/jgit/transport/TransportLocal.java |   25 ++++++++++++++++---
 1 files changed, 21 insertions(+), 4 deletions(-)

diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/TransportLocal.java b/org.spearce.jgit/src/org/spearce/jgit/transport/TransportLocal.java
index b112267..b41d4af 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/transport/TransportLocal.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/TransportLocal.java
@@ -59,13 +59,15 @@ import org.spearce.jgit.util.FS;
  * process.
  */
 class TransportLocal extends PackTransport {
+	private static final String PWD = ".";
+
 	static boolean canHandle(final URIish uri) {
 		if (uri.getHost() != null || uri.getPort() > 0 || uri.getUser() != null
 				|| uri.getPass() != null || uri.getPath() == null)
 			return false;
 
 		if ("file".equals(uri.getScheme()) || uri.getScheme() == null)
-			return FS.resolve(new File("."), uri.getPath()).isDirectory();
+			return FS.resolve(new File(PWD), uri.getPath()).isDirectory();
 		return false;
 	}
 
@@ -74,7 +76,7 @@ class TransportLocal extends PackTransport {
 	TransportLocal(final Repository local, final URIish uri) {
 ...
[ message continues ]