Brandon Williams writes:
> On 07/09, Junio C Hamano wrote:
>> Brandon Williams writes:
>>
>> > I agree with this observation, though I'm a bit sad about it. I think
>> > that having tag auto-following the default is a little confusing (and
>> > hurts perf[1] when using proto v2) but since
On 07/09, Junio C Hamano wrote:
> Brandon Williams writes:
>
> > I agree with this observation, though I'm a bit sad about it. I think
> > that having tag auto-following the default is a little confusing (and
> > hurts perf[1] when using proto v2) but since thats the way its always been
> >
Brandon Williams writes:
> I agree with this observation, though I'm a bit sad about it. I think
> that having tag auto-following the default is a little confusing (and
> hurts perf[1] when using proto v2) but since thats the way its always been
> we'll have to live with it for now. I think
On 07/09, Jonathan Nieder wrote:
> Hi,
>
> Jonathan Tan wrote:
>
> > --- a/builtin/fetch.c
> > +++ b/builtin/fetch.c
> > @@ -359,7 +359,7 @@ static struct ref *get_ref_map(struct transport
> > *transport,
> > refspec_ref_prefixes(>remote->fetch, _prefixes);
> >
> > if
Hi,
Jonathan Tan wrote:
> --- a/builtin/fetch.c
> +++ b/builtin/fetch.c
> @@ -359,7 +359,7 @@ static struct ref *get_ref_map(struct transport
> *transport,
> refspec_ref_prefixes(>remote->fetch, _prefixes);
>
> if (ref_prefixes.argc &&
> - (tags == TAGS_SET ||
> Jonathan Tan writes:
>
> >> Wouldn't that allow us not having to advertise the whole tags
> >> namespace only to implement the tag following?
> >
> > Yes, it would, but as far as I can tell, it would add an extra burden on
> > the server to walk all refs requested in the ls-refs call (in order
Jonathan Tan writes:
>> Wouldn't that allow us not having to advertise the whole tags
>> namespace only to implement the tag following?
>
> Yes, it would, but as far as I can tell, it would add an extra burden on
> the server to walk all refs requested in the ls-refs call (in order to
>
> Jonathan Tan writes:
>
> > When performing tag following, in addition to using the server's
> > "include-tag" capability to send tag objects (and emulating it if the
> > server does not support that capability), "git fetch" relies upon the
> > presence of refs/tags/* entries in the initial ref
Jonathan Tan writes:
> When performing tag following, in addition to using the server's
> "include-tag" capability to send tag objects (and emulating it if the
> server does not support that capability), "git fetch" relies upon the
> presence of refs/tags/* entries in the initial ref
On 06/18, Jonathan Tan wrote:
>
> This would cause different behavior. For example, if I run "git fetch
> refs/heads/master refs/tags/foo", I would expect tag following to work
> even if the tag's name does not start with refs/tags/foo.
I understand that some people *may* want tag following, but
> okay. Thinking long term, we may want to introduce a capability that
> can filter the tag space, e.g. "want-refs-since refs/tags/*"
> as a client directive as then the client only asks for new (newly
> created/appearing) tags instead of all tags.
I don't think refs normally have a
On Tue, Jun 5, 2018 at 2:41 PM Jonathan Tan wrote:
>
> When performing tag following, in addition to using the server's
> "include-tag" capability to send tag objects (and emulating it if the
> server does not support that capability), "git fetch" relies upon the
> presence of refs/tags/* entries
When performing tag following, in addition to using the server's
"include-tag" capability to send tag objects (and emulating it if the
server does not support that capability), "git fetch" relies upon the
presence of refs/tags/* entries in the initial ref advertisement to
locally create refs
13 matches
Mail list logo
