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

Re: Local tag killer

From
John Szakmeister <john@szakmeister.net>
Date
Sep 21, 2013, 12:28 UTC
Message-ID
<CAEBDL5UVZERxHF5FwR66HummgjoczWGwzXwiHZtFKZGBLt6c+A@mail.gmail.com>
In-Reply-To
<523D3FD2.4090002@alum.mit.edu>
On Sat, Sep 21, 2013 at 2:42 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
Show 17 quoted lines
> On 09/21/2013 12:51 AM, Junio C Hamano wrote:
>> Junio C Hamano <gitster-vger@pobox.com> writes:
>>
>>> I also agree that the documentation is misstated; "remote-tracking branch"
>>> may have been a convenient and well understood phrase for whoever wrote
>>> that part, but the --prune is designed to cull extra refs in the
>>> hierarchies into
>>> which refs would be fetched if counterparts existed on the other side, so
>>> culling tags that do not exist on the remote side should also be described.
>>
>> (gleaning-leftovers mode)
>
> Thanks for following up on this with your proposed documentation patch.
>  I have been researching and experimenting, and still find the use of
> fetch confusing with respect to tags.  I think the problem is primarily
> that the behavior is awkward, and that it would be better to change the
> behavior than to document the awkward behavior.
I agree with this sentiment.  I've never liked how `--tags` operates.
Show 5 quoted lines
> I must have read an old version of the documentation, from which it
> seemed that "git fetch --tags" fetches all tags from the remote *in
> addition to* the references and tags that would otherwise be fetched.
> This seems like a handy and safe feature, and I wish that this were
> indeed the effect of "--tags".
Me too.
Show 42 quoted lines
> But I see that the documentation for "--tags" has been changed and now
> states explicitly that "--tags" is equivalent to specifying
> "refs/tags/*:refs/tags/*" on the command line, overriding any configured
> refspecs.  This doesn't seem like useful behavior; why would I want to
> fetch tags from a remote without also updating the configured refspecs?
>  And contrariwise, how can I fetch the configured refspecs *and* all
> tags at the same time in a single fetch?
>
> OK, one way to do it is to configure an explicit refspec for fetching
> the tags:
>
> [remote "origin"]
>         url = [...]
>         fetch = +refs/heads/*:refs/remotes/origin/*
>         fetch = refs/tags/*:refs/tags/*
>
> [Here is one oddity: even if the tags refspec doesn't have a "+" prefix,
> "git fetch" will do non-ff updates to tags, presumably because of the
> implicit tag-fetching behavior.]
>
> But if I use this configuration and type "git fetch --prune", then any
> local tags that are not present on the remote will be killed.
>
> In short, when local tags are in use, or tags that are in one remote but
> not another [1], then the current Git implementation makes it impossible to
>
> - Configure "fetch.prune" or "remote.$REMOTE.prune" without preventing
> the use of "fetch --tags"
>
> - Configure default fetching of all tags (via a refspec or via
> remote.$REMOTE.tagopt) without preventing the use of "fetch --prune"
>
> - Configure "fetch.prune" or "remote.$REMOTE.prune" and the default
> fetching of all tags (via a refspec or via remote.$REMOTE.tagopt) at the
> same time.
>
> This is unfortunate.
>
> I think it would be preferable if "--prune" would *not* affect tags, and
> if there were an extra option like "--prune-tags" that would have to be
> used explicitly to cause tags to be pruned.  Would somebody object to
> such a change?

I, personally, think what you outline makes more sense. Also, I'm curious if `git remote update -p $REMOTE` suffers from the same problem, if the remote was added with the `--tags` option.

-John
Previous: Michael HaggertyNext: Jeff King
Message 5 of 23 in “Local tag killer”
  1. Michael HaggertySep 13, 2013
  2. Junio C HamanoSep 13, 2013
  3. Junio C HamanoSep 20, 2013
  4. Michael HaggertySep 21, 2013
  5. John SzakmeisterSep 21, 2013
  6. Jeff KingSep 24, 2013
  7. Marc BranchaudSep 24, 2013
  8. Jeff KingSep 25, 2013
  9. Nicolas PitreSep 25, 2013
  10. Michael HaggertySep 28, 2013
  11. Johan HerlandSep 28, 2013
  12. Michael HaggertySep 29, 2013
  13. Johan HerlandSep 29, 2013
  14. Marc BranchaudSep 30, 2013
  15. Nicolas PitreSep 30, 2013
  16. Marc BranchaudSep 30, 2013
  17. Nicolas PitreSep 30, 2013
  18. Marc BranchaudSep 30, 2013
  19. Nicolas PitreSep 30, 2013
  20. Jeff KingSep 30, 2013
  21. Marc BranchaudOct 1, 2013
  22. Nicolas PitreOct 1, 2013
  23. Marc BranchaudOct 1, 2013

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.