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 15, 2012, 07:48 UTC
Message-ID
<CAB9Jk9DK9AWBe_cf6=-v0pyD9xdhSoYPsKmRnUOwjuAm=hewfA@mail.gmail.com>
In-Reply-To
<7v8va3afrt.fsf@alter.siamese.dyndns.org>
Hi Junio,
> I am *not* convinced that the "refs/tags/ is the only special
> hierarchy whose contents should not move" is a bad limitation we
> should avoid, but if it indeed is a bad limitation, the above is one
> possible way to think about avoiding it.

What other hierarchy besides branches and tags is there? Do you have in mind some other that should not move?

-Angelo
On 15 November 2012 01:09, Junio C Hamano <gitster@pobox.com> wrote:
Show 38 quoted lines
> Junio C Hamano <gitster@pobox.com> writes:
>
> Addendum.
>
>> 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/".
>
> The above is not a "you should do it this way" suggestion, by the
> way.
>
> I was just explaining what I meant by "it may be a good feature, but
> may not necessarily be limited to refs/tags" in my earlier message
> in a different way "... and a possible design that lifts the
> limitation may go like this".
>
> I am *not* convinced that the "refs/tags/ is the only special
> hierarchy whose contents should not move" is a bad limitation we
> should avoid, but if it indeed is a bad limitation, the above is one
> possible way to think about avoiding it.
>
> Thanks.
Previous: Junio C HamanoNext: Junio C Hamano
Message 16 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.