Hi, I'm trying to set up a remote repository on a shared hosting provider. The provider doesn't have Git on their system, so I installed it to a custom location: ~/opt. That should be sufficient to allow external clients to use the repository, but there's a snag: The provider prevents users from modifying the PATH variable for non-interactive shells, which means I can't add ~/opt/bin to the server's PATH for SSH sessions. As a result, users who attempt to clone the repository get an error: bash: git-upload-pack: command not found Luckily, users can work around this issue by providing Git with the command's location: git clone -u /home/[user]/opt/bin/git-upload-pack [repository] but a subsequent "git pull" on the working copy also fails for the same reason, though that's also easily remedied: git config remote.origin.uploadpack '/home/[user]/opt/bin/git-upload-pack' However, there's one last problem I can't find a workaround for... Specifying the repository explicitly when doing a "git pull", such as: git pull someguy@xxxxxxxxxxxxx:git/some-repository.git still gives a "git-upload-pack: command not found" error. It seems that Git isn't honoring the remote.origin.uploadpack value here. This is a problem because I'm using a third-party automated tool for handling pushes, and it's hard-coded to always specify the repository in the command (as opposed to the default from the remotes list). Is this a bug in Git? Thanks, Trevor -- 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