Quoting Junio C Hamano <gitster@xxxxxxxxx>:
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?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html