Michael Haggerty <mhagger@xxxxxxxxxxxx> 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?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html