git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] git-prompt: show 'CONFLICT' indicator at command prompt

From
Junio C Hamano <gitster@pobox.com>
Date
Jul 28, 2022, 17:44 UTC
Message-ID
<xmqqpmhpb08p.fsf@gitster.g>
In-Reply-To
<CAGTqyRzfeh4HLbXUCb3Zv=bWNoBmvBU5QB=N2g2d0=y+NEToag@mail.gmail.com>
Justin Donnelly <justinrdonnelly@gmail.com> writes:
Show 15 quoted lines
>> 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.

Previous: Justin DonnellyNext: Justin Donnelly
Message 4 of 17 in “git-prompt: show 'CONFLICT' indicator at command prompt”
  1. git-prompt: show 'CONFLICT' indicator at command promptJustin Donnelly via GitGitGadget, Jul 26, 2022
  2. Junio C HamanoJul 27, 2022
  3. Justin DonnellyJul 28, 2022
  4. Junio C HamanoJul 28, 2022
  5. Justin DonnellyJul 28, 2022
  6. git-prompt: show presence of unresolved conflicts at command promptJustin Donnelly via GitGitGadget, Jul 29, 2022
  7. Justin DonnellyAug 14, 2022
  8. Junio C HamanoAug 15, 2022
  9. Johannes SchindelinAug 15, 2022
  10. Justin DonnellyAug 16, 2022
  11. Phillip WoodAug 15, 2022
  12. Junio C HamanoAug 15, 2022
  13. Justin DonnellyAug 16, 2022
  14. Justin DonnellyAug 16, 2022
  15. git-prompt: show presence of unresolved conflicts at command promptJustin Donnelly via GitGitGadget, Aug 17, 2022
  16. Johannes SchindelinAug 19, 2022
  17. Junio C HamanoAug 19, 2022

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.