Jonathan Nieder writes:
> I should have mentioned this is
>
> Reported-by: Shin Fan
>
>> Signed-off-by: Jeff King
>> ---
>> I just did this on master, and it is standalone. But for the reasons
>> above I think it would also be fine to
On Tue, Mar 22, 2016 at 2:43 PM, Jonathan Nieder wrote:
> Jeff King wrote[1]:
>
>> Subject: git_config_push_parameter: handle empty GIT_CONFIG_PARAMETERS
>>
>> The "git -c var=value" option stuffs the config value into
>> $GIT_CONFIG_PARAMETERS, so that sub-processes can see
Jeff King wrote[1]:
> Subject: git_config_push_parameter: handle empty GIT_CONFIG_PARAMETERS
>
> The "git -c var=value" option stuffs the config value into
> $GIT_CONFIG_PARAMETERS, so that sub-processes can see it.
> When the config is later read via git_config() or similar,
> we parse it back
Jeff King writes:
> Obviously another option would be to make the parsing side more liberal
> (which has the added effect that if anybody _else_ ever wants to
> generate $GIT_CONFIG_PARAMETERS, they will not get annoyed). But I took
> this route for now because it's the simplest
On Tue, Mar 22, 2016 at 03:23:09PM -0400, Jeff King wrote:
> On Tue, Mar 22, 2016 at 11:56:28AM -0700, Jonathan Nieder wrote:
>
> > This is failing for me when I use "git submodule add" with a remote
> > helper I whitelisted with GIT_ALLOW_PROTOCOL, with current "next":
> >
> > $
5 matches
Mail list logo