Re: [BUG?] Fetching a single tag to a local tag requires `--no-tags`

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jul 14, 2020 at 10:17:59PM -0400, Philippe Blain wrote:

> If I want to fetch a single tag from a remote repository to a local tag,
> it seems I have to use `--no-tags`, or else all tags on the remote are fetched:
> 
> git remote add ggg https://github.com/gitgitgadget/git
> # this command fetches all tags on Gitgitgadget
> git fetch ggg tag pr-590/phil-blain/doc-log-multiple-ranges-v2
> # this command fetches only the tag listed on the command line
> git fetch ggg tag pr-590/phil-blain/doc-log-multiple-ranges-v2 --no-tags

Hmm, that's not what I see:

  $ git clone -q https://github.com/git/git tmp
  $ cd tmp
  $ git remote add ggg https://github.com/gitgitgadget/git
  $ git fetch ggg tag pr-590/phil-blain/doc-log-multiple-ranges-v2
  remote: Enumerating objects: 11, done.
  remote: Counting objects: 100% (11/11), done.
  remote: Total 18 (delta 10), reused 10 (delta 10), pack-reused 7
  Receiving objects: 100% (18/18), 7.16 KiB | 1.79 MiB/s, done.
  Resolving deltas: 100% (12/12), completed with 3 local objects.
  From https://github.com/gitgitgadget/git
   * [new tag]               pr-590/phil-blain/doc-log-multiple-ranges-v2 -> pr-590/phil-blain/doc-log-multiple-ranges-v2

> Am I reading the documentation correctly ?
> 
> tag <tag> syntax [1]:
> "tag <tag> means the same as refs/tags/<tag>:refs/tags/<tag>; 
> it requests fetching everything up to the given tag."
> 
> --no-tags [2] :
> "By default, tags that point at objects that are downloaded
> from the remote repository are fetched and stored locally.
> This option disables this automatic tag following." 

I think this last one may be an oversimplification. I'm pretty sure that
we'd download a tag that points to any object we already have, even if
it wasn't just fetched.

  [after this, we'll have the object still, but not the tag]
  $ git tag -d pr-590/phil-blain/doc-log-multiple-ranges-v2
  Deleted tag 'pr-590/phil-blain/doc-log-multiple-ranges-v2' (was 3221c3f76f)

  $ git fetch ggg tag pr-590/phil-blain/doc-log-multiple-ranges-v1
  remote: Enumerating objects: 16, done.
  remote: Counting objects: 100% (16/16), done.
  remote: Total 25 (delta 15), reused 15 (delta 15), pack-reused 9
  Receiving objects: 100% (25/25), 8.67 KiB | 2.89 MiB/s, done.
  Resolving deltas: 100% (17/17), completed with 8 local objects.
  From https://github.com/gitgitgadget/git
   * [new tag]               pr-590/phil-blain/doc-log-multiple-ranges-v1 -> pr-590/phil-blain/doc-log-multiple-ranges-v1
   * [new tag]               pr-590/phil-blain/doc-log-multiple-ranges-v2 -> pr-590/phil-blain/doc-log-multiple-ranges-v2

So in the second fetch, we got v1 and v2, because we already had the
history for v2 sitting around. In the example at the beginning of my
email, our git.git clone was pristine. But presumably you ran into this
in a repository where you'd been doing work on that or other ggg-tracked
topics.

-Peff



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux