Angelo Borsotti [off-list ref] 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/".
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.
-Angelo
On 14 November 2012 18:32, Junio C Hamano [off-list ref] wrote:
Angelo Borsotti [off-list ref] writes:
quoted
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/".