Richard Hansen <rhan...@bbn.com> writes:
>> and plan for transition to forbid them
>> everywhere in a next big version bump (it is too late for 2.0).
>
> Would it be acceptable to have a config option to forbid these in a
> non-major version bump?
Of course ;-) Because we try very hard to avoid a "flag day" change,
any "plan for transition" inevitably has to include what we need to
do _before_ the big version bump.
> If it's OK to have a config option, then here's one possible transition
> path (probably flawed, but my intent is to bootstrap discussion):
>
> 1. Add an option to forbid dangerous characters. The option defaults
> to disabled for compatibility. If the option is unset, print a
> warning upon encountering a ref name that would be forbidden.
> 2. Later, flip the default to enabled.
> 3. Later, in the weeks/months leading up to the next major version
> release, print the warning even if the config option is set to
> disabled.
Sounds fairly conservative and nice. We may want to treat creating
a new such ref and using an existing such ref differently, though,
and that might give us a better/smoother transition (as you are, I
am just thinking aloud).
For example, it might be sufficient to do these two things:
(1) upon an attempt to use an existing such ref, warn and encourage
renaming of the ref.
(2) upon an attempt to create a new one, error it out.
in the first step, and in either case, tell the user about the
loosening variable.
Going that route may shorten the time until the initial safety.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
