On Thu, Jul 28, 2022 at 1:44 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > 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. > Thanks. I'll incorporate these suggestions into a re-roll.
