Hi Junio,

> That is an independent issue of deciding to accept or reject
> receiving a push from outside, no?

Yes, it is. Actually I thought some means to let the owner do decide
what to accept were already present (the pushNonFastForward config
key), and going along this avenue I thought it could be appropriate to
extent this a bit.


On 14 November 2012 18:32, Junio C Hamano <gits...@pobox.com> wrote:
> Angelo Borsotti <angelo.borso...@gmail.com> writes:
>> 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.
> That is an independent issue of deciding to accept or reject
> receiving a push from outside, no?  You can implement any such
> policy in the pre-receive hook on the receiving end with a simple
> and clear manner, instead of adding specific logic to enforce a
> single hardcoded policy to the code that is flipped on with a
> configuration variable.
> In any case, I thought this series was about users who run "push"
> voluntarily stopping themselves from pushing updates to tags that
> may happen to fast-forward, so if we were to go with the
> configuration route, the suggestion would be more like
>     [push]
>         updateNeedsForce = refs/tags/:refs/frotz/
> or perhaps
>     [remote "origin"]
>         updateNeedsForce = refs/tags/:refs/frotz/
> if we want to configure it per-remote, to specify that you would
> need to say "--force" to update the refs in the listed hierarchies.
> Then your patch series could become just the matter of declaring
> that the value of push.updateNeedsForce, when unspecified, defaults
> to "refs/tags/".
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

Reply via email to