git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v3 0/5] push: update remote tags only with force

From
ABAngelo Borsotti <angelo.borsotti@gmail.com>
Date
Nov 14, 2012, 23:43 UTC
Message-ID
<CAB9Jk9CoCAnWtWGPXBq_rNKrdUBgxEcdu3ySzaG-XDnkJn=BvA@mail.gmail.com>
In-Reply-To
<7vmwykay4n.fsf@alter.siamese.dyndns.org>
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@pobox.com> wrote:
Show 36 quoted lines
> Angelo Borsotti <angelo.borsotti@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/".
>
Previous: Junio C HamanoNext: Junio C Hamano
Message 14 of 17 in “push: update remote tags only with force”
  1. 0/5 push: update remote tags only with forceChris Rorvick, Nov 12, 2012
  2. 1/5 push: return reject reasons via a maskChris Rorvick, Nov 12, 2012
  3. 2/5 push: add advice for rejected tag referenceChris Rorvick, Nov 12, 2012
  4. 3/5 push: flag updatesChris Rorvick, Nov 12, 2012
  5. 4/5 push: flag updates that require forceChris Rorvick, Nov 12, 2012
  6. 5/5 push: update remote tags only with forceChris Rorvick, Nov 12, 2012
  7. Junio C HamanoNov 13, 2012
  8. Drew NorthupNov 13, 2012
  9. Chris RorvickNov 14, 2012
  10. Kacper KornetNov 14, 2012
  11. Junio C HamanoNov 14, 2012
  12. Angelo BorsottiNov 14, 2012
  13. Junio C HamanoNov 14, 2012
  14. Angelo BorsottiNov 14, 2012
  15. Junio C HamanoNov 15, 2012
  16. Angelo BorsottiNov 15, 2012
  17. Junio C HamanoNov 15, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.