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
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
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
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
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
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
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
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
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
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(),
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
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,
17 matches
Mail list logo
