Michael Haggerty <mhag...@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? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
