Re: [PATCH v2] clone: respect configured fetch respecs during initial fetch

From: SZEDER Gábor <szeder@ira.uka.de>
Date: Apr 1, 2016, 00:30 UTC
Message-ID: <20160401023029.Horde.xfy5_x25TYi5be_HbswgxWI@webmail.informatik.kit.edu>
In-Reply-To: <xmqq1t6qr5c1.fsf@gitster.mtv.corp.google.com>

Quoting Junio C Hamano <gitster@pobox.com>:

Show 17 quoted lines

> SZEDER Gábor <szeder@ira.uka.de> writes:
>
>> Conceptually 'git clone' should behave as if the following commands
>> were run:
>>
>>   git init
>>   git config ... # set default configuration and origin remote
>>   git fetch
>>   git checkout   # unless '--bare' is given
>>
>> However, that initial 'git fetch' behaves differently from any
>> subsequent fetches, because it takes only the default fetch refspec
>> into account and ignores all other fetch refspecs that might have
>> been explicitly specified on the command line (e.g. 'git -c
>> remote.origin.fetch=<refspec> clone' or 'git clone -c ...').
>
> Is it really 'git fetch' behaves differently?

Certainly.

> What is missing in the above description is your expected behaviour
> of "git -c var=val clone", and without it we cannot tell if your
> expectation is sane to begin with.

These 'git -c var=val cmd' one-shot configuration parameters exist during the lifespan of the command. Therefore, in case of 'git -c var=val clone' they should exist while all the commands in our mental model are executed. IOW, those commands should behave as if these configuration parameters were specified for them, see below.

Show 9 quoted lines

> Is the expectation like this?
>
>     git init
>     git config ... # set default configuration and origin remote
>     git config var val # update with what "-c var=val" told us
>     git fetch
>     git checkout   # unless '--bare' is given
>
> or is it something else?

For 'git -c var=val clone':

   git -c var=val init
   git -c var=val config ... # though this probably doesn't really
                             # matter, as it is about writing the
                             # configuration, and it gets the
                             # to-be-written variables and values
                             # in the "..." part anyway
   git -c var=val fetch
   git -c var=val checkout

Being one-shot configuration parameters, they shouldn't be written to the new repository's config file.

'git clone -c var=val' is designed to be different:

   - it does write var=val into the new repository's config file

   - it specifies that var.val "takes effect immediately after the
     repository is initialized, but before the remote history is
     fetched or any files checked out".

Additionally, there may be relevant config variables defined in the global and system-wide config files, which of course should be respected by all these commands.

And it all works just fine as described above, even the initial fetch respects most of the config variables, wherever specified, except for fetch refspecs which are completely ignored.

> Is "-c var=val" adding to the config variables set by default, or is
> it replacing them?  Does the choice depend on the nature of
> individual variables, and if so what is the criteria?

It's up to the individual command how it treats a particular config variable: single-valued variables like 'fetch.fsckObjects' should override (they already do), multi-valued variables like fetch refspecs should be added. Running as part of 'git clone' shouldn't matter at all.

This patch only affects how fetch refspecs are handled, the effects of other config variables are unchanged.

> Are all "-c var=val" update the configuration of the resulting
> repository?  Or are certain "var"s treated as special and placed in
> the config but not other "var"s?  If the latter, what makes these
> certain "var"s special?

In this regard it doesn't matter what 'val=var' is. What matters is how the configuration parameter is specified (i.e. 'git -c var=val clone' vs. 'git clone -c var=val').

This patch doesn't change anything in this regard.