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 really its
confusing from an end user's standpoint. You can fetch a particular ref
and end up with a bunch of tags that you didn't want. Aside from that
my biggest issue is with performance. The ref filtering was added to
cut down on the number of refs sent from the server, now we're basically
adding them all back no matter what (unless a user goes and flips the
default to not fetch tags).
I think we're probably going to need some people other than us to
comment on how this should be handled.
>
> > > @@ -359,7 +359,7 @@ static struct ref *get_ref_map(struct transport *transport,
> > > refspec_ref_prefixes(&transport->remote->fetch, &ref_prefixes);
> > >
> > > if (ref_prefixes.argc &&
> > > - (tags == TAGS_SET || (tags == TAGS_DEFAULT && !rs->nr))) {
> > > + (tags == TAGS_SET || tags == TAGS_DEFAULT)) {
> >
> > Oh, I see. This always asks for refs/tags/ whereas before we only
> > asked for them if there were *no* refspec given. Maybe we can
> > change this to
> >
> > refspec_any_item_contains("refs/tags/")
> >
> > instead of always asking for the tags?
> > (that function would need to be written; I guess for a short term bugfix
> > this is good enough)
>
> Same answer as above.
>
> > How is the tag following documented (i.e. when is the user least
> > surprised that we do not tag-follow all and unconditionally)?
>
> It's documented under the --no-tags option in the man page for git
> fetch. I'm not sure what you mean by the user being surprised.
--
Brandon Williams
