Re: [PATCH v2 3/3] transport.c: introduce core.alternateRefsPrefixes

From: Jeff King <peff@peff.net>
Date: Sep 21, 2018, 21:37 UTC
Message-ID: <20180921213753.GA11177@sigill.intra.peff.net>
In-Reply-To: <xmqqbm8qv9hy.fsf@gitster-ct.c.googlers.com>

On Fri, Sep 21, 2018 at 02:14:17PM -0700, Junio C Hamano wrote:

Show 18 quoted lines

> Taylor Blau <me@ttaylorr.com> writes:
> 
> > +core.alternateRefsPrefixes::
> > +	When listing references from an alternate, list only references that begin
> > +	with the given prefix. Prefixes match as if they were given as arguments to
> > +	linkgit:git-for-each-ref[1]. To list multiple prefixes, separate them with
> > +	whitespace. If `core.alternateRefsCommand` is set, setting
> > +	`core.alternateRefsPrefixes` has no effect.
> 
> We do not allow anything elaborate like "refs/tags/release-*" but we
> still allow "refs/tags/" and "refs/heads/" by listing them together,
> and because these are only prefixes, whitespace is a reasonable list
> separator as they cannot appear anywhere in a refname.  OK.
> 
> Why is this "core"?  I thought this was more about receive-pack;
> even if this is going to be extended to upload-pack's negotiation,
> "core" is way too wide a hierarchy.  We have "transport.*" for
> things like this, no?

There's no extension necessary; these should already affect upload-pack as well. I agree transport.* would cover both upload-pack and receive-pack. If we extend it to check_everything_connected(), would it make sense as part of transport.*, too?

I dunno. I guess I could see an argument either way.

If we do add "rev-list --alternate-refs", that pushes it even further away from transport.*, though.

-Peff