Justin Donnelly <justinrdonnelly@xxxxxxxxx> 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.
