From: SZEDER Gábor Date: Thu, 31 Mar 2016 20:50:55 GMT Subject: Re: [PATCH v2] clone: respect configured fetch respecs during initial fetch Message-ID: <20160331225055.Horde.1X4mNM4L4J85rAeMFQzAEH_@webmail.informatik.kit.edu> In-Reply-To: Quoting Junio C Hamano : > 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 (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?