Subject: Re: [PATCH] scalar: add --no-tags option

From: Junio C Hamano <[email-masked]>
Date: Thu, 05 Sep 2024 09:12:38 -0700

"Derrick Stolee via GitGitGadget" <[email-masked]> writes:

> From: Derrick Stolee <[email-masked]>
>
> Some large repositories use tags to track a huge list of release
> versions. While this is choice is costly on the ref advertisement, it is
> further wasteful for clients who do not need those tags. Allow clients
> to optionally skip the tag advertisement.
>
> This behavior is similar to that of 'git clone --no-tags' implemented in
> 0dab2468ee5 (clone: add a --no-tags option to clone without tags,
> 2017-04-26), including the modification of the remote.origin.tagOpt
> config value to include "--no-tags".
>
> One thing that is opposite of the 'git clone' implementation is that
> this allows '--tags' as an assumed option, which can be naturally negated
> with '--no-tags'. The clone command does not accept '--tags' but allows
> "--no-no-tags" as the negation of its '--no-tags' option.

Yuck.  The loophole may be something we may want to close later,
though (and replaced with a proper "--tags" support).

> While testing this option, combine the test with the previously untested
> '--no-src' option introduced in 4527db8ff8c (scalar: add --[no-]src
> option, 2023-08-28).
>
> Signed-off-by: Derrick Stolee <[email-masked]>
> ---

Makes sense.

This is a tangent, but the "--[no-]tags" option in "git fetch" is
misdesigned; the default is to auto-follow tags that would annotate
objects that are being fetched, and "--no-tags" is a way to decline
the auto-following.  But "--tags" is to say that all tags must be
fetched.  There is no obvious way to say "I want the auto-following
behaviour" (e.g., to override an earlier "--no-tags" or "--tags").