Proposal for pruning tags

Proposal for pruning tags

[Robert Dailey]

I've never contributed to the Git project before. I'm a Windows user,
so I use msysgit, but I'd be happy to install linux just so I can help
implement this feature if everyone feels it would be useful.

Right now AFAIK, there is no way to prune tags through Git. The way I
currently do it is like so:

$ git tag -l | xargs git tag -d
$ git fetch --all

This is not only wasteful, but dangerous. I might accidentally delete
a local tag I haven't pushed yet. What would be great is if we had the
following:

git tag prune [<remote>|--all]

The <remote> is needed in decentralized workflows (upstream vs
origin). I'd also like to see an `--all` option in place of the
remote, which means it will prune local tags from all remotes. I'm not
sure if this command line structure will work, but it can be altered
as necessary.

Alternatively, this might also make sense on the remote command:

git remote prune <remote> --tags

Again I'm not an expert at the internals of Git, so I wanted to share
my idea with the community first to see if this holds water or if
there is already some built in way of doing this. Thanks for hearing
out my idea!

Re: Proposal for pruning tags

[Junio C Hamano]

Robert Dailey <rcdailey.lists@gmail.com> writes:

> I've never contributed to the Git project before. I'm a Windows user,
> so I use msysgit, but I'd be happy to install linux just so I can help
> implement this feature if everyone feels it would be useful.
>
> Right now AFAIK, there is no way to prune tags through Git. The way I
> currently do it is like so:
>
> $ git tag -l | xargs git tag -d
> $ git fetch --all

I think you need to explain what you mean by "prune" a lot better
than what you are doing in your message to be understood by others.

After seeing the above two commands, my *guess* of what you want to
do is to remove any of your local tag that is *not* present in the
repository you usually fetch from (aka "origin"), but that directly
contradicts with what you said you wish, i.e.

> This is not only wasteful, but dangerous. I might accidentally delete
> a local tag I haven't pushed yet...

which only shows that your definition of "prune" is different from
"remove what I do not have at 'origin'".

But it does not say *how* that is different.  How should "prune"
behave differently from the two commands above?  How does your
"prune" decide a tag needs to be removed locally when it is not at
your "origin" [*1*]?

There is *nothing* in git that lets you look at a local tag that is
missing from the other side and determine if that is something you
did not want to push (hence it is missing there) of if that is
something you forgot to push (hence it is missing there but you
would rather have pushed if you did not forget).  So you must have
some new mechanism to record and/or infer that distinction in mind,
but it is not clear what it is from your message.

So until that is clarified, there is not much more to say if your
"feature" has any merit---as there is no way to tell what that
"feature" exactly is, at least not yet ;-)


[Footnote]

*1* By the way, removing and then refetching would be a silly way to
    do this kind of thing anyway.  After removing but before you
    have a chance to fetch, your ISP may severe your network
    connection and then what happens?

    Whatever your definition of "prune" is, I would think it would
    be built around "ls-remote --tags" output, to see what tags the
    other repository (or other repositories, by looping over the
    remotes you interact with) have, compare that set with the tags
    you locally have in order to decide which subset of tags you
    locally have to remove.

Re: Proposal for pruning tags

[Robert Dailey]

On Thu, Jun 5, 2014 at 3:50 PM, Junio C Hamano <gitster@pobox.com> wrote:
> I think you need to explain what you mean by "prune" a lot better
> than what you are doing in your message to be understood by others.
>
> After seeing the above two commands, my *guess* of what you want to
> do is to remove any of your local tag that is *not* present in the
> repository you usually fetch from (aka "origin"), but that directly
> contradicts with what you said you wish, i.e.
>
>> This is not only wasteful, but dangerous. I might accidentally delete
>> a local tag I haven't pushed yet...
>
> which only shows that your definition of "prune" is different from
> "remove what I do not have at 'origin'".
>
> But it does not say *how* that is different.  How should "prune"
> behave differently from the two commands above?  How does your
> "prune" decide a tag needs to be removed locally when it is not at
> your "origin" [*1*]?
>
> There is *nothing* in git that lets you look at a local tag that is
> missing from the other side and determine if that is something you
> did not want to push (hence it is missing there) of if that is
> something you forgot to push (hence it is missing there but you
> would rather have pushed if you did not forget).  So you must have
> some new mechanism to record and/or infer that distinction in mind,
> but it is not clear what it is from your message.
>
> So until that is clarified, there is not much more to say if your
> "feature" has any merit---as there is no way to tell what that
> "feature" exactly is, at least not yet ;-)
> <snip>

You're right I didn't clarify, although I feel you're not providing
the most welcome response to someone who isn't as familiar with the
internals of Git as you are.

It was an oversight on my part. What I was expecting is that it would
behave exactly like branch pruning does, but that would require
"remote tracking tags", which we don't have. So, apparently my idea
doesn't hold much water.

The general problem I see in the day to day workflow with my team is
that if tags exist locally and they push, those tags continuously get
recreated on the remote repo even after I delete them remotely. So I
can never truly delete tags until I go to each person and make sure
the tool they're using isn't accidentally pushing tags. For example,
SourceTree pushes all tags by default. Everyone on my team is new to
Git, so they don't know to turn that off. Having git clean up tags
automatically would really help with this, even though you may not
feel it's the responsibility of Git. It's more of a usability issue,
it's just prone to error.

I can setup my config to prune tracking branches after I pull. Having
something like this for tags would be wonderful. However, this
requires a bigger overhaul than what I initially was proposing.

Re: Proposal for pruning tags

[Junio C Hamano]

Robert Dailey <rcdailey.lists@gmail.com> writes:

> ... Having git clean up tags
> automatically would really help with this, even though you may not
> feel it's the responsibility of Git. It's more of a usability issue,

I agree with "Having ... help with this".  I did not say at all that
it is not something Git should and can try to help.  I also agree
with it is a usability issue.

The thing is, the word "automatically" in your "clean up tags
automatically" is still too loose a definition of what we want, and
we cannot come up with a way to help users without tightening that
looseness.  As you said, you are looking for something that can tell
between two kinds of tags that locally exist without having a copy
at the 'origin':

 - ones that you do not want to keep
 - others that you haven't pushed to (or forgot to push to) 'origin'

without giving the users a way to help Git to tell these two kinds
apart and only remove the former.

So...

Re: Proposal for pruning tags

[Michael Haggerty]

On 06/05/2014 04:51 PM, Robert Dailey wrote:
> I've never contributed to the Git project before. I'm a Windows user,
> so I use msysgit, but I'd be happy to install linux just so I can help
> implement this feature if everyone feels it would be useful.
> 
> Right now AFAIK, there is no way to prune tags through Git. The way I
> currently do it is like so:
> 
> $ git tag -l | xargs git tag -d
> $ git fetch --all

Junio explained some limitations of tags (namely that there is only one
tags namespace that is shared project-wide) that makes your wish
impossible to implement the way it works for branches.

Local tags are awkward for the same reason.  It is too easy to push them
accidentally to a central repository and too hard to delete them after
that has happened.  They kindof spread virally, as you have noticed.  I
recommend against using local tags in general.

Recent Git does have a feature that might help you.  *If* you have a
central repository that is "authoritative" WRT tags, then you can sync
the tags in your local repository to the tags in the central repo using

    git fetch --prune $REMOTE +refs/tags/*:refs/tags/*

You might also be able to use a pre-receive hook on the central repo to
prevent tags from being pushed by people who shouldn't be doing so, or
to require that tags have an approved format (like
refs/tags/release-\d+\.\d+\.\d+ or whatever) to try to prevent a
recurrence of the problem.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/