Re: git-tag bug? confusing git fast-export with double tag objects
- From
- Matthias Andree <matthias.andree@gmx.de>
- Date
- May 15, 2009, 16:14 UTC
- Message-ID
- <op.utzbdtb91e62zd@merlin.emma.line.org>
- In-Reply-To
- <81b0412b0905150851q232b3f6s95df89e72d4dc381@mail.gmail.com>
Am 15.05.2009, 17:51 Uhr, schrieb Alex Riesen <raa.lkml@gmail.com>:
Show 23 quoted lines
> 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