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

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 31, 2016, 18:56 UTC
Message-ID: <xmqq1t6qo4rd.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <xmqq1t6qr5c1.fsf@gitster.mtv.corp.google.com>

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

Show 23 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?
>
> 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?
>
> 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?
>
> These design decisions need to be explained so that they will serve
> to guide people to decide what other variables to propagate and how
> when they have to add new configuration variables in the future.
> Otherwise we'd end up with an inconsistent mess.

The above did not start as rhetorical questions, but was merely me thinking aloud. However, it showed me a different approach might be more appropriate.

Taken as rhetorical questions, the sane answers to them would revolve around "we do not know the semantics of each and every configuration variable that will be given to this codepath, and by definition we will never know in advance the ones that will be introduced later". IOW, special casing -c remote.origin.fetch=spec is a bad idea.

So how about teaching "git clone" a new _option_ that is about what branches are followed?

	git clone $there --branches="master next pu"

would give

	[remote "origin"]
        	fetch = +refs/heads/master:refs/remotes/origin/master
        	fetch = +refs/heads/next:refs/remotes/origin/next
        	fetch = +refs/heads/pu:refs/remotes/origin/pu

instead of the usual

	[remote "origin"]
		fetch = +refs/heads/*:refs/remotes/origin/*

And that can be made to work orthognonal to --single-branch by a small additional rule: if the branch given by -b <name> (or their HEAD) is not part of --branches, then we add it to the set of branches to be followed (i.e. if you give only --single-branch, without --branches, the set of branches to be followed will become that single branch).

Hmm?