From: Junio C Hamano <gitster@pobox•com>
To: Michael Haggerty <mhagger@alum•mit.edu>
Cc: Jeff King <peff@peff•net>,
git@vger•kernel.org, cmn@elego•de,
A Large Angry SCM <gitzilla@gmail•com>,
Daniel Barkalow <barkalow@iabervon•org>,
Sverre Rabbelier <srabbelier@gmail•com>
Subject: Re: [PATCH 2/2] Restrict ref-like names immediately below $GIT_DIR
Date: Tue, 18 Oct 2011 22:28:33 -0700 [thread overview]
Message-ID: <7v39epft32.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <4E9609E3.1000300@alum.mit.edu> (Michael Haggerty's message of "Wed, 12 Oct 2011 23:42:59 +0200")
Michael Haggerty <mhagger@alum•mit.edu> writes:
>>> Nit: the seen_non_root_char variable can be replaced by an early "return
>>> 0" from the loop and "return 1" if the loop falls through.
>>
>> Hmm, I thought that would fail when you feed "refs/heads/master" to the
>> function.
>
> You're right. My brain must be scrambled from all of the rebasing that
> I have been doing ;-)
>
> How about adding
>
> /*
> * Accept strings that are either ALL_CAPS or include a '/'.
> */
>
> (I think the underscore is implied by the example, but the comment could
> be expanded if necessary to be explicit.)
I was trying to summarize this topic for Release Notes.
Possibly incompatible changes
-----------------------------
* Special refs such as "HEAD", "MERGE_HEAD", and "FETCH_HEAD" are now
restricted to names with only uppercase letters and underscore. All
other refs must live under refs/ namespace. Earlier, you could
confuse git by storing an object name in $GIT_DIR/tmp/junk and say
"git show tmp/junk", but this will no longer work.
But noticed that "git update-ref tmp/junk HEAD" does create such a ref
that won't be recognized, and "git check-ref-format tmp/junk" is happy.
I think we would need to restrict check_ref_format() so that these
commands (and possibly others, but I think that single function will cover
pretty much everything) also reject "tmp/junk" immediately below $GIT_DIR
as a bad string. Otherwise we cannot merge these fixups, which would mean
we would have to revert the "Clean up refname checks and normalization"
series, at least the part that started emitting the "warning", which is a
mess I would rather want to avoid.
Opinions on how to get us out of this mess?
next prev parent reply other threads:[~2011-10-19 5:28 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-15 21:10 [PATCH v3 00/22] Clean up refname checks and normalization Michael Haggerty
2011-09-15 21:10 ` [PATCH v3 01/22] t1402: add some more tests Michael Haggerty
2011-09-15 21:10 ` [PATCH v3 02/22] git check-ref-format: add options --allow-onelevel and --refspec-pattern Michael Haggerty
2011-09-15 21:10 ` [PATCH v3 03/22] Change bad_ref_char() to return a boolean value Michael Haggerty
2011-09-15 21:10 ` [PATCH v3 04/22] Change check_ref_format() to take a flags argument Michael Haggerty
2011-09-15 21:10 ` [PATCH v3 05/22] Refactor check_refname_format() Michael Haggerty
2011-09-15 21:10 ` [PATCH v3 06/22] Do not allow ".lock" at the end of any refname component Michael Haggerty
2011-09-15 21:10 ` [PATCH v3 07/22] Make collapse_slashes() allocate memory for its result Michael Haggerty
2011-09-15 21:10 ` [PATCH v3 08/22] Inline function refname_format_print() Michael Haggerty
2011-09-15 21:10 ` [PATCH v3 09/22] Change check_refname_format() to reject unnormalized refnames Michael Haggerty
2011-09-15 21:10 ` [PATCH v3 10/22] resolve_ref(): explicitly fail if a symlink is not readable Michael Haggerty
2011-09-15 21:10 ` [PATCH v3 11/22] resolve_ref(): use prefixcmp() Michael Haggerty
2011-09-15 21:10 ` [PATCH v3 12/22] resolve_ref(): only follow a symlink that contains a valid, normalized refname Michael Haggerty
2011-09-15 21:10 ` [PATCH v3 13/22] resolve_ref(): turn buffer into a proper string as soon as possible Michael Haggerty
2011-09-23 8:17 ` Thomas Rast
2011-09-23 13:11 ` Michael Haggerty
2011-09-23 13:38 ` [PATCH 1/1] get_sha1_hex(): do not read past a NUL character Michael Haggerty
2011-09-23 18:59 ` Junio C Hamano
2011-10-05 19:11 ` Thomas Rast
2011-10-05 20:37 ` Junio C Hamano
2011-09-15 21:10 ` [PATCH v3 14/22] resolve_ref(): extract a function get_packed_ref() Michael Haggerty
2011-09-15 21:10 ` [PATCH v3 15/22] resolve_ref(): do not follow incorrectly-formatted symbolic refs Michael Haggerty
2011-09-15 21:10 ` [PATCH v3 16/22] remote: use xstrdup() instead of strdup() Michael Haggerty
2011-09-15 21:10 ` [PATCH v3 17/22] remote: avoid passing NULL to read_ref() Michael Haggerty
2011-09-15 21:10 ` [PATCH v3 18/22] resolve_ref(): verify that the input refname has the right format Michael Haggerty
2011-09-15 21:10 ` [PATCH v3 19/22] resolve_ref(): emit warnings for improperly-formatted references Michael Haggerty
2011-10-11 16:16 ` Jeff King
2011-10-11 17:53 ` Junio C Hamano
2011-10-11 18:07 ` Junio C Hamano
2011-10-11 20:14 ` Re* " Junio C Hamano
2011-10-11 20:39 ` Jeff King
2011-10-11 21:31 ` Junio C Hamano
2011-10-11 22:54 ` Jeff King
2011-10-12 16:52 ` Junio C Hamano
2011-10-11 23:07 ` Jeff King
2011-10-11 23:50 ` Junio C Hamano
2011-10-12 2:11 ` Jeff King
2011-10-12 4:41 ` Junio C Hamano
2011-10-12 4:50 ` Jeff King
2011-10-12 17:48 ` [PATCH 1/2] refs.c: move dwim_ref()/dwim_log() from sha1_name.c Junio C Hamano
2011-10-12 17:49 ` [PATCH 2/2] Restrict ref-like names immediately below $GIT_DIR Junio C Hamano
2011-10-12 18:01 ` Michael Haggerty
2011-10-12 18:07 ` Junio C Hamano
2011-10-12 21:42 ` Michael Haggerty
2011-10-12 22:26 ` Junio C Hamano
2011-10-19 5:28 ` Junio C Hamano [this message]
2011-10-19 6:19 ` Junio C Hamano
2011-10-19 15:18 ` Michael Haggerty
2011-10-19 17:10 ` Junio C Hamano
2011-10-19 19:29 ` Junio C Hamano
2011-10-19 19:39 ` [PATCH] resolve_ref(): report breakage to the caller without warning Junio C Hamano
2011-10-19 20:31 ` [PATCH 2/2] Restrict ref-like names immediately below $GIT_DIR Michael Haggerty
2011-10-19 20:39 ` Junio C Hamano
2011-10-12 21:51 ` Jeff King
2011-10-12 2:56 ` Re* [PATCH v3 19/22] resolve_ref(): emit warnings for improperly-formatted references Michael Haggerty
2011-10-12 19:20 ` Junio C Hamano
2011-10-12 19:26 ` Jeff King
2011-09-15 21:10 ` [PATCH v3 20/22] resolve_ref(): also treat a too-long SHA1 as invalid Michael Haggerty
2011-09-15 21:10 ` [PATCH v3 21/22] resolve_ref(): expand documentation Michael Haggerty
2011-09-15 21:10 ` [PATCH v3 22/22] add_ref(): verify that the refname is formatted correctly 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=7v39epft32.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox$(echo .)com \
--cc=barkalow@iabervon$(echo .)org \
--cc=cmn@elego$(echo .)de \
--cc=git@vger$(echo .)kernel.org \
--cc=gitzilla@gmail$(echo .)com \
--cc=mhagger@alum$(echo .)mit.edu \
--cc=peff@peff$(echo .)net \
--cc=srabbelier@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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