actually, I proposed to add a key in config files, e.g.
pushTagsNoChange to be set in the remote repo do disallow changes to
tags, similar to pushNonFastForward that disallows non-fastforward
changes to branches. I still have the impression that this is simple
and clear, and allows the owner of the remote repository to enforce
the policy s/he wants on her/his repository.
On 14 November 2012 14:22, Junio C Hamano <gits...@pobox.com> wrote:
> Chris Rorvick <ch...@rorvick.com> writes:
>>> "Do not update, only add new" may be a good feature, but at the same
>>> time I have this suspicion that its usefulness may not necessarily
>>> be limited to refs/tags/* hierarchy.
>>> I dunno.
>> Are you suggesting allowing forwards for just refs/heads/*?
> No, it is a nonsense to unconditionally forbid fast-forwards to refs
> outside refs/heads/ hierarchy.
> I was imagining a more general feature to allow the *user* to ask
> Git not to fast-forward some refs (not limited to refs/tags/) during
> a push.
> If such a general feature were in place, you can think of your patch
> as automatically making the user to ask Git not to fast-forward refs
> in refs/tags/, which would be a mere special case of it.
> And I was wondering if such a general feature makes sense.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html