Re: [PATCH] git fetch one tag only
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jun 7, 2012, 05:33 UTC
- Message-ID
- <7vpq9bk7o5.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <CAH5vBdKPH_-cn=r-zxQKCOi5PB5D6vuSXrZxPeZJ+HYg-K9Yqw@mail.gmail.com>
cheng renquan <crquan@gmail.com> writes:
Show 23 quoted lines
>> 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.