Am 15.05.2009, 17:51 Uhr, schrieb Alex Riesen <raa.lkml@gmail.com>:

quoted text
> 2009/5/15 Johannes Sixt <j.sixt@viscovery.net>:
>> Jakub Narebski schrieb:
>>> "Matthias Andree" <matthias.andree@gmx.de> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html