# remote.origin.*pack settings are not honored when repository is specified 3 messages from 2011-03-21 to 2011-03-21. Participants: Trevor Harmon, Erik Faye-Lund. Thread: https://gitlist.dev/t/26818 ## Trevor Harmon, 2011-03-21 18:31 Subject: remote.origin.*pack settings are not honored when repository is specified Message-ID: <982706A6-A00E-43B3-9002-41C8DC084EC9@vocaro.com> URL: https://gitlist.dev/e/982706A6-A00E-43B3-9002-41C8DC084EC9%40vocaro.com ``` 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, 2011-03-21 19:25 Subject: Re: remote.origin.*pack settings are not honored when repository is specified Message-ID: URL: https://gitlist.dev/e/AANLkTina56vfqidyyB0DgkAP2upvkCuW8OshnxzuNVjy%40mail.gmail.com In-Reply-To: <982706A6-A00E-43B3-9002-41C8DC084EC9@vocaro.com> ``` On Mon, Mar 21, 2011 at 7:31 PM, Trevor Harmon wrote: > 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, 2011-03-21 19:48 Subject: Re: remote.origin.*pack settings are not honored when repository is specified Message-ID: URL: https://gitlist.dev/e/BBA93ABD-C146-4866-AFB9-6E07717AE541%40vocaro.com In-Reply-To: ``` 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 ```