Jeff King <peff@xxxxxxxx> writes: > I think one thing I was missing is that we need to just grab the > _object_, but we need to realize that the ref needs updating[1]. So we > cannot skip backfill of any tag that we do not already have, even if we > already have the tag object. > ... > [1] I'm still puzzled why find_non_local_tags uses has_sha1_file() on > the tag object at all, then. The designed semantics of auto-following tags (not necessarily as implemented or documented, i.e. there may be implementation or documentation bugs), I think, is to arrive at the same state as doing a fetch (or a push) without the auto-following and then doing a separate fetch (or a push) of tags that point at the objects that are reachable from the tips of refs after finishing the first (i.e. without auto-follow) fetch (or a push). In a scenario where we already have a commit reachable from existing remote-tracking branch and the current transfer (be it a fetch or a push, with or without auto-follow) does not update any remote-tracking branch (because the source side did not have any changes), if the source side added a tag that refers to that commit that the receiving end lacks, that tag needs to be transferred and then stored. So has_sha1_file() is not the right test---if anything, it needs to be checking if the object being checked is reachable from a tip of some ref. But of course, that test is rather expensive, so perhaps the implementation cheated and uses has_sha1_file() instead? The only case it would misidentify would be after an aborted fetch (or push) left unconnected island of objects and some of these objects that are not reachable are pointed at by tags the receiving end does not have. -- 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