cheng renquan <crquan@xxxxxxxxx> writes: >> There is a convenience short-hand "tag <tagname>", i.e. >> >> git fetch 3rd-repo tag the-tag-name >> >> that is equivalent to >> >> git fetch 3rd-repo refs/tags/the-tag-name:refs/tags/the-tag-name >> >> So I do not think your patch is necessary for your use case, and >> obviously it will break other people's use case where they just >> want to fetch (and inspect what is left in FETCH_HEAD) but do not >> want to store. > > No, I tried what you said but it doesn't work as expected: > ... > [linus-git] $ git fetch -v --dry-run linux-stable tag v3.4.1 |& head > From git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable > = [up to date] v3.4.1 -> v3.4.1 > * [new tag] latest -> latest > * [new tag] v2.6.12.1 -> v2.6.12.1 > * [new tag] v2.6.12.2 -> v2.6.12.2 > [...] > maybe I'd better to fix that? Ahh, that is auto-following of tags. Read up on that in "git fetch" manual page, and there is an option to decline auto-following also described. The (current) rule is to grab all tags that reference commits you are fetching *IF* you are storing any refs resulting from the fetch in your refs/ namespace, and "tag v3.4.1" obviously asks for storing that tag at refs/tags/v3.4.1 in your repository, so it is expected that the auto-following kicks in. It is a separate matter if we should add some special case to further reduce the cases where auto-following happens. I personally do not think any change is needed. -- 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