{"thread":{"id":"26818","subject":"remote.origin.*pack settings are not honored when repository is specified","startedAt":"2011-03-21T18:31:06Z","lastAt":"2011-03-21T19:48:04Z","messageCount":3,"participants":["Trevor Harmon","Erik Faye-Lund"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"163949","messageId":"982706A6-A00E-43B3-9002-41C8DC084EC9@vocaro.com","threadId":"26818","inReplyTo":null,"subject":"remote.origin.*pack settings are not honored when repository is specified","fromName":"Trevor Harmon","fromEmail":"trevor@vocaro.com","sentAt":"2011-03-21T18:31:06Z","receivedAt":"2011-03-21T18:31:06Z","isPatch":false,"sender":{"key":"trevor@vocaro.com","avatar":null},"body":"Hi,\n\nI'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:\n\n  bash: git-upload-pack: command not found\n\nLuckily, users can work around this issue by providing Git with the command's location:\n\n  git clone -u /home/[user]/opt/bin/git-upload-pack [repository]\n\nbut a subsequent \"git pull\" on the working copy also fails for the same reason, though that's also easily remedied:\n\n  git config remote.origin.uploadpack '/home/[user]/opt/bin/git-upload-pack'\n\nHowever, there's one last problem I can't find a workaround for... Specifying the repository explicitly when doing a \"git pull\", such as:\n\n  git pull someguy@somewhere.com:git/some-repository.git\n\nstill 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).\n\nIs this a bug in Git? Thanks,\n\nTrevor\n"},{"id":"163957","messageId":"AANLkTina56vfqidyyB0DgkAP2upvkCuW8OshnxzuNVjy@mail.gmail.com","threadId":"26818","inReplyTo":"982706A6-A00E-43B3-9002-41C8DC084EC9@vocaro.com","subject":"Re: remote.origin.*pack settings are not honored when repository is specified","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@gmail.com","sentAt":"2011-03-21T19:25:47Z","receivedAt":"2011-03-21T19:25:47Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Mon, Mar 21, 2011 at 7:31 PM, Trevor Harmon <trevor@vocaro.com> wrote:\n> Hi,\n>\n> 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:\n>\n>  bash: git-upload-pack: command not found\n>\n> Luckily, users can work around this issue by providing Git with the command's location:\n>\n>  git clone -u /home/[user]/opt/bin/git-upload-pack [repository]\n>\n> but a subsequent \"git pull\" on the working copy also fails for the same reason, though that's also easily remedied:\n>\n>  git config remote.origin.uploadpack '/home/[user]/opt/bin/git-upload-pack'\n>\n> However, there's one last problem I can't find a workaround for... Specifying the repository explicitly when doing a \"git pull\", such as:\n>\n>  git pull someguy@somewhere.com:git/some-repository.git\n>\n> still gives a \"git-upload-pack: command not found\" error. It seems that Git isn't honoring the remote.origin.uploadpack value here.\n\nremote.origin.* applies to the configured remote called \"origin\". If\nyou specify a remote-url then you're not using the configured remote.\n\nYou could use the --upload-pack option when pulling (unless you're\nusing Windows and MSYS/CYGWIN, because bash will end up translating\nthe path to a win32-path...)\n\n> 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).\n>\n> Is this a bug in Git? Thanks,\n\nNo, this is expected behavior. You should probably look into getting\nit fixed in the external tool, if possible.\n"},{"id":"163965","messageId":"BBA93ABD-C146-4866-AFB9-6E07717AE541@vocaro.com","threadId":"26818","inReplyTo":"AANLkTina56vfqidyyB0DgkAP2upvkCuW8OshnxzuNVjy@mail.gmail.com","subject":"Re: remote.origin.*pack settings are not honored when repository is specified","fromName":"Trevor Harmon","fromEmail":"trevor@vocaro.com","sentAt":"2011-03-21T19:48:04Z","receivedAt":"2011-03-21T19:48:04Z","isPatch":false,"sender":{"key":"trevor@vocaro.com","avatar":null},"body":"On Mar 21, 2011, at 12:25 PM, Erik Faye-Lund wrote:\n\n> You could use the --upload-pack option when pulling\n...\n> You should probably look into getting\n> it fixed in the external tool, if possible.\n\nYes, 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,\n\nTrevor\n"}]}