Jeff King venit, vidit, dixit 10.12.2009 13:49: > On Thu, Dec 10, 2009 at 01:23:43PM +0100, Michael J Gruber wrote: > >> Print the sha1 of the deleted tag (in addition to the tag name) so that >> one can easily recreate a mistakenly deleted tag: >> >> git tag -d tagname >> Deleted tag 'tagname' DEADBEEF >> git tag 'tagname' DEADBEEF # for lightweight tags >> git update-ref refs/tags/'tagname' DEADBEEF # for annotated tags > > I think this is a good idea, and we already do the same for branch > deletion. > > I'm not sure your example is right. If "tag -d" always prints out the > sha1 in the tag ref, can't you just use "git tag 'tagname' DEADBEEF" to > recreate both lightweight and annotated tags? That is, making a > lightweight tag of an annotated tag's sha1 should just recreate the > original annotated tag. While my example is right it is unnecessarily complex. I learned that through Björns and your remark. > That being said, I am not a fan of the cut-and-paste format. This is not > something that happens so frequently that I think we need to go out of > our way to save some typing. And for a user seeing this message for the > first time: > > 1. It is not immediately obvious to a user seeing this message > for this first time exactly what the trailing sha1 means. We > already had this discussion with "git branch -d" and decided > that "(was DEADBEEF)" was more readable. So, should we simply go with that then? Meanwhile, RFCs/PATCHes crossed paths. I take it that Zoltan suggests giving the same output for force-overwritten existing tags. I beat him by 11 minutes, though ;) Michael -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html