On Tue, Sep 25, 2018 at 04:56:11PM -0700, Junio C Hamano wrote:
> Taylor Blau writes:
>
> > My reading of this is threefold:
> >
> > 1. There are some cosmetic changes that need to occur in t5410 and
> > documentation, which are mentioned above. Those seem self
> > explanatory, and I
On Tue, Sep 25, 2018 at 04:56:11PM -0700, Junio C Hamano wrote:
> Taylor Blau writes:
>
> > My reading of this is threefold:
> >
> > 1. There are some cosmetic changes that need to occur in t5410 and
> > documentation, which are mentioned above. Those seem self
> > explanatory, and I'v
Taylor Blau writes:
> My reading of this is threefold:
>
> 1. There are some cosmetic changes that need to occur in t5410 and
> documentation, which are mentioned above. Those seem self
> explanatory, and I've applied the necessary bits already on my
> local version of this topic
On Tue, Sep 25, 2018 at 10:41:18AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Right, I think that is totally fine for the current uses. I guess my
> > question was: do you envision cutting the interface down to only the
> > oids to bite us in the future?
> >
> > I was on the fence duri
Jeff King writes:
> Right, I think that is totally fine for the current uses. I guess my
> question was: do you envision cutting the interface down to only the
> oids to bite us in the future?
>
> I was on the fence during past discussions, but I think I've come over
> to the idea that the refnam
On Mon, Sep 24, 2018 at 02:55:57PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Do you have an opinion on whether for_each_alternate_refs() interface
> > should stop passing back refnames? By the "they may not even exist"
> > rationale in this sub-thread, I think it's probably foolish
Jeff King writes:
> Do you have an opinion on whether for_each_alternate_refs() interface
> should stop passing back refnames? By the "they may not even exist"
> rationale in this sub-thread, I think it's probably foolish for any
> caller to actually depend on the names being meaningful.
I perso
On Mon, Sep 24, 2018 at 04:50:22PM -0400, Jeff King wrote:
> On Mon, Sep 24, 2018 at 01:32:26PM -0700, Junio C Hamano wrote:
>
> > Jeff King writes:
> >
> > > So I think it's conceptually consistent to always show a subset.
> >
> > OK. Then I agree with you that it is a good approach to first
On Mon, Sep 24, 2018 at 01:32:26PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > So I think it's conceptually consistent to always show a subset.
>
> OK. Then I agree with you that it is a good approach to first adopt
> core.* knobs that universally apply, and add specialized ones as
Jeff King writes:
> So I think it's conceptually consistent to always show a subset.
OK. Then I agree with you that it is a good approach to first adopt
core.* knobs that universally apply, and add specialized ones as
they are needed later.
Thanks.
On Mon, Sep 24, 2018 at 08:17:14AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > I was suggesting that check_everything_connected() is not strictly
> > transport-related, so would be inappropriate for transport.*, and we'd
> > need a more generic name. And my "either way" was that I cou
Jeff King writes:
> I was suggesting that check_everything_connected() is not strictly
> transport-related, so would be inappropriate for transport.*, and we'd
> need a more generic name. And my "either way" was that I could see
> an argument that it _is_ transport related, since we only call it
On Fri, Sep 21, 2018 at 3:18 PM Jeff King wrote:
> I agree that core.* is kind of a kitchen sink, but I'm not sure that's
> all that bad. Is "here is how Git finds refs in an alternate" any more
This touches both "refs" and "alternates", which are Git concepts
whereas ssh is not.
> or less core
On Fri, Sep 21, 2018 at 03:06:43PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > 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(), w
Jeff King writes:
> 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 co
On Fri, Sep 21, 2018 at 02:14:17PM -0700, Junio C Hamano wrote:
> Taylor Blau 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
Taylor Blau 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
The recently-introduced "core.alternateRefsCommand" allows callers to
specify with high flexibility the tips that they wish to advertise from
alternates. This flexibility comes at the cost of some inconvenience
when the caller only wishes to limit the advertisement to one or more
prefixes.
For exa
18 matches
Mail list logo
