Quoting Junio C Hamano <gitster@xxxxxxxxx>:
SZEDER Gábor <szeder@xxxxxxxxxx> 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.
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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html