git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: --no-tags doesn't appear to be working as intended

From
BDBen Denhartog <ben@sudoforge.com>
Date
May 3, 2020, 18:27 UTC
Message-ID
<7ecc6a46-001a-45b5-8b63-7e07f88acfb9@www.fastmail.com>
In-Reply-To
<20200503065446.GA1829906@coredump.intra.peff.net>
Gah, sorry for the erroneous bug report, this was user error.
This was caused by having `fetch.prunetags = true` in my user-scoped conffile. As per the documentation from `git-fetch`:

``` The --prune-tags option is equivalent to having refs/tags/*:refs/tags/* declared in the refspecs of the remote. This can lead to some seemingly strange interactions:

           # These both fetch tags
           $ git fetch --no-tags origin 'refs/tags/*:refs/tags/*'
           $ git fetch --no-tags --prune-tags origin
       The reason it doesn’t error out when provided without --prune or its config versions is for flexibility of the configured versions, and to maintain a 1=1 mapping between what the command line flags
       do, and what the configuration versions do.
```
-- 
  Ben Denhartog
  ben@sudoforge.com

On Sat, May 2, 2020, at 23:54, Jeff King wrote:
> On Sat, May 02, 2020 at 02:01:35PM -0700, Ben Denhartog wrote:
> 
> > # set up the fork
> > git -C /tmp/b init
> > git -C /tmp/b remote add -f --no-tags upstream file:///tmp/a
> > ```
> > 
> > You'll see the 0.0.1 tag being fetched. You can delete it all you
> > want, set the `remote.upstream.tagopt = --no-tags`, etc -- it will
> > always be pulled. This is the opposite behavior I would expect based
> > on the available documentation and discussion around the tag in the
> > mailing list.
> 
> I don't see that behavior. I get:
> 
>   $ git -C /tmp/b remote add -f --no-tags upstream file:///tmp/a
>   Updating upstream
>   remote: Enumerating objects: 3, done.
>   remote: Counting objects: 100% (3/3), done.
>   remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
>   Unpacking objects: 100% (3/3), 197 bytes | 197.00 KiB/s, done.
>   From file:///tmp/a
>    * [new branch]      master     -> upstream/master
> 
> Is it possible you have some other config that might be conflicting
> (e.g., extra refspecs that ask to transfer tags)? What does "git config
> --list --show-origin" say?
> 
> -Peff
>
Previous: Jeff King
Message 3 of 3 in “--no-tags doesn't appear to be working as intended”
  1. Ben DenhartogMay 2, 2020
  2. Jeff KingMay 3, 2020
  3. Ben DenhartogMay 3, 2020

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.