Am 15.05.2009, 17:51 Uhr, schrieb Alex Riesen <raa.lkml@xxxxxxxxx>:
2009/5/15 Johannes Sixt <j.sixt@xxxxxxxxxxxxx>:
Jakub Narebski schrieb:
"Matthias Andree" <matthias.andree@xxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html