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

["SZEDER Gábor" <szeder@ira.uka.de>]

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'.

> 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

Without my patch the initial fetch would ignore these refspecs, too.

> instead of the usual
>
> 	[remote "origin"]
> 		fetch = +refs/heads/*:refs/remotes/origin/*

Typing only branch names is much shorter and simpler than typing the
name of a config var and full refspecs, so this would be a nice
simplification of the UI for the case when the user is only
interested in certain branches.  But it wouldn't help if the user
wants to include 'refs/interesting/*' in the initial fetch.


> 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?