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 <gitster@xxxxxxxxx> wrote: > Angelo Borsotti <angelo.borsotti@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html