From: Eric Chamberland <Eric.Chamberland@giref.ulaval.ca>
To: "git@vger.kernel.org" <git@vger.kernel.org>
Subject: [feature request] 2) Remove many tags at once and 1) Prune tags on old-branch-before-rebase
Date: Thu, 07 Mar 2013 17:01:39 -0500 [thread overview]
Message-ID: <51390E43.60704@giref.ulaval.ca> (raw)
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
next reply other threads:[~2013-03-07 22:02 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-07 22:01 Eric Chamberland [this message]
2013-03-07 23:33 ` [feature request] 2) Remove many tags at once and 1) Prune tags on old-branch-before-rebase Junio C Hamano
2013-03-08 19:37 ` Eric Chamberland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51390E43.60704@giref.ulaval.ca \
--to=eric.chamberland@giref.ulaval.ca \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).