From: Michael Haggerty <mhagger@alum.mit.edu>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, cmn@elego.de
Subject: Re: [PATCH 6/6] Add a REFNAME_ALLOW_UNNORMALIZED flag to check_ref_format()
Date: Sat, 10 Sep 2011 06:04:41 +0200 [thread overview]
Message-ID: <4E6AE1D9.9010004@alum.mit.edu> (raw)
In-Reply-To: <7vpqj9s385.fsf@alter.siamese.dyndns.org>
On 09/10/2011 01:30 AM, Junio C Hamano wrote:
> 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/
next prev parent reply other threads:[~2011-09-10 4:05 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-09 11:46 [PATCH 0/6] Improved infrastructure for refname normalization Michael Haggerty
2011-09-09 11:46 ` [PATCH 1/6] Change bad_ref_char() to return a boolean value Michael Haggerty
2011-09-09 11:46 ` [PATCH 2/6] git check-ref-format: add options --onelevel-ok and --refname-pattern Michael Haggerty
2011-09-09 11:46 ` [PATCH 3/6] Change check_ref_format() to take a flags argument Michael Haggerty
2011-09-09 11:46 ` [PATCH 4/6] Add a library function normalize_refname() Michael Haggerty
2011-09-09 11:46 ` [PATCH 5/6] Do not allow ".lock" at the end of any refname component Michael Haggerty
2011-09-09 11:46 ` [PATCH 6/6] Add a REFNAME_ALLOW_UNNORMALIZED flag to check_ref_format() Michael Haggerty
2011-09-09 23:30 ` Junio C Hamano
2011-09-10 4:04 ` Michael Haggerty [this message]
2011-09-09 14:06 ` [PATCH 0/6] Improved infrastructure for refname normalization A Large Angry SCM
2011-09-09 15:33 ` Michael Haggerty
2011-09-09 17:57 ` Junio C Hamano
2011-09-10 3:31 ` Michael Haggerty
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E6AE1D9.9010004@alum.mit.edu \
--to=mhagger@alum.mit.edu \
--cc=cmn@elego.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).