# Feature suggestion: support arguments for GIT_PROXY_COMMAND & core.gitproxy 5 messages from 2009-12-18 to 2009-12-30. Participants: Joey Korkames, Nanako Shiraishi, Junio C Hamano, Jeff King. Thread: https://gitlist.dev/t/21987 ## Joey Korkames, 2009-12-18 23:39 Subject: Feature suggestion: support arguments for GIT_PROXY_COMMAND & core.gitproxy Message-ID: URL: https://gitlist.dev/e/cone.1261179562.490491.4033.1000%40toolshiner.phx1.kidfixit.com ``` Could /connect.c be patched to support multiple arguments in ENV[GIT_PROXY_COMMAND] and git config core.gitproxy? For instance, something like : GIT_PROXY_COMMAND="myproxyscript arg1 arg2" or (way more useful): git config core.gitproxy \ '"myproxyscript -mode git -proxy joey@gw.myhouse.com -proxy joey@bastion.foocorp.com" for foocorp.com$' Its slightly annoying to maintain and distribute custom copies of myproxyscript that carry the repo-specific proxy arguments inline just because git won't pass those arguments itself (arguments that a repo's .git/config can easily store). I think supporting tokens (ala ssh's ProxyCommand - %h=repohost, %p=repoport, %u=repouser) would be awesome, but that change would not be backward-compatible with existing .git/config files or GIT_PROXY_COMMAND utilizing-scripts. Its enough to assume that "$host $port" will always be appended to the gitproxy arg list. Thanks for reading, (and thnaks for git!) -joey ``` ## Joey Korkames, 2009-12-19 00:58 Subject: Re: Feature suggestion: support arguments for GIT_PROXY_COMMAND & core.gitproxy Message-ID: URL: https://gitlist.dev/e/cone.1261184309.999283.4033.1000%40toolshiner.phx1.kidfixit.com In-Reply-To: ``` I forgot to mention that this all applies to ENV[GIT_SSH] as well, which has no correspondgin git-config option, currently. I see there's some hardcoding of Tortoise and PuTTY's plink argument-handling in connect.c . I think a tokenable core.sshproxy option in ~/.gitconfig would be way less hinky, IMHO. I just played with the man options in git config and I really liked how that worked; maybe that's a good part of the codebase to copy-paste from? I'm no C hacker, otherwise I'd be shutting up and sending a patch... -joey ``` ## Nanako Shiraishi, 2009-12-30 03:13 Subject: Re: Feature suggestion: support arguments for GIT_PROXY_COMMAND & core.gitproxy Message-ID: <20091230121329.6117@nanako3.lavabit.com> URL: https://gitlist.dev/e/20091230121329.6117%40nanako3.lavabit.com In-Reply-To: ``` Junio, could you tell us what happened to this thread? I think this is probably related to the "textconv" change. ``` ## Junio C Hamano, 2009-12-30 08:06 Subject: Re: Feature suggestion: support arguments for GIT_PROXY_COMMAND & core.gitproxy Message-ID: <7vmy1051ik.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7vmy1051ik.fsf%40alter.siamese.dyndns.org In-Reply-To: <20091230121329.6117@nanako3.lavabit.com> ``` Nanako Shiraishi writes: > Junio, could you tell us what happened to this thread? > > I think this is probably related to the "textconv" change. Yeah, you guessed right. I think the unified way to launch user specified programs would come first and then spawning proxy the same way as others would become trivial. ``` ## Jeff King, 2009-12-30 11:05 Subject: Re: Feature suggestion: support arguments for GIT_PROXY_COMMAND & core.gitproxy Message-ID: <20091230110557.GG22959@coredump.intra.peff.net> URL: https://gitlist.dev/e/20091230110557.GG22959%40coredump.intra.peff.net In-Reply-To: <7vmy1051ik.fsf@alter.siamese.dyndns.org> ``` On Wed, Dec 30, 2009 at 12:06:43AM -0800, Junio C Hamano wrote: > Nanako Shiraishi writes: > > > Junio, could you tell us what happened to this thread? > > > > I think this is probably related to the "textconv" change. > > Yeah, you guessed right. I think the unified way to launch user specified > programs would come first and then spawning proxy the same way as others > would become trivial. As a "7/6" on top of my other series, this should just be: diff --git a/connect.c b/connect.c index db965c9..838146c 100644 --- a/connect.c +++ b/connect.c @@ -432,6 +432,7 @@ static void git_proxy_connect(int fd[2], char *host) argv[2] = port; argv[3] = NULL; memset(&proxy, 0, sizeof(proxy)); + proxy.use_shell = 1; proxy.argv = argv; proxy.in = -1; proxy.out = -1; But I will leave it to somebody who actually uses the proxy feature to test and submit a patch. -Peff ```