[feature request] 2) Remove many tags at once and 1) Prune tags on old-branch-before-rebase

Hi,

============================ Short story: ============================ we are now using *annotated* tags in a way that we would need to manage (remove) them easily. It would be usefull to have one of the folowing in "git tag":

1) git tag --delete-tags-to-danglings-and-unnamed-banches

This would be able to remove all tags that refers to commits which are on branches that are no more referenced by any branch name. This is happening when you tag something, then "git rebase". Your tag will still be there on the old-and-before-rebase branch and won't be "pruned" by any git command... (that I know of...)

Then you will end up to delete all of them "by hand"...

to do so you would like to have:

2) git tag -d "TOKEN*"

This would be able to delete all tags referred by the name. Ok ok, I can do this like this:

rm .git/refs/tags/TOKEN*

but why have the git users "play" into the .git...?

============================

---------------------------------------- Long story: ----------------------------------------

We started using annotated tags to hold information about the code "status", ie the results of our regression tests are stored in annotated tags each time you do a "make test" in the distribution. We can retrieve the information by "git show" which we aliased to parse the output, extract the ".html" that we stored in the tag message (about 67kb) and then display the "make test" results as a web page in a browser... ;-)

We also "resume" the information on the number of "(P)assed" and "(F)ailed" tests in the tag name to quickly view the overall status of the code in the local clone. For example, we end up with tags name like these:

SQA_ericc_ad76kj78_P_155_F_0

as a result of: SQA_${USER}_${SHA}_P_${PASSED}_F_${FAILED}

However, the number of tags increases as you do many "make test" to validate your developments and see the progressions you do.

Moreover, when you "git fetch" from colleagues, you retrieve their annotated tags too, which is nice, since you can view the results of the regression tests they have done, which can contain useful information to share...

BUT, when your colleagues delete their old tags because they rebased, you don't have the possibility to "git fetch --prune-tags", so you are left with all those "old" tags hanging all around and would like to easily remove them...

Because you know that no more branches are associated with the tip commit of all those "old-before-rebased-branches", you would like something like feature request #1 to automagically do the job you do by hand in feature request #2... ;-)

Ok, we shall not rebase but merge, but this is another long story... ;-)

Hope all this might be useful to other, so if other people start using tags like this, more will hope to have these features... ;-) ----------------------------------------

thanks,

Eric

Eric Chamberland <Eric.Chamberland@giref.ulaval.ca> writes:

Not interesting for at least two reasons.

Why are "tags" any special? "git branch --delete-merged" may also be of interest, and for that matter "git update-ref -d" to deal with any ref in general would be equally valid if such an option were a good idea.

What you want is a way to compute, given a set of tags (or refs in general) and a set of branches (or another set of refs in general), find the ones in the former that none of the latter can reach. With that, you can drive "git tag -d $(that way)".

In other words, the feature does not belong to "git tag" command.

Again, not interesting.  You already have:

    git for-each-ref --format='%(refname:short)' refs/tags/TOKEN\* |
    xargs -r git tag -d

Hi Junio,

On 03/07/2013 06:33 PM, Junio C Hamano wrote:

Yes, this is *exactly* what I want...

I don't agree here for one reason:

git tag -l "TOKEN*"

already exists and works very well...

So why is it not interesting to have:

git tag -d "TOKEN*"

?

We can also write:

git tag -d `git tag -l "TOKEN*"`

but a simple addition to "-d" feature looks like a receivable behavior here, no?

Thanks,

Eric