Re: fetch: tag following too ambitious?

[Junio C Hamano <gitster@pobox.com>]

Michael Haggerty <mhagger@alum.mit.edu> writes:

> When investigating the exact semantics of tag-following, I discovered
> that the tag auto-following behavior of "git fetch" is more ambitious
> than I would have expected: it fetches any tag that references an object
> that is known to the local repository, *even if that object is not
> currently reachable* (i.e., neither reachable before the fetch or after
> the fetch of non-auto-followed references).  This makes it hard to
> renounce interest in a branch.
>
> Suppose there is a remote repo with
>
>     o---o---o        <- master
>      \
>       o---A---B      <- pu
>
> When I clone this repo, of course I get all of the commits and both
> branches.
>
> Now suppose I decide I'm not interested in "branch" anymore, so I delete
> its remote-tracking branch from my repository and change the config to
> only fetch "master":
>
>     git config remote.origin.fetch \
>             '+refs/heads/master:refs/remotes/origin/master'
>     git update-ref -d refs/remotes/origin/pu
>
> It looks like I'm free of the "pu" branch, right?
>
> But if a week later somebody pushes a tag "t" to origin that points at
> commit A, and then I do
>
>     git fetch origin
>
> then Git (un)helpfully fetches tag "t" into my repo, because even though
> commit "A" isn't reachable in my repo, it hasn't been pruned yet from
> the object database.
>
> I admit this is not likely to be a serious problem in practice, but I
> found it surprising and strangely disturbing.  I would call it a bug.

Sounds like a bug to me.  Does upload-pack to pack-object codepath
actually pack the tag object and give it to you, or is it done all
by reconnecting an existing and dangling tag back to your ref
namespace?