Re: [PATCH v2] clone: respect configured fetch respecs during initial fetch
- From
SZEDER Gábor <szeder@ira.uka.de>
- Date
- Mar 31, 2016, 20:50 UTC
- Message-ID
- <20160331225055.Horde.1X4mNM4L4J85rAeMFQzAEH_@webmail.informatik.kit.edu>
- In-Reply-To
- <xmqq1t6qo4rd.fsf@gitster.mtv.corp.google.com>
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'.
Show 11 quoted lines
> 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.
Show 8 quoted lines
> 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?