threads / discuss / 26818

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

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

## tl;dr

3 messages between Mar 21, 2011 and Mar 21, 2011.

replies: 2people: 2as markdown or json

Trevor Harmon· Mar 21, 2011, 18:31 UTC · lore
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. 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
Erik Faye-Lund· Mar 21, 2011, 19:25 UTC · re: Trevor Harmon · lore

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

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.

Trevor Harmon· Mar 21, 2011, 19:48 UTC · re: Erik Faye-Lund · lore

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

On Mar 21, 2011, at 12:25 PM, Erik Faye-Lund wrote:
> You could use the --upload-pack option when pulling
...
> You should probably look into getting
> it fixed in the external tool, if possible.
Yes, probably the best course of action is to modify the tool so it can accept arbitrary Git parameters as options for its push command, then specify --receive-pack as one of those options. Thanks for your help,
Trevor

← back to recent threads