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

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 31, 2016, 22:44 UTC
Message-ID: <xmqqbn5ul12t.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20160331225055.Horde.1X4mNM4L4J85rAeMFQzAEH_@webmail.informatik.kit.edu>

SZEDER Gábor <szeder@ira.uka.de> writes:

Show 15 quoted lines

> Quoting Junio C Hamano <gitster@pobox.com>:
>
>> IOW, special casing -c remote.origin.fetch=spec
>> is a bad idea.
>
> I completely agree :)
> But it's the other way around.
>
> 'remote.origin.fetch=spec' during clone is special _now_, because the
> initial fetch ignores it, no matter where it is set.
>
> My patch makes it non-special, so that the initial fetch respects it,
> the same way it already respects 'fetch.fsckObjects' and
> 'fsck.unpackLimit', or the way the initial checkout respects e.g.
> 'core.eol'.

... but does "git -c core.eol clone" leave that configuration in the resulting repository's .git/config? "git -c user.name=foo" for that matter.

They may affect the one-shot operation but are not left in the resulting .git/config, which was what I was driving at. To make clone behave as if it is truly a short-hand of

	git init
	git config ;# with default and necessary tweaks to adjust
		   ;# for things like -b, -o, --single-branch
        git fetch
        git checkout

which by the way I think everybody agrees is a worth goal, then shouldn't the update to the current code be more like "prepare the default config, tweak with whatever configuration necessary, and re-read the config before driving the equivalent of 'git fetch'?"

And the conclusion my rhetorical questions led to was that "adjust for things like..." should not include what comes from "-c var=val" because there is no sensible way to incorporate them in general.

The most important point is that "-c var=val" is the wrong source of information to blindly propagete to the resulting .git/config. And the point of "--branches" option is not that it would be short and tidy, but it is more targetted. With such an approach, nobody would imagine "git -c random.var=value clone" would be propagated into the resulting .git/config in a random and unspecified way.

Once you learn what custom set of refs the user wants to fetch, you would need futzing of the refspecs like you did in your patch. That part of your patch is salvageable. The part that special cased the information that came from "-c remote.origin.fetch" while ignoring others like user.name that came from exactly the same mechanism via "-c user.name" is not.