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

Re: [PATCH 6/6] Add a REFNAME_ALLOW_UNNORMALIZED flag to check_ref_format()

From
Michael Haggerty <mhagger@alum.mit.edu>
Date
Sep 10, 2011, 04:04 UTC
Message-ID
<4E6AE1D9.9010004@alum.mit.edu>
In-Reply-To
<7vpqj9s385.fsf@alter.siamese.dyndns.org>
On 09/10/2011 01:30 AM, Junio C Hamano wrote:
Show 12 quoted lines
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>> Let the callers of check_ref_format() (and normalize_refname()) decide
>> whether to accept unnormalized refnames via a new
>> REFNAME_ALLOW_UNNORMALIZED flag.  Change callers to set this flag,
>> which preserves their current behavior.  (There are likely places
>> where this flag can be removed.)
> 
> [...]
> To put it another way, my knee jerk reaction is that we shouldn't need
> such a "flag". Shouldn't it be sufficient for normalize_refname() and
> nothing else to allow unnormalized input, and everybody else should barf
> when they see an un-normalized input?
That is a good idea.

I will make the current normalize_refname() function static and hide the REFNAME_ALLOW_UNNORMALIZED option from the outside world. Then I will write a new public normalize_refname() function that calls the static version with REFNAME_ALLOW_UNNORMALIZED set, and change check_ref_format() to call normalize_refname() with REFNAME_ALLOW_UNNORMALIZED unset.

What should I do with all of the current callers of check_ref_format(), given that I don't want to be personally responsible for analyzing and rewriting them all? The hard-nosed approach would be to say that they are calling check_ref_format() without normalizing the refnames, so they are already broken (albeit perhaps sometimes accidentally functional), and it is OK that the new behavior of check_ref_format() causes them to fail explicitly.

A more forgiving approach would be to implement another transition function like check_ref_format_deprecated_unsafe() that accepts unnormalized refnames, change the callers to use this function during the transition, and remove it only after all callers have been fixed.

Suggestions?
Michael
-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
Previous: Junio C HamanoNext: A Large Angry SCM
Message 9 of 13 in “Improved infrastructure for refname normalization”
  1. 0/6 Improved infrastructure for refname normalizationMichael Haggerty, Sep 9, 2011
  2. 1/6 Change bad_ref_char() to return a boolean valueMichael Haggerty, Sep 9, 2011
  3. 2/6 git check-ref-format: add options --onelevel-ok and --refname-patternMichael Haggerty, Sep 9, 2011
  4. 3/6 Change check_ref_format() to take a flags argumentMichael Haggerty, Sep 9, 2011
  5. 4/6 Add a library function normalize_refname()Michael Haggerty, Sep 9, 2011
  6. 5/6 Do not allow ".lock" at the end of any refname componentMichael Haggerty, Sep 9, 2011
  7. 6/6 Add a REFNAME_ALLOW_UNNORMALIZED flag to check_ref_format()Michael Haggerty, Sep 9, 2011
  8. Junio C HamanoSep 9, 2011
  9. Michael HaggertySep 10, 2011
  10. A Large Angry SCMSep 9, 2011
  11. Michael HaggertySep 9, 2011
  12. Junio C HamanoSep 9, 2011
  13. Michael HaggertySep 10, 2011

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.