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