Show 35 quoted lines
>
> Justin Donnelly <justinrdonnelly@gmail.com> writes:
>
> >> It is unusual to subject our unsuspecting users to new features in a
> >> way that is done by this patch. A more usual practice, I think, is
> >> to tell the users that they can set GIT_PS1_INCLUDECONFLICTSTATE to
> >> "yes" if they want to opt in, and trigger the new feature only to
> >> them. Later, we may decide that the feature is useful and widely
> >> apprlicable enough, at which time it may be turned on by default and
> >> tell the users to set GIT_PS1_INCLUDECONFLICTSTATE to "no" if they
> >> do not want to see it. But one step at a time.
> >>
> >
> > I see that most of the state indicators are disabled by default, so it
> > makes sense to be consistent. Should I make a variable with 'yes'/'no'
> > values, or set/unset? 'yes'/'no' has the benefit that if the default
> > is later changed, existing setups will continue to work. Set/unset
> > makes it harder to change the default later ...
>
> As you said, "an environment variable that is set triggers the
> feature" is harder to transition. Starting from a clear Boolean is
> probably easy to see what is going on, and that is why I suggested
> doing that way.
>
> Ones that are "if set, enabled" can be corrected later when needed,
> e.g. GIT_PS1_FROTZ may enable the feature FROTZ when the environment
> is set, but when we introduce two or more ways to do FROTZ thing
> (e.g. in addition to always do FROTZ, which may be the original
> design of "an environment that is set triggers the feature", we may
> add "automatically enable FROTZ only under this and that
> condition"), we may say "when set to 'auto', do the auto-FROTZ, and
> when set to 'yes', do FROTZ as we have always done. When set to any
> other value, warn and then do FROTZ"). But let's leave them outside
> the scope of the topic.
>
Justin Donnelly <justinrdonnelly@gmail.com>