From: Matthias Andree Date: Fri, 15 May 2009 16:14:07 GMT Subject: Re: git-tag bug? confusing git fast-export with double tag objects Message-ID: In-Reply-To: <81b0412b0905150851q232b3f6s95df89e72d4dc381@mail.gmail.com> Am 15.05.2009, 17:51 Uhr, schrieb Alex Riesen : > 2009/5/15 Johannes Sixt : >> Jakub Narebski schrieb: >>> "Matthias Andree" writes: >>>>      commit <-- signed-by-- NIL (removed) <--signed-by-- tag1. >>> >>> THIS IS A FEATURE, NOT A BUG. >> >> Please stop it. Everone agrees about this. >> >> Matthias only wants a patch like below. Matthias, if you are serious >> about it, please pick this up and turn it into a proper submission. I >> don't care enough. >> > ... >> +       if ((tag_object = (struct tag *)parse_object(object)) && >> +           tag_object->object.type == OBJ_TAG && >> +           tag_object->tag && >> +           !strcmp(tag_object->tag, tag)) { >> +               error("A tag cannot tag itself. If you meant to tag the >> commit"); > > If it ever turned into submission, I'll always patch this out. It is > stupid. I seem to lack intermediate messages, probably queued somewhere, yet I'll respond already. Moving a tag on top of itself is just stupid. The result of git -f doesn't properly match documentation IMO. There is no clear consensus if it's "gone". It's gone from the refs/ namespace, but kept in the object space, so there's a split meaning of "replace" or "delete" here. Arguably, we already need to say -f once, but nothing prevents me from using git tag -d first and then tag the dangling old_tag1 object to revive it. Nobody has shown valid reasons of existence for such tags, or valid semantics, or use cases. It's confusing => usability problem => let's put a warning there. I'm not sure if "error()" is the right function to call here, since I don't have the full patch to look at. At any rate, a policy of obstruction is as invalid as anything. -- Matthias Andree