Re: remote.origin.*pack settings are not honored when repository is specified

From: Erik Faye-Lund <kusmabite@gmail.com>
Date: Mar 21, 2011, 19:25 UTC
Message-ID: <AANLkTina56vfqidyyB0DgkAP2upvkCuW8OshnxzuNVjy@mail.gmail.com>
In-Reply-To: <982706A6-A00E-43B3-9002-41C8DC084EC9@vocaro.com>

On Mon, Mar 21, 2011 at 7:31 PM, Trevor Harmon <trevor@vocaro.com> wrote:

Show 19 quoted lines

> 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@somewhere.com: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.

remote.origin.* applies to the configured remote called "origin". If you specify a remote-url then you're not using the configured remote.

You could use the --upload-pack option when pulling (unless you're using Windows and MSYS/CYGWIN, because bash will end up translating the path to a win32-path...)

> 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,

No, this is expected behavior. You should probably look into getting it fixed in the external tool, if possible.