{"thread":{"id":"57941","subject":"[RFC PATCH] git-prompt: make colourization consistent","startedAt":"2022-06-01T13:51:53Z","lastAt":"2022-06-11T09:01:44Z","messageCount":43,"participants":["Joakim Petersen","Ævar Arnfjörð Bjarmason","Junio C Hamano","joak-pet@online.no","Justin Donnelly","Bagas Sanjaya","SZEDER Gábor"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"456444","messageId":"20220601134414.66825-1-joak-pet@online.no","threadId":"57941","inReplyTo":null,"subject":"[RFC PATCH] git-prompt: make colourization consistent","fromName":"Joakim Petersen","fromEmail":"joak-pet@online.no","sentAt":"2022-06-01T13:44:14Z","receivedAt":"2022-06-01T13:51:53Z","isPatch":true,"sender":{"key":"joak-pet@online.no","avatar":"https://avatars.githubusercontent.com/u/107927072?v=4"},"body":"The short upstream state indicator inherits the colour of the last short\nstate indicator before it (if there is one), and the sparsity state\nindicator inherits this colour as well. Make the colourization of these\nstate indicators consistent by clearing any colour before printing the\nshort upstream state indicator, as this immediately follows the last\ncoloured indicator.\n\nSigned-off-by: Joakim Petersen <joak-pet@online.no>\n---\nAs of 0ec7c23cdc6bde5af3039c59e21507adf7579a99, colourization of the\noutput of __git_ps1 has changed such that the short upstream state\nindicator inherits the colour of the last short state indicator before\nit (if there is one), while before this change it was white/the default\ntext colour. Some examples of what I mean are (assuming all indicators\nare enabled):\n * If the local tree is clean and there is something in the stash, both\n   the '$' and the short upstream state indicator following it will be\n   blue.\n * If the local tree has new, untracked files, both the '%' and the\n   short upstream state indicator will be red.\n * If all local changes are added to the index and the stash is empty,\n   both the '+' and the short upstream state indicator following it will\n   be green.\n * If the local tree is clean and there is nothing in the stash, the\n   short upstream state indicator will be white/${default text colour}.\n\nThis appears to be an unintended side-effect of the change, and makes\nlittle sense semantically (e.g. why is it bad to be in sync with\nupstream when you have uncommitted local changes?). The cause of the\nchange is that previously, the short upstream state indicator appeared\nimmediately after the rebase/revert/bisect/merge state indicator, which\nis prepended with the clear colour code, while it now follows the\nsequence of colourized indicators, without any clearing of colour.\nHowever, adding a clearing of colour before the short upstream state\nindicator will change how the sparsity state indicator is colourized,\nas it currently inherits (and before the change referenced also\ninherited) the colour of the last short state indicator before it.\nReading the commit message of the change that introduced the sparsity\nstate indicator, it appears this colourization also was unintended.\n\n contrib/completion/git-prompt.sh | 1 +\n 1 file changed, 1 insertion(+)\n\ndiff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh\nindex 87b2b916c0..dfd6cef35f 100644\n--- a/contrib/completion/git-prompt.sh\n+++ b/contrib/completion/git-prompt.sh\n@@ -286,6 +286,7 @@ __git_ps1_colorize_gitstring ()\n \tif [ -n \"$u\" ]; then\n \t\tu=\"$bad_color$u\"\n \tfi\n+\tp=\"$c_clear$p\"\n \tr=\"$c_clear$r\"\n }\n \n\nbase-commit: e54793a95afeea1e10de1e5ad7eab914e7416250\n-- \n2.36.1\n\n"},{"id":"456445","messageId":"220601.864k141ls0.gmgdl@evledraar.gmail.com","threadId":"57941","inReplyTo":"20220601134414.66825-1-joak-pet@online.no","subject":"Re: [RFC PATCH] git-prompt: make colourization consistent","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2022-06-01T14:47:46Z","receivedAt":"2022-06-01T14:49:42Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Wed, Jun 01 2022, Joakim Petersen wrote:\n\n> The short upstream state indicator inherits the colour of the last short\n> state indicator before it (if there is one), and the sparsity state\n> indicator inherits this colour as well. Make the colourization of these\n> state indicators consistent by clearing any colour before printing the\n> short upstream state indicator, as this immediately follows the last\n> coloured indicator.\n>\n> Signed-off-by: Joakim Petersen <joak-pet@online.no>\n> ---\n> As of 0ec7c23cdc6bde5af3039c59e21507adf7579a99, colourization of the\n> output of __git_ps1 has changed such that the short upstream state\n> indicator inherits the colour of the last short state indicator before\n> it (if there is one), while before this change it was white/the default\n> text colour. Some examples of what I mean are (assuming all indicators\n> are enabled):\n>  * If the local tree is clean and there is something in the stash, both\n>    the '$' and the short upstream state indicator following it will be\n>    blue.\n>  * If the local tree has new, untracked files, both the '%' and the\n>    short upstream state indicator will be red.\n>  * If all local changes are added to the index and the stash is empty,\n>    both the '+' and the short upstream state indicator following it will\n>    be green.\n>  * If the local tree is clean and there is nothing in the stash, the\n>    short upstream state indicator will be white/${default text colour}.\n>\n> This appears to be an unintended side-effect of the change, and makes\n> little sense semantically (e.g. why is it bad to be in sync with\n> upstream when you have uncommitted local changes?). The cause of the\n> change is that previously, the short upstream state indicator appeared\n> immediately after the rebase/revert/bisect/merge state indicator, which\n> is prepended with the clear colour code, while it now follows the\n> sequence of colourized indicators, without any clearing of colour.\n> However, adding a clearing of colour before the short upstream state\n> indicator will change how the sparsity state indicator is colourized,\n> as it currently inherits (and before the change referenced also\n> inherited) the colour of the last short state indicator before it.\n> Reading the commit message of the change that introduced the sparsity\n> state indicator, it appears this colourization also was unintended.\n>\n>  contrib/completion/git-prompt.sh | 1 +\n>  1 file changed, 1 insertion(+)\n>\n> diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh\n> index 87b2b916c0..dfd6cef35f 100644\n> --- a/contrib/completion/git-prompt.sh\n> +++ b/contrib/completion/git-prompt.sh\n> @@ -286,6 +286,7 @@ __git_ps1_colorize_gitstring ()\n>  \tif [ -n \"$u\" ]; then\n>  \t\tu=\"$bad_color$u\"\n>  \tfi\n> +\tp=\"$c_clear$p\"\n>  \tr=\"$c_clear$r\"\n>  }\n>  \n>\n> base-commit: e54793a95afeea1e10de1e5ad7eab914e7416250\n\nThis seems to make sense to me, but I haven't looked deeply into it. But\nlet's CC the author of 0ec7c23cdc6 (git-prompt: make upstream state\nindicator location consistent, 2022-02-27) (which I've done here).\n\nFor a non-RFC patch I think a rephrasing of most of what yo uhave below\n\"--\" should be part of the message. Note how I referred to the\n0ec... commit above, you should reference the commit like that (see\nSubmittingPatches).\n\nThanks for working on this fix!\n \n"},{"id":"456455","messageId":"xmqq7d60tfyd.fsf@gitster.g","threadId":"57941","inReplyTo":"20220601134414.66825-1-joak-pet@online.no","subject":"Re: [RFC PATCH] git-prompt: make colourization consistent","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-06-01T18:07:54Z","receivedAt":"2022-06-01T18:08:05Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Joakim Petersen <joak-pet@online.no> writes:\n\n> The short upstream state indicator inherits the colour of the last short\n> state indicator before it (if there is one), and the sparsity state\n> indicator inherits this colour as well. Make the colourization of these\n> state indicators consistent by clearing any colour before printing the\n> short upstream state indicator, as this immediately follows the last\n> coloured indicator.\n>\n> Signed-off-by: Joakim Petersen <joak-pet@online.no>\n> ---\n\n> diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh\n> index 87b2b916c0..dfd6cef35f 100644\n> --- a/contrib/completion/git-prompt.sh\n> +++ b/contrib/completion/git-prompt.sh\n> @@ -286,6 +286,7 @@ __git_ps1_colorize_gitstring ()\n>  \tif [ -n \"$u\" ]; then\n>  \t\tu=\"$bad_color$u\"\n>  \tfi\n> +\tp=\"$c_clear$p\"\n>  \tr=\"$c_clear$r\"\n>  }\n\nHmph, am I correct to understand that the general flow of __git_ps1 is \n\n (1) various pieces of information like $h, $w, $i, $s, $r, $b, $p,\n     etc.  are declared \"local\" and values computed for them,\n     either inside __git_ps1() itself, or by various helper\n     functions it calls;\n\n (2) When GIT_PS1_SHOWCOLORHINTS is in effect, we may call the\n     __git_ps1_colorize_gitstring helper (which is touched by the\n     above hunk), that modifies these variables with color codes.\n     Upon entry to this helper function, these variables prepared in\n     (1) have no color effects.  Upon leaving, they do.\n\n (3) Finally, the PS1 is asseembled by concatenating these\n     variables, whose text was prepared in (1) and then prefixed by\n     color codes in (2), one of the earliest steps begins like so:\n\n     local f=\"$h$w$i$s$u\"\n     local gitstring=\"$c$b${f:+$z$f}${sparse}$r$p\"\n\nIn the final step of formulation, $p immediately follows $r in the\nresulting $PS1, and the existing code at the end of the (2) prefixes\n$c_clear before $r, and $r before such prefixing is free of coloring,\nso it is curious how this patch makes difference (other than emitting\n$c_clear one more time).  Unless there is a use of $p that does not\nimmediately follow $r, that is.\n\nThanks.\n"},{"id":"456456","messageId":"df854e0b-3731-0b7e-557e-9446578da0e9@online.no","threadId":"57941","inReplyTo":"220601.864k141ls0.gmgdl@evledraar.gmail.com","subject":"Re: [RFC PATCH] git-prompt: make colourization consistent","fromName":"Joakim Petersen","fromEmail":"joak-pet@online.no","sentAt":"2022-06-01T18:26:23Z","receivedAt":"2022-06-01T18:26:30Z","isPatch":true,"sender":{"key":"joak-pet@online.no","avatar":"https://avatars.githubusercontent.com/u/107927072?v=4"},"body":"On 01/06/2022 16:47, Ævar Arnfjörð Bjarmason wrote:\n> This seems to make sense to me, but I haven't looked deeply into it. But\n> let's CC the author of 0ec7c23cdc6 (git-prompt: make upstream state\n> indicator location consistent, 2022-02-27) (which I've done here).\n> \n> For a non-RFC patch I think a rephrasing of most of what yo uhave below\n> \"--\" should be part of the message. Note how I referred to the\n> 0ec... commit above, you should reference the commit like that (see\n> SubmittingPatches).\n> \n> Thanks for working on this fix!\n>  >\n\nThanks for the pointers, I'll keep that in mind for the follow-up! I do\nhave one question regarding the procedure for the follow-up, though:\nIf there are no code changes, should it still be submitted as a \"v2\"?\n"},{"id":"456457","messageId":"47ba2296-10f3-4590-dbf5-38d92ed3e29e@online.no","threadId":"57941","inReplyTo":"xmqq7d60tfyd.fsf@gitster.g","subject":"Re: [RFC PATCH] git-prompt: make colourization consistent","fromName":"Joakim Petersen","fromEmail":"joak-pet@online.no","sentAt":"2022-06-01T18:32:31Z","receivedAt":"2022-06-01T18:32:40Z","isPatch":true,"sender":{"key":"joak-pet@online.no","avatar":"https://avatars.githubusercontent.com/u/107927072?v=4"},"body":"On 01/06/2022 20:07, Junio C Hamano wrote:\n> Hmph, am I correct to understand that the general flow of __git_ps1 is\n> \n>   (1) various pieces of information like $h, $w, $i, $s, $r, $b, $p,\n>       etc.  are declared \"local\" and values computed for them,\n>       either inside __git_ps1() itself, or by various helper\n>       functions it calls;\n> \n>   (2) When GIT_PS1_SHOWCOLORHINTS is in effect, we may call the\n>       __git_ps1_colorize_gitstring helper (which is touched by the\n>       above hunk), that modifies these variables with color codes.\n>       Upon entry to this helper function, these variables prepared in\n>       (1) have no color effects.  Upon leaving, they do.\n> \n>   (3) Finally, the PS1 is asseembled by concatenating these\n>       variables, whose text was prepared in (1) and then prefixed by\n>       color codes in (2), one of the earliest steps begins like so:\n> \n>       local f=\"$h$w$i$s$u\"\n>       local gitstring=\"$c$b${f:+$z$f}${sparse}$r$p\"\n> \n> In the final step of formulation, $p immediately follows $r in the\n> resulting $PS1, and the existing code at the end of the (2) prefixes\n> $c_clear before $r, and $r before such prefixing is free of coloring,\n> so it is curious how this patch makes difference (other than emitting\n> $c_clear one more time).  Unless there is a use of $p that does not\n> immediately follow $r, that is.\n> \n> Thanks.\n> \n\nYour understanding is correct for the flow before the change I\nreferenced (0ec7c23cdc6 (git-prompt: make upstream state\nindicator location consistent, 2022-02-27)), however, that commit\nchanged the definition of $f and $gitstring to\n\n\tlocal f=\"$h$w$i$s$u$p\"\n\tlocal gitstring=\"$c$b${f:+$z$f}${sparse}$r${upstream}\"\n\nThis makes it so $p is no longer immediately preceded by $r, but rather\n$u, which, like all the preceding variables, except $h, will be\ncolourized if enabled.\n"},{"id":"456467","messageId":"xmqqleugqfiw.fsf@gitster.g","threadId":"57941","inReplyTo":"47ba2296-10f3-4590-dbf5-38d92ed3e29e@online.no","subject":"Re: [RFC PATCH] git-prompt: make colourization consistent","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-06-01T20:45:27Z","receivedAt":"2022-06-01T20:49:51Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Joakim Petersen <joak-pet@online.no> writes:\n\n> Your understanding is correct for the flow before the change I\n> referenced (0ec7c23cdc6 (git-prompt: make upstream state\n> indicator location consistent, 2022-02-27)), however, that commit\n> changed the definition of $f and $gitstring to\n>\n> \tlocal f=\"$h$w$i$s$u$p\"\n> \tlocal gitstring=\"$c$b${f:+$z$f}${sparse}$r${upstream}\"\n>\n> This makes it so $p is no longer immediately preceded by $r, but rather\n> $u, which, like all the preceding variables, except $h, will be\n> colourized if enabled.\n\nAh, OK.  With the above explanation, the change does make sense.\nThe mention of that commit does need to be in the proposed log\nmessage, not under the three-dash line, as it is essential to\nunderstand why the patch is not a no-op change.\n\nThanks.\n"},{"id":"456524","messageId":"20220602145935.10512-1-joak-pet@online.no","threadId":"57941","inReplyTo":"20220601134414.66825-1-joak-pet@online.no","subject":"[PATCH v2] git-prompt: make colourization consistent","fromName":"Joakim Petersen","fromEmail":"joak-pet@online.no","sentAt":"2022-06-02T14:59:35Z","receivedAt":"2022-06-02T15:02:16Z","isPatch":true,"sender":{"key":"joak-pet@online.no","avatar":"https://avatars.githubusercontent.com/u/107927072?v=4"},"body":"The short upstream state indicator inherits the colour of the last short\nstate indicator before it (if there is one), and the sparsity state\nindicator inherits this colour as well. Make the colourization of these\nstate indicators consistent by clearing any colour before printing the\nshort upstream state indicator, as this immediately follows the last\ncoloured indicator.\n\nAs of 0ec7c23cdc6 (git-prompt: make upstream state indicator location\nconsistent, 2022-02-27), colourization in the output of __git_ps1 has\nchanged such that the short upstream state indicator inherits the colour\nof the last short state indicator before it (if there is one), while\nbefore this change it was white/the default text colour. Some examples\nto illustrate this behaviour (assuming all indicators are enabled and\ncolourization is on):\n * If the local tree is clean and there is something in the stash, both\n   the '$' and the short upstream state indicator following it will be\n   blue.\n * If the local tree has new, untracked files, both the '%' and the\n   short upstream state indicator will be red.\n * If all local changes are added to the index and the stash is empty,\n   both the '+' and the short upstream state indicator following it will\n   be green.\n * If the local tree is clean and there is nothing in the stash, the\n   short upstream state indicator will be white/${default text colour}.\n\nThis appears to be an unintended side-effect of the change, and makes\nlittle sense semantically (e.g. why is it bad to be in sync with\nupstream when you have uncommitted local changes?). The cause of the\nchange is that previously, the short upstream state indicator appeared\nimmediately after the rebase/revert/bisect/merge state indicator (note\nthe position of $p in $gitstring):\n\n\tlocal f=\"$h$w$i$s$u\"\n\tlocal gitstring=\"$c$b${f:+$z$f}${sparse}$r$p\"\n\t\nSaid indicator is prepended with the clear colour code, and the short\nupstream state indicator is thus also uncoloured. Now, the short\nupstream state indicator follows the sequence of colourized indicators,\nwithout any clearing of colour (again note the position of $p, now in\n$f):\n\n\tlocal f=\"$h$w$i$s$u$p\"\n\tlocal gitstring=\"$c$b${f:+$z$f}${sparse}$r${upstream}\"\n\nHowever, adding a clearing of colour before the short upstream state\nindicator will change how the sparsity state indicator is colourized,\nas it currently inherits (and before the change referenced also\ninherited) the colour of the last short state indicator before it.\nReading the commit message of the change that introduced the sparsity\nstate indicator, afda36dbf3b (git-prompt: include sparsity state as\nwell, 2020-06-21), it appears this colourization also was unintended,\nso clearing the colour for said indicator further increases consistency.\n\nSigned-off-by: Joakim Petersen <joak-pet@online.no>\n---\n\nRange-diff against v1:\n1:  e235caa7a8 = 1:  e235caa7a8 git-prompt: make colourization consistent\n\n contrib/completion/git-prompt.sh | 1 +\n 1 file changed, 1 insertion(+)\n\ndiff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh\nindex 87b2b916c0..dfd6cef35f 100644\n--- a/contrib/completion/git-prompt.sh\n+++ b/contrib/completion/git-prompt.sh\n@@ -286,6 +286,7 @@ __git_ps1_colorize_gitstring ()\n \tif [ -n \"$u\" ]; then\n \t\tu=\"$bad_color$u\"\n \tfi\n+\tp=\"$c_clear$p\"\n \tr=\"$c_clear$r\"\n }\n \n-- \n2.36.1\n\n"},{"id":"456544","messageId":"db1c01f8413fbbfa3e19755afdec4f71@online.no","threadId":"57941","inReplyTo":"20220602145935.10512-1-joak-pet@online.no","subject":"Re: [PATCH v2] git-prompt: make colourization consistent","fromName":"","fromEmail":"joak-pet@online.no","sentAt":"2022-06-02T21:56:02Z","receivedAt":"2022-06-02T21:56:12Z","isPatch":true,"sender":{"key":"joak-pet@online.no","avatar":"https://avatars.githubusercontent.com/u/107927072?v=4"},"body":"On 02/06/2022 16:59, Joakim Petersen wrote:\n> The short upstream state indicator inherits the colour of the last \n> short\n> state indicator before it (if there is one), and the sparsity state\n> indicator inherits this colour as well. Make the colourization of these\n> state indicators consistent by clearing any colour before printing the\n> short upstream state indicator, as this immediately follows the last\n> coloured indicator.\n> \n> As of 0ec7c23cdc6 (git-prompt: make upstream state indicator location\n> consistent, 2022-02-27), colourization in the output of __git_ps1 has\n> changed such that the short upstream state indicator inherits the \n> colour\n> of the last short state indicator before it (if there is one), while\n> before this change it was white/the default text colour. Some examples\n> to illustrate this behaviour (assuming all indicators are enabled and\n> colourization is on):\n>  * If the local tree is clean and there is something in the stash, both\n>    the '$' and the short upstream state indicator following it will be\n>    blue.\n>  * If the local tree has new, untracked files, both the '%' and the\n>    short upstream state indicator will be red.\n>  * If all local changes are added to the index and the stash is empty,\n>    both the '+' and the short upstream state indicator following it \n> will\n>    be green.\n>  * If the local tree is clean and there is nothing in the stash, the\n>    short upstream state indicator will be white/${default text colour}.\n> \n> This appears to be an unintended side-effect of the change, and makes\n> little sense semantically (e.g. why is it bad to be in sync with\n> upstream when you have uncommitted local changes?). The cause of the\n> change is that previously, the short upstream state indicator appeared\n> immediately after the rebase/revert/bisect/merge state indicator (note\n> the position of $p in $gitstring):\n> \n> \tlocal f=\"$h$w$i$s$u\"\n> \tlocal gitstring=\"$c$b${f:+$z$f}${sparse}$r$p\"\n> \n> Said indicator is prepended with the clear colour code, and the short\n> upstream state indicator is thus also uncoloured. Now, the short\n> upstream state indicator follows the sequence of colourized indicators,\n> without any clearing of colour (again note the position of $p, now in\n> $f):\n> \n> \tlocal f=\"$h$w$i$s$u$p\"\n> \tlocal gitstring=\"$c$b${f:+$z$f}${sparse}$r${upstream}\"\n> \n> However, adding a clearing of colour before the short upstream state\n> indicator will change how the sparsity state indicator is colourized,\n> as it currently inherits (and before the change referenced also\n> inherited) the colour of the last short state indicator before it.\n> Reading the commit message of the change that introduced the sparsity\n> state indicator, afda36dbf3b (git-prompt: include sparsity state as\n> well, 2020-06-21), it appears this colourization also was unintended,\n> so clearing the colour for said indicator further increases \n> consistency.\n> \n> Signed-off-by: Joakim Petersen <joak-pet@online.no>\n> ---\n> \n> Range-diff against v1:\n> 1:  e235caa7a8 = 1:  e235caa7a8 git-prompt: make colourization \n> consistent\n> \n>  contrib/completion/git-prompt.sh | 1 +\n>  1 file changed, 1 insertion(+)\n> \n> diff --git a/contrib/completion/git-prompt.sh \n> b/contrib/completion/git-prompt.sh\n> index 87b2b916c0..dfd6cef35f 100644\n> --- a/contrib/completion/git-prompt.sh\n> +++ b/contrib/completion/git-prompt.sh\n> @@ -286,6 +286,7 @@ __git_ps1_colorize_gitstring ()\n>  \tif [ -n \"$u\" ]; then\n>  \t\tu=\"$bad_color$u\"\n>  \tfi\n> +\tp=\"$c_clear$p\"\n>  \tr=\"$c_clear$r\"\n>  }\n\nI just realized I forgot to write what changed between the RFC patch\nand v2:\n\n  * Clarify the reason why 0ec7c23cdc6 (git-prompt: make upstream state\n    indicator location consistent, 2022-02-27) changed the colourization\n    of the short upstream state indicator.\n  * Explain the rationale for changing the sparsity state colourization.\n  * Include examples of how the short upstream state indicator is\n    currently colourized\n"},{"id":"456546","messageId":"xmqqilpiistk.fsf@gitster.g","threadId":"57941","inReplyTo":"20220602145935.10512-1-joak-pet@online.no","subject":"Re: [PATCH v2] git-prompt: make colourization consistent","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-06-02T22:49:59Z","receivedAt":"2022-06-02T22:50:09Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Joakim Petersen <joak-pet@online.no> writes:\n\n> Range-diff against v1:\n> 1:  e235caa7a8 = 1:  e235caa7a8 git-prompt: make colourization consistent\n>\n>  contrib/completion/git-prompt.sh | 1 +\n>  1 file changed, 1 insertion(+)\n>\n> diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh\n> index 87b2b916c0..dfd6cef35f 100644\n> --- a/contrib/completion/git-prompt.sh\n> +++ b/contrib/completion/git-prompt.sh\n> @@ -286,6 +286,7 @@ __git_ps1_colorize_gitstring ()\n>  \tif [ -n \"$u\" ]; then\n>  \t\tu=\"$bad_color$u\"\n>  \tfi\n> +\tp=\"$c_clear$p\"\n>  \tr=\"$c_clear$r\"\n>  }\n\nHas this been tested?\n\nIt seems to break a handful of tests in t9903 for me.\n\n"},{"id":"456581","messageId":"09d485f5-e3f0-be10-7061-bff6ef09a99a@online.no","threadId":"57941","inReplyTo":"xmqqilpiistk.fsf@gitster.g","subject":"Re: [PATCH v2] git-prompt: make colourization consistent","fromName":"Joakim Petersen","fromEmail":"joak-pet@online.no","sentAt":"2022-06-03T13:55:51Z","receivedAt":"2022-06-03T13:56:02Z","isPatch":true,"sender":{"key":"joak-pet@online.no","avatar":"https://avatars.githubusercontent.com/u/107927072?v=4"},"body":"On 03/06/2022 00:49, Junio C Hamano wrote:\n> Joakim Petersen <joak-pet@online.no> writes:\n> \n>> Range-diff against v1:\n>> 1:  e235caa7a8 = 1:  e235caa7a8 git-prompt: make colourization consistent\n>>\n>>   contrib/completion/git-prompt.sh | 1 +\n>>   1 file changed, 1 insertion(+)\n>>\n>> diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh\n>> index 87b2b916c0..dfd6cef35f 100644\n>> --- a/contrib/completion/git-prompt.sh\n>> +++ b/contrib/completion/git-prompt.sh\n>> @@ -286,6 +286,7 @@ __git_ps1_colorize_gitstring ()\n>>   \tif [ -n \"$u\" ]; then\n>>   \t\tu=\"$bad_color$u\"\n>>   \tfi\n>> +\tp=\"$c_clear$p\"\n>>   \tr=\"$c_clear$r\"\n>>   }\n> \n> Has this been tested?\n> \n> It seems to break a handful of tests in t9903 for me.\n> \n\nOh, no I hadn't run the test suite, sorry. I must've gotten too caught\nup in other parts of the submitting process and simply forgot to run\nthem. After looking into it, the reason why the tests fail is that $p is\nno longer empty when it is not set, so $f is no longer empty, leading to \nboth $z and $p being inserted into $gitstring. This causes there to be\nthree clear-colour sequences in the final output instead of the expected\none. Wrapping the clearing of $p's colour in a check for emptiness like\nthe other short state indicators fixes the tests. I'll submit a v3\nshortly.\n"},{"id":"456584","messageId":"20220603142521.42863-1-joak-pet@online.no","threadId":"57941","inReplyTo":"20220602145935.10512-1-joak-pet@online.no","subject":"[PATCH v3] git-prompt: make colourization consistent","fromName":"Joakim Petersen","fromEmail":"joak-pet@online.no","sentAt":"2022-06-03T14:25:21Z","receivedAt":"2022-06-03T14:25:55Z","isPatch":true,"sender":{"key":"joak-pet@online.no","avatar":"https://avatars.githubusercontent.com/u/107927072?v=4"},"body":"The short upstream state indicator inherits the colour of the last short\nstate indicator before it (if there is one), and the sparsity state\nindicator inherits this colour as well. Make the colourization of these\nstate indicators consistent by clearing any colour before printing the\nshort upstream state indicator, as this immediately follows the last\ncoloured indicator.\n\nAs of 0ec7c23cdc6 (git-prompt: make upstream state indicator location\nconsistent, 2022-02-27), colourization in the output of __git_ps1 has\nchanged such that the short upstream state indicator inherits the colour\nof the last short state indicator before it (if there is one), while\nbefore this change it was white/the default text colour. Some examples\nto illustrate this behaviour (assuming all indicators are enabled and\ncolourization is on):\n * If the local tree is clean and there is something in the stash, both\n   the '$' and the short upstream state indicator following it will be\n   blue.\n * If the local tree has new, untracked files, both the '%' and the\n   short upstream state indicator will be red.\n * If all local changes are added to the index and the stash is empty,\n   both the '+' and the short upstream state indicator following it will\n   be green.\n * If the local tree is clean and there is nothing in the stash, the\n   short upstream state indicator will be white/${default text colour}.\n\nThis appears to be an unintended side-effect of the change, and makes\nlittle sense semantically (e.g. why is it bad to be in sync with\nupstream when you have uncommitted local changes?). The cause of the\nchange is that previously, the short upstream state indicator appeared\nimmediately after the rebase/revert/bisect/merge state indicator (note\nthe position of $p in $gitstring):\n\n\tlocal f=\"$h$w$i$s$u\"\n\tlocal gitstring=\"$c$b${f:+$z$f}${sparse}$r$p\"\n\t\nSaid indicator is prepended with the clear colour code, and the short\nupstream state indicator is thus also uncoloured. Now, the short\nupstream state indicator follows the sequence of colourized indicators,\nwithout any clearing of colour (again note the position of $p, now in\n$f):\n\n\tlocal f=\"$h$w$i$s$u$p\"\n\tlocal gitstring=\"$c$b${f:+$z$f}${sparse}$r${upstream}\"\n\nIf the user is in a sparse checkout, the sparsity state indicator\nfollows a similar pattern to the short upstream state indicator.However,\nadding a clearing of colour before the short upstream state indicator\nwill change how the sparsity state indicator is colourized only when the\nshort upstream state indicator is present, as it currently inherits (and\nbefore the change referenced also inherited) the colour of the last\nshort state indicator before it. Reading the commit message of the\nchange that introduced the sparsity state indicator, afda36dbf3b\n(git-prompt: include sparsity state as well, 2020-06-21), it appears\nthis colourization also was unintended, so clearing the colour for said\nindicator further increases consistency.\n\nSigned-off-by: Joakim Petersen <joak-pet@online.no>\n---\nChanges since v2:\n * Wrapped clearing of $p's colour in a check for emptiness to avoid\n   multiple colour clears in the final gitstring.\n * Added clearing of colour for $sparse, as it wouldn't acutally be\n   cleared consistently with only the change from the previous bullet\n    - Having the short upstream state indicator disabled would leave the\n      sparse state indicator as it is without this patch.\n\nRange-diff against v2:\n1:  e235caa7a8 < -:  ---------- git-prompt: make colourization consistent\n-:  ---------- > 1:  0e107d0496 git-prompt: make colourization consistent\n\n contrib/completion/git-prompt.sh | 6 ++++++\n 1 file changed, 6 insertions(+)\n\ndiff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh\nindex 87b2b916c0..4997545ee5 100644\n--- a/contrib/completion/git-prompt.sh\n+++ b/contrib/completion/git-prompt.sh\n@@ -286,6 +286,12 @@ __git_ps1_colorize_gitstring ()\n \tif [ -n \"$u\" ]; then\n \t\tu=\"$bad_color$u\"\n \tfi\n+\tif [ -n \"$p\" ]; then\n+\t\tp=\"$c_clear$p\"\n+\tfi\n+\tif [ -n \"$sparse\" ]; then\n+\t\tsparse=\"$c_clear$sparse\"\n+\tfi\n \tr=\"$c_clear$r\"\n }\n \n-- \n2.36.1\n\n"},{"id":"456592","messageId":"xmqqy1ydhfcc.fsf@gitster.g","threadId":"57941","inReplyTo":"20220603142521.42863-1-joak-pet@online.no","subject":"Re: [PATCH v3] git-prompt: make colourization consistent","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-06-03T16:38:43Z","receivedAt":"2022-06-03T16:38:52Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"This is not a new issue, but seeing this:\n\n \tif [ $detached = no ]; then\n \t\tbranch_color=\"$ok_color\"\n \telse\n \t\tbranch_color=\"$bad_color\"\n \tfi\n \tc=\"$branch_color$c\"\n \n \tz=\"$c_clear$z\"\n \tif [ \"$w\" = \"*\" ]; then\n \t\tw=\"$bad_color$w\"\n \tfi\n \tif [ -n \"$i\" ]; then\n \t\ti=\"$ok_color$i\"\n \tfi\n \tif [ -n \"$s\" ]; then\n \t\ts=\"$flags_color$s\"\n \tfi\n \tif [ -n \"$u\" ]; then\n \t\tu=\"$bad_color$u\"\n \tfi\n+\tif [ -n \"$p\" ]; then\n+\t\tp=\"$c_clear$p\"\n+\tfi\n+\tif [ -n \"$sparse\" ]; then\n+\t\tsparse=\"$c_clear$sparse\"\n+\tfi\n \tr=\"$c_clear$r\"\n }\n\nit makes me wonder if the more forward looking and future-proof way\nthat is resistant to any future and random reshuffling like what\n0ec7c23c (git-prompt: make upstream state indicator location\nconsistent, 2022-02-27) did would be to make it a rule to maintain\nthat there is no coloring by default, and when any of these tokens\nlike w, i, s, ... are not empty, enclose them inside \"color-on\" and\n\"color-off\" sequence.\n\nFor example, \n\n \tif [ \"$w\" = \"*\" ]; then\n \t\tw=\"$bad_color$w\"\n \tfi\n\nwould mean $w, when it is \"*\", would cause gitstring to contain an\nasterisk that is painted in $bad_color, but ALSO causes whatever\nthat happens to come AFTER $w in gitstring to be painted in the same\ncolor UNLESS it tries to protect itself.  Right now, $w may be\nimmediately followed by $i, and $i does protect itself by prefixing\nwith $ok_color, but if $i is empty, $w's coloring will extend to $s.\n\nSo, if we did this instead:\n\n- \tz=\"$c_clear$z\"\n \tif [ \"$w\" = \"*\" ]; then\n- \t\tw=\"$bad_color$w\"\n+ \t\tw=\"$bad_color$w$c_clear\"\n \tfi\n\nand make similar changes to everything else we see above, we\nprobably can lose the ones that prefix with $c_clear, because each\ntoken that paints itself in unusual color is now responsible for\nreturning the terminal state to normal with the $c_clear sequence\nafter it is done with it.  We do not have to special case sparse, p,\nor r in this helper function at all if we go that route, no?\n\nIf the helper were written that way, then reshuffling the order of\nthe tokens done in 0ec7c23c (git-prompt: make upstream state\nindicator location consistent, 2022-02-27) wouldn't have made the\npatch under discussion necessary at all, which is what I see is\nvaluable from the \"maintainability\" point of view.\n\n"},{"id":"456596","messageId":"7d391d82-b15e-4a31-5207-c4037fec0bf9@online.no","threadId":"57941","inReplyTo":"xmqqy1ydhfcc.fsf@gitster.g","subject":"Re: [PATCH v3] git-prompt: make colourization consistent","fromName":"Joakim Petersen","fromEmail":"joak-pet@online.no","sentAt":"2022-06-03T17:23:25Z","receivedAt":"2022-06-03T17:23:40Z","isPatch":true,"sender":{"key":"joak-pet@online.no","avatar":"https://avatars.githubusercontent.com/u/107927072?v=4"},"body":"On 03/06/2022 18:38, Junio C Hamano wrote:\n> This is not a new issue, but seeing this:\n> \n>   \tif [ $detached = no ]; then\n>   \t\tbranch_color=\"$ok_color\"\n>   \telse\n>   \t\tbranch_color=\"$bad_color\"\n>   \tfi\n>   \tc=\"$branch_color$c\"\n>   \n>   \tz=\"$c_clear$z\"\n>   \tif [ \"$w\" = \"*\" ]; then\n>   \t\tw=\"$bad_color$w\"\n>   \tfi\n>   \tif [ -n \"$i\" ]; then\n>   \t\ti=\"$ok_color$i\"\n>   \tfi\n>   \tif [ -n \"$s\" ]; then\n>   \t\ts=\"$flags_color$s\"\n>   \tfi\n>   \tif [ -n \"$u\" ]; then\n>   \t\tu=\"$bad_color$u\"\n>   \tfi\n> +\tif [ -n \"$p\" ]; then\n> +\t\tp=\"$c_clear$p\"\n> +\tfi\n> +\tif [ -n \"$sparse\" ]; then\n> +\t\tsparse=\"$c_clear$sparse\"\n> +\tfi\n>   \tr=\"$c_clear$r\"\n>   }\n> \n> it makes me wonder if the more forward looking and future-proof way\n> that is resistant to any future and random reshuffling like what\n> 0ec7c23c (git-prompt: make upstream state indicator location\n> consistent, 2022-02-27) did would be to make it a rule to maintain\n> that there is no coloring by default, and when any of these tokens\n> like w, i, s, ... are not empty, enclose them inside \"color-on\" and\n> \"color-off\" sequence.\n> \n> For example,\n> \n>   \tif [ \"$w\" = \"*\" ]; then\n>   \t\tw=\"$bad_color$w\"\n>   \tfi\n> \n> would mean $w, when it is \"*\", would cause gitstring to contain an\n> asterisk that is painted in $bad_color, but ALSO causes whatever\n> that happens to come AFTER $w in gitstring to be painted in the same\n> color UNLESS it tries to protect itself.  Right now, $w may be\n> immediately followed by $i, and $i does protect itself by prefixing\n> with $ok_color, but if $i is empty, $w's coloring will extend to $s.\n> \n> So, if we did this instead:\n> \n> - \tz=\"$c_clear$z\"\n>   \tif [ \"$w\" = \"*\" ]; then\n> - \t\tw=\"$bad_color$w\"\n> + \t\tw=\"$bad_color$w$c_clear\"\n>   \tfi\n> \n> and make similar changes to everything else we see above, we\n> probably can lose the ones that prefix with $c_clear, because each\n> token that paints itself in unusual color is now responsible for\n> returning the terminal state to normal with the $c_clear sequence\n> after it is done with it.  We do not have to special case sparse, p,\n> or r in this helper function at all if we go that route, no?\n> \n> If the helper were written that way, then reshuffling the order of\n> the tokens done in 0ec7c23c (git-prompt: make upstream state\n> indicator location consistent, 2022-02-27) wouldn't have made the\n> patch under discussion necessary at all, which is what I see is\n> valuable from the \"maintainability\" point of view.\n> \n\nThat does seem like a much better idea for maintainability, I can\nchange the patch to do this instead. I have one question, though: the\nsequence $c$b (bare state and branch name) is a special case, where\nthey're intended to have the same colour, should I wrap both in colour\nset, colour clear, or only clear after $b? The former requires rewriting\nthe tests or changing $gitstring to not include $c when $c is empty,\nwhile the latter keeps the tests unchanged, but may pose a problem if\n\"BARE:\" should at any point not appear immediately before the branch\nname.\n"},{"id":"456622","messageId":"9fa34f22-3404-7bf8-6985-642c80634bf8@online.no","threadId":"57941","inReplyTo":"7d391d82-b15e-4a31-5207-c4037fec0bf9@online.no","subject":"Re: [PATCH v3] git-prompt: make colourization consistent","fromName":"Joakim Petersen","fromEmail":"joak-pet@online.no","sentAt":"2022-06-03T18:51:58Z","receivedAt":"2022-06-03T18:52:11Z","isPatch":true,"sender":{"key":"joak-pet@online.no","avatar":"https://avatars.githubusercontent.com/u/107927072?v=4"},"body":"On 03/06/2022 19:23, Joakim Petersen wrote:\n> That does seem like a much better idea for maintainability, I can\n> change the patch to do this instead. I have one question, though: the\n> sequence $c$b (bare state and branch name) is a special case, where\n> they're intended to have the same colour, should I wrap both in colour\n> set, colour clear, or only clear after $b? The former requires rewriting\n> the tests or changing $gitstring to not include $c when $c is empty,\n> while the latter keeps the tests unchanged, but may pose a problem if\n> \"BARE:\" should at any point not appear immediately before the branch\n> name.\n\nSorry, the former (colourizing and clearing $c and $b individually)\nrequires rewriting tests no matter what.\n"},{"id":"456629","messageId":"CAGTqyRxkiGt7CRggV7VeXNRK2VmDMxDX3EpOr5cPcc5AdH8ZaA@mail.gmail.com","threadId":"57941","inReplyTo":"9fa34f22-3404-7bf8-6985-642c80634bf8@online.no","subject":"Re: [PATCH v3] git-prompt: make colourization consistent","fromName":"Justin Donnelly","fromEmail":"justinrdonnelly@gmail.com","sentAt":"2022-06-03T19:43:11Z","receivedAt":"2022-06-03T19:43:51Z","isPatch":true,"sender":{"key":"justinrdonnelly@gmail.com","avatar":"https://avatars.githubusercontent.com/u/24846452?v=4"},"body":"Hi all. I'm the author of 0ec7c23c (git-prompt: make upstream state\nindicator location consistent, 2022-02-27). Sorry I'm a little late\njumping in. I was also going to propose something more comprehensive\nand future-proof than what's there (adding the applicable color\n(including clear) to all the indicators), but I like Junio's idea\nbetter. The only other thing I have to add is that it's probably a\ngood idea to include a comment in the function\n`__git_ps1_colorize_gitstring` explaining the design so future\ndevelopers/reviewers know.\n\nThanks,\nJustin\n\n\nOn Fri, Jun 3, 2022 at 2:52 PM Joakim Petersen <joak-pet@online.no> wrote:\n>\n> On 03/06/2022 19:23, Joakim Petersen wrote:\n> > That does seem like a much better idea for maintainability, I can\n> > change the patch to do this instead. I have one question, though: the\n> > sequence $c$b (bare state and branch name) is a special case, where\n> > they're intended to have the same colour, should I wrap both in colour\n> > set, colour clear, or only clear after $b? The former requires rewriting\n> > the tests or changing $gitstring to not include $c when $c is empty,\n> > while the latter keeps the tests unchanged, but may pose a problem if\n> > \"BARE:\" should at any point not appear immediately before the branch\n> > name.\n>\n> Sorry, the former (colourizing and clearing $c and $b individually)\n> requires rewriting tests no matter what.\n"},{"id":"456632","messageId":"xmqqh751eakm.fsf@gitster.g","threadId":"57941","inReplyTo":"7d391d82-b15e-4a31-5207-c4037fec0bf9@online.no","subject":"Re: [PATCH v3] git-prompt: make colourization consistent","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-06-03T20:50:01Z","receivedAt":"2022-06-03T20:50:12Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Joakim Petersen <joak-pet@online.no> writes:\n\n> That does seem like a much better idea for maintainability, I can\n> change the patch to do this instead. I have one question, though: the\n> sequence $c$b (bare state and branch name) is a special case, where\n> they're intended to have the same colour, should I wrap both in colour\n> set, colour clear, or only clear after $b?\n\nIf we want to allow $c and $b appear in different places (which I\nhave no opinion on), I would say we should just color them\nindependently and fix the test that expects the close linkage\nbetween the two.  I offhand see no reason that they _must_ stay\ntogether myself, though.\n\nThanks.\n\n"},{"id":"456635","messageId":"xmqqwndxcuru.fsf@gitster.g","threadId":"57941","inReplyTo":"CAGTqyRxkiGt7CRggV7VeXNRK2VmDMxDX3EpOr5cPcc5AdH8ZaA@mail.gmail.com","subject":"Re: [PATCH v3] git-prompt: make colourization consistent","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-06-03T21:16:37Z","receivedAt":"2022-06-03T21:16:46Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Justin Donnelly <justinrdonnelly@gmail.com> writes:\n\n> Hi all. I'm the author of 0ec7c23c (git-prompt: make upstream state\n> indicator location consistent, 2022-02-27). Sorry I'm a little late\n> jumping in. I was also going to propose something more comprehensive\n> and future-proof than what's there (adding the applicable color\n> (including clear) to all the indicators), but I like Junio's idea\n> better. The only other thing I have to add is that it's probably a\n> good idea to include a comment in the function\n> `__git_ps1_colorize_gitstring` explaining the design so future\n> developers/reviewers know.\n\nAfter thinking it again, I actually am OK with the original coloring\ncode structure.  The rule is \"you always counter whatever color\nsettings left behind by somebody who came before you\".\n\nAs long as the color effect you use is not additive (e.g. if the\nfinal product is $a$b, and $a is prefixed with $c_red and $b is\nprefixed with $c_blue, an additive coloring scheme may end up\npainting b in purple), we'll save number of $c_clear we would need\nto emit.  Plain colors are probably not additive, but some\nattributes are, so this is more brittle than \"always reset to the\nbase state\" rule, but it may be more desirable in practice.\n\nI have no strong preference either way.  But if we are to go that\nroute, we definitely need to make sure that the last element added\nto gitstring is followed by $c_reset, by doing something like the\nattached patch.  Currently, $r has unconditional $c_clear in front\nof it, and $upstream is never colored, and that is the only thing\nthat is saving us from leftover color bleeding into whatever comes\nafter the prompt.\n\n contrib/completion/git-prompt.sh | 4 +++-\n 1 file changed, 3 insertions(+), 1 deletion(-)\n\ndiff --git c/contrib/completion/git-prompt.sh w/contrib/completion/git-prompt.sh\nindex 87b2b916c0..c803b9fae5 100644\n--- c/contrib/completion/git-prompt.sh\n+++ w/contrib/completion/git-prompt.sh\n@@ -287,6 +287,7 @@ __git_ps1_colorize_gitstring ()\n \t\tu=\"$bad_color$u\"\n \tfi\n \tr=\"$c_clear$r\"\n+\tend_of_gitstring=$c_clear\n }\n \n # Helper function to read the first line of a file into a variable.\n@@ -556,6 +557,7 @@ __git_ps1 ()\n \n \tlocal z=\"${GIT_PS1_STATESEPARATOR-\" \"}\"\n \n+\tlocal end_of_gitstring=\n \t# NO color option unless in PROMPT_COMMAND mode or it's Zsh\n \tif [ -n \"${GIT_PS1_SHOWCOLORHINTS-}\" ]; then\n \t\tif [ $pcmode = yes ] || [ -n \"${ZSH_VERSION-}\" ]; then\n@@ -570,7 +572,7 @@ __git_ps1 ()\n \tfi\n \n \tlocal f=\"$h$w$i$s$u$p\"\n-\tlocal gitstring=\"$c$b${f:+$z$f}${sparse}$r${upstream}\"\n+\tlocal gitstring=\"$c$b${f:+$z$f}${sparse}$r${upstream}${end_of_gitstring}\"\n \n \tif [ $pcmode = yes ]; then\n \t\tif [ \"${__git_printf_supports_v-}\" != yes ]; then\n"},{"id":"456659","messageId":"ed7d78a5-3c70-df5a-81c3-bdb631271700@online.no","threadId":"57941","inReplyTo":"xmqqwndxcuru.fsf@gitster.g","subject":"Re: [PATCH v3] git-prompt: make colourization consistent","fromName":"Joakim Petersen","fromEmail":"joak-pet@online.no","sentAt":"2022-06-04T09:42:54Z","receivedAt":"2022-06-04T09:46:49Z","isPatch":true,"sender":{"key":"joak-pet@online.no","avatar":"https://avatars.githubusercontent.com/u/107927072?v=4"},"body":"On 03/06/2022 23:16, Junio C Hamano wrote:\n> After thinking it again, I actually am OK with the original coloring\n> code structure.  The rule is \"you always counter whatever color\n> settings left behind by somebody who came before you\".\n> \n> As long as the color effect you use is not additive (e.g. if the\n> final product is $a$b, and $a is prefixed with $c_red and $b is\n> prefixed with $c_blue, an additive coloring scheme may end up\n> painting b in purple), we'll save number of $c_clear we would need\n> to emit.  Plain colors are probably not additive, but some\n> attributes are, so this is more brittle than \"always reset to the\n> base state\" rule, but it may be more desirable in practice.\n> \n> I have no strong preference either way.  But if we are to go that\n> route, we definitely need to make sure that the last element added\n> to gitstring is followed by $c_reset, by doing something like the\n> attached patch.  Currently, $r has unconditional $c_clear in front\n> of it, and $upstream is never colored, and that is the only thing\n> that is saving us from leftover color bleeding into whatever comes\n> after the prompt.\n\nThere might be something I'm not seeing, but having it so each element\ncounters whatever colour left by the preceding element seems less\nintuitive when adding or moving elements in the final $gitstring. Adding\nan element will then require going into __git_ps1_colorize_gitstring,\neven when it is not intended to be colourized. All existing uncoloured\nelements will also need to be prefixed to protect against colour bleed\nfrom being moved around. I'm partial to the idea of each coloured\nelement clearing its own colour.\n"},{"id":"456684","messageId":"20220604161333.54627-1-joak-pet@online.no","threadId":"57941","inReplyTo":"20220603142521.42863-1-joak-pet@online.no","subject":"[PATCH v4] git-prompt: make colourization consistent","fromName":"Joakim Petersen","fromEmail":"joak-pet@online.no","sentAt":"2022-06-04T16:13:33Z","receivedAt":"2022-06-04T16:13:56Z","isPatch":true,"sender":{"key":"joak-pet@online.no","avatar":"https://avatars.githubusercontent.com/u/107927072?v=4"},"body":"The short upstream state indicator inherits the colour of the last short\nstate indicator before it (if there is one), and the sparsity state\nindicator inherits this colour as well. Make the colourization of these\nstate indicators consistent by making all colourized indicators clear\ntheir own colour.\n\nAs of 0ec7c23cdc6 (git-prompt: make upstream state indicator location\nconsistent, 2022-02-27), colourization in the output of __git_ps1 has\nchanged such that the short upstream state indicator inherits the colour\nof the last short state indicator before it (if there is one), while\nbefore this change it was white/the default text colour. Some examples\nto illustrate this behaviour (assuming all indicators are enabled and\ncolourization is on):\n * If there is something in the stash, both the '$' and the short\n   upstream state indicator following it will be blue.\n * If the local tree has new, untracked files and there is nothing in\n   the stash, both the '%' and the    short upstream state indicator\n   will be red.\n * If all local changes are added to the index and the stash is empty,\n   both the '+' and the short upstream state indicator following it will\n   be green.\n * If the local tree is clean and there is nothing in the stash, the\n   short upstream state indicator will be white/${default text colour}.\n\nThis appears to be an unintended side-effect of the change, and makes\nlittle sense semantically (e.g. why is it bad to be in sync with\nupstream when you have uncommitted local changes?). The cause of the\nchange is that previously, the short upstream state indicator appeared\nimmediately after the rebase/revert/bisect/merge state indicator (note\nthe position of $p in $gitstring):\n\n\tlocal f=\"$h$w$i$s$u\"\n\tlocal gitstring=\"$c$b${f:+$z$f}${sparse}$r$p\"\n\t\nSaid indicator is prepended with the clear colour code, and the short\nupstream state indicator is thus also uncoloured. Now, the short\nupstream state indicator follows the sequence of colourized indicators,\nwithout any clearing of colour (again note the position of $p, now in\n$f):\n\n\tlocal f=\"$h$w$i$s$u$p\"\n\tlocal gitstring=\"$c$b${f:+$z$f}${sparse}$r${upstream}\"\n\nIf the user is in a sparse checkout, the sparsity state indicator\nfollows a similar pattern to the short upstream state indicator.\nHowever, clearing colour of the colourized indicators changes how the\nsparsity state indicator is colourized , as it currently inherits (and\nbefore the change referenced also inherited) the colour of the last\nshort state indicator before it. Reading the commit message of the\nchange that introduced the sparsity state indicator, afda36dbf3b\n(git-prompt: include sparsity state as well, 2020-06-21), it appears\nthis colourization also was unintended, so clearing the colour for said\nindicator further increases consistency.\n\nColouring of $c was made dependent on it not being empty, as it is no\nlonger being used to colour the branch name. Removal of $b's prefix was\nmoved to before the colourization so it gets cleared properly now that\ncolour codes are inserted into it.\n\nDue to colour clearing being moved into the variables for each coloured\nindicator, the tests for the coloured Bash prompt had to be changed:\n * All colour tests now have the colour codes around the expected\n   content of the expanded $__git_ps1_branch_name variable instead of\n   the unexpanded variable in the string.\n * The test with two indicators had a clear-colour code inserted after\n   the symbol for the first indicator, since all indicators clear their\n   own colours now.\n\nSigned-off-by: Joakim Petersen <joak-pet@online.no>\n---\nChanges since v3:\n * All colourized variables now also clear their own colour.\n * Variables are only coloured if they are not empty, except $b (branch\n   name), which is not an optional indicator.\n * Updated tests to reflect the new colourization behaviour.\n * Fixed a mistake in two of the examples; the stash indicator is the\n   last of the short state indicators preceding the short upstream state\n   indicator.\n\nRange-diff against v3:\n1:  0e107d0496 < -:  ---------- git-prompt: make colourization consistent\n-:  ---------- > 1:  98ce78ddc5 git-prompt: make colourization consistent\n\n contrib/completion/git-prompt.sh | 20 +++++++++++---------\n t/t9903-bash-prompt.sh           | 18 +++++++++---------\n 2 files changed, 20 insertions(+), 18 deletions(-)\n\ndiff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh\nindex 87b2b916c0..32bb98bb8d 100644\n--- a/contrib/completion/git-prompt.sh\n+++ b/contrib/completion/git-prompt.sh\n@@ -245,7 +245,8 @@ __git_ps1_show_upstream ()\n \n # Helper function that is meant to be called from __git_ps1.  It\n # injects color codes into the appropriate gitstring variables used\n-# to build a gitstring.\n+# to build a gitstring. Colored variables are responsible for clearing\n+# their own color.\n __git_ps1_colorize_gitstring ()\n {\n \tif [[ -n ${ZSH_VERSION-} ]]; then\n@@ -271,22 +272,23 @@ __git_ps1_colorize_gitstring ()\n \telse\n \t\tbranch_color=\"$bad_color\"\n \tfi\n-\tc=\"$branch_color$c\"\n+\tif [ -n \"$c\" ]; then\n+\t\tc=\"$branch_color$c$c_clear\"\n+\tfi\n+\tb=\"$branch_color$b$c_clear\"\n \n-\tz=\"$c_clear$z\"\n \tif [ \"$w\" = \"*\" ]; then\n-\t\tw=\"$bad_color$w\"\n+\t\tw=\"$bad_color$w$c_clear\"\n \tfi\n \tif [ -n \"$i\" ]; then\n-\t\ti=\"$ok_color$i\"\n+\t\ti=\"$ok_color$i$c_clear\"\n \tfi\n \tif [ -n \"$s\" ]; then\n-\t\ts=\"$flags_color$s\"\n+\t\ts=\"$flags_color$s$c_clear\"\n \tfi\n \tif [ -n \"$u\" ]; then\n-\t\tu=\"$bad_color$u\"\n+\t\tu=\"$bad_color$u$c_clear\"\n \tfi\n-\tr=\"$c_clear$r\"\n }\n \n # Helper function to read the first line of a file into a variable.\n@@ -554,6 +556,7 @@ __git_ps1 ()\n \t\tfi\n \tfi\n \n+\tb=${b##refs/heads/}\n \tlocal z=\"${GIT_PS1_STATESEPARATOR-\" \"}\"\n \n \t# NO color option unless in PROMPT_COMMAND mode or it's Zsh\n@@ -563,7 +566,6 @@ __git_ps1 ()\n \t\tfi\n \tfi\n \n-\tb=${b##refs/heads/}\n \tif [ $pcmode = yes ] && [ $ps1_expanded = yes ]; then\n \t\t__git_ps1_branch_name=$b\n \t\tb=\"\\${__git_ps1_branch_name}\"\ndiff --git a/t/t9903-bash-prompt.sh b/t/t9903-bash-prompt.sh\nindex bbd513bab0..abd82eec35 100755\n--- a/t/t9903-bash-prompt.sh\n+++ b/t/t9903-bash-prompt.sh\n@@ -541,7 +541,7 @@ test_expect_success 'prompt - pc mode' '\n '\n \n test_expect_success 'prompt - bash color pc mode - branch name' '\n-\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear}):AFTER\\\\nmain\" >expected &&\n+\tprintf \"BEFORE: (\\${__git_ps1_branch_name}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n \t(\n \t\tGIT_PS1_SHOWCOLORHINTS=y &&\n \t\t__git_ps1 \"BEFORE:\" \":AFTER\" >\"$actual\" &&\n@@ -551,7 +551,7 @@ test_expect_success 'prompt - bash color pc mode - branch name' '\n '\n \n test_expect_success 'prompt - bash color pc mode - detached head' '\n-\tprintf \"BEFORE: (${c_red}\\${__git_ps1_branch_name}${c_clear}):AFTER\\\\n(%s...)\" $(git log -1 --format=\"%h\" b1^) >expected &&\n+\tprintf \"BEFORE: (\\${__git_ps1_branch_name}):AFTER\\\\n${c_red}(%s...)\"${c_clear} $(git log -1 --format=\"%h\" b1^) >expected &&\n \tgit checkout b1^ &&\n \ttest_when_finished \"git checkout main\" &&\n \t(\n@@ -563,7 +563,7 @@ test_expect_success 'prompt - bash color pc mode - detached head' '\n '\n \n test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirty worktree' '\n-\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear} ${c_red}*${c_clear}):AFTER\\\\nmain\" >expected &&\n+\tprintf \"BEFORE: (\\${__git_ps1_branch_name} ${c_red}*${c_clear}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n \techo \"dirty\" >file &&\n \ttest_when_finished \"git reset --hard\" &&\n \t(\n@@ -576,7 +576,7 @@ test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirt\n '\n \n test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirty index' '\n-\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear} ${c_green}+${c_clear}):AFTER\\\\nmain\" >expected &&\n+\tprintf \"BEFORE: (\\${__git_ps1_branch_name} ${c_green}+${c_clear}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n \techo \"dirty\" >file &&\n \ttest_when_finished \"git reset --hard\" &&\n \tgit add -u &&\n@@ -590,7 +590,7 @@ test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirt\n '\n \n test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirty index and worktree' '\n-\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear} ${c_red}*${c_green}+${c_clear}):AFTER\\\\nmain\" >expected &&\n+\tprintf \"BEFORE: (\\${__git_ps1_branch_name} ${c_red}*${c_clear}${c_green}+${c_clear}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n \techo \"dirty index\" >file &&\n \ttest_when_finished \"git reset --hard\" &&\n \tgit add -u &&\n@@ -605,7 +605,7 @@ test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirt\n '\n \n test_expect_success 'prompt - bash color pc mode - dirty status indicator - before root commit' '\n-\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear} ${c_green}#${c_clear}):AFTER\\\\nmain\" >expected &&\n+\tprintf \"BEFORE: (\\${__git_ps1_branch_name} ${c_green}#${c_clear}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n \t(\n \t\tGIT_PS1_SHOWDIRTYSTATE=y &&\n \t\tGIT_PS1_SHOWCOLORHINTS=y &&\n@@ -617,7 +617,7 @@ test_expect_success 'prompt - bash color pc mode - dirty status indicator - befo\n '\n \n test_expect_success 'prompt - bash color pc mode - inside .git directory' '\n-\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear}):AFTER\\\\nGIT_DIR!\" >expected &&\n+\tprintf \"BEFORE: (\\${__git_ps1_branch_name}):AFTER\\\\n${c_green}GIT_DIR!${c_clear}\" >expected &&\n \techo \"dirty\" >file &&\n \ttest_when_finished \"git reset --hard\" &&\n \t(\n@@ -631,7 +631,7 @@ test_expect_success 'prompt - bash color pc mode - inside .git directory' '\n '\n \n test_expect_success 'prompt - bash color pc mode - stash status indicator' '\n-\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear} ${c_lblue}\\$${c_clear}):AFTER\\\\nmain\" >expected &&\n+\tprintf \"BEFORE: (\\${__git_ps1_branch_name} ${c_lblue}\\$${c_clear}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n \techo 2 >file &&\n \tgit stash &&\n \ttest_when_finished \"git stash drop\" &&\n@@ -645,7 +645,7 @@ test_expect_success 'prompt - bash color pc mode - stash status indicator' '\n '\n \n test_expect_success 'prompt - bash color pc mode - untracked files status indicator' '\n-\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear} ${c_red}%%${c_clear}):AFTER\\\\nmain\" >expected &&\n+\tprintf \"BEFORE: (\\${__git_ps1_branch_name} ${c_red}%%${c_clear}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n \t(\n \t\tGIT_PS1_SHOWUNTRACKEDFILES=y &&\n \t\tGIT_PS1_SHOWCOLORHINTS=y &&\n-- \n2.36.1\n\n"},{"id":"456688","messageId":"CAGTqyRxS9aBitVivSTqojX_C_VBdgrD7JkUKgKSE6apjabzvQg@mail.gmail.com","threadId":"57941","inReplyTo":"20220604161333.54627-1-joak-pet@online.no","subject":"Re: [PATCH v4] git-prompt: make colourization consistent","fromName":"Justin Donnelly","fromEmail":"justinrdonnelly@gmail.com","sentAt":"2022-06-04T17:30:45Z","receivedAt":"2022-06-04T17:31:24Z","isPatch":true,"sender":{"key":"justinrdonnelly@gmail.com","avatar":"https://avatars.githubusercontent.com/u/24846452?v=4"},"body":"On Sat, Jun 4, 2022 at 12:13 PM Joakim Petersen <joak-pet@online.no> wrote:\n>\n> The short upstream state indicator inherits the colour of the last short\n> state indicator before it (if there is one), and the sparsity state\n> indicator inherits this colour as well. Make the colourization of these\n> state indicators consistent by making all colourized indicators clear\n> their own colour.\n>\n> As of 0ec7c23cdc6 (git-prompt: make upstream state indicator location\n> consistent, 2022-02-27), colourization in the output of __git_ps1 has\n> changed such that the short upstream state indicator inherits the colour\n> of the last short state indicator before it (if there is one), while\n> before this change it was white/the default text colour. Some examples\n> to illustrate this behaviour (assuming all indicators are enabled and\n> colourization is on):\n>  * If there is something in the stash, both the '$' and the short\n>    upstream state indicator following it will be blue.\n>  * If the local tree has new, untracked files and there is nothing in\n>    the stash, both the '%' and the    short upstream state indicator\n>    will be red.\n>  * If all local changes are added to the index and the stash is empty,\n>    both the '+' and the short upstream state indicator following it will\n>    be green.\n>  * If the local tree is clean and there is nothing in the stash, the\n>    short upstream state indicator will be white/${default text colour}.\n>\n> This appears to be an unintended side-effect of the change, and makes\n> little sense semantically (e.g. why is it bad to be in sync with\n> upstream when you have uncommitted local changes?). The cause of the\n> change is that previously, the short upstream state indicator appeared\n> immediately after the rebase/revert/bisect/merge state indicator (note\n> the position of $p in $gitstring):\n>\n>         local f=\"$h$w$i$s$u\"\n>         local gitstring=\"$c$b${f:+$z$f}${sparse}$r$p\"\n>\n> Said indicator is prepended with the clear colour code, and the short\n> upstream state indicator is thus also uncoloured. Now, the short\n> upstream state indicator follows the sequence of colourized indicators,\n> without any clearing of colour (again note the position of $p, now in\n> $f):\n>\n>         local f=\"$h$w$i$s$u$p\"\n>         local gitstring=\"$c$b${f:+$z$f}${sparse}$r${upstream}\"\n>\n> If the user is in a sparse checkout, the sparsity state indicator\n> follows a similar pattern to the short upstream state indicator.\n> However, clearing colour of the colourized indicators changes how the\n> sparsity state indicator is colourized , as it currently inherits (and\n> before the change referenced also inherited) the colour of the last\n> short state indicator before it. Reading the commit message of the\n> change that introduced the sparsity state indicator, afda36dbf3b\n> (git-prompt: include sparsity state as well, 2020-06-21), it appears\n> this colourization also was unintended, so clearing the colour for said\n> indicator further increases consistency.\n>\n> Colouring of $c was made dependent on it not being empty, as it is no\n> longer being used to colour the branch name. Removal of $b's prefix was\n> moved to before the colourization so it gets cleared properly now that\n> colour codes are inserted into it.\n>\n> Due to colour clearing being moved into the variables for each coloured\n> indicator, the tests for the coloured Bash prompt had to be changed:\n>  * All colour tests now have the colour codes around the expected\n>    content of the expanded $__git_ps1_branch_name variable instead of\n>    the unexpanded variable in the string.\n>  * The test with two indicators had a clear-colour code inserted after\n>    the symbol for the first indicator, since all indicators clear their\n>    own colours now.\n>\n> Signed-off-by: Joakim Petersen <joak-pet@online.no>\n> ---\n> Changes since v3:\n>  * All colourized variables now also clear their own colour.\n>  * Variables are only coloured if they are not empty, except $b (branch\n>    name), which is not an optional indicator.\n>  * Updated tests to reflect the new colourization behaviour.\n>  * Fixed a mistake in two of the examples; the stash indicator is the\n>    last of the short state indicators preceding the short upstream state\n>    indicator.\n>\n> Range-diff against v3:\n> 1:  0e107d0496 < -:  ---------- git-prompt: make colourization consistent\n> -:  ---------- > 1:  98ce78ddc5 git-prompt: make colourization consistent\n>\n>  contrib/completion/git-prompt.sh | 20 +++++++++++---------\n>  t/t9903-bash-prompt.sh           | 18 +++++++++---------\n>  2 files changed, 20 insertions(+), 18 deletions(-)\n>\n> diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh\n> index 87b2b916c0..32bb98bb8d 100644\n> --- a/contrib/completion/git-prompt.sh\n> +++ b/contrib/completion/git-prompt.sh\n> @@ -245,7 +245,8 @@ __git_ps1_show_upstream ()\n>\n>  # Helper function that is meant to be called from __git_ps1.  It\n>  # injects color codes into the appropriate gitstring variables used\n> -# to build a gitstring.\n> +# to build a gitstring. Colored variables are responsible for clearing\n> +# their own color.\n>  __git_ps1_colorize_gitstring ()\n>  {\n>         if [[ -n ${ZSH_VERSION-} ]]; then\n> @@ -271,22 +272,23 @@ __git_ps1_colorize_gitstring ()\n>         else\n>                 branch_color=\"$bad_color\"\n>         fi\n> -       c=\"$branch_color$c\"\n> +       if [ -n \"$c\" ]; then\n> +               c=\"$branch_color$c$c_clear\"\n> +       fi\n> +       b=\"$branch_color$b$c_clear\"\n>\n> -       z=\"$c_clear$z\"\n>         if [ \"$w\" = \"*\" ]; then\n> -               w=\"$bad_color$w\"\n> +               w=\"$bad_color$w$c_clear\"\n>         fi\n>         if [ -n \"$i\" ]; then\n> -               i=\"$ok_color$i\"\n> +               i=\"$ok_color$i$c_clear\"\n>         fi\n>         if [ -n \"$s\" ]; then\n> -               s=\"$flags_color$s\"\n> +               s=\"$flags_color$s$c_clear\"\n>         fi\n>         if [ -n \"$u\" ]; then\n> -               u=\"$bad_color$u\"\n> +               u=\"$bad_color$u$c_clear\"\n>         fi\n> -       r=\"$c_clear$r\"\n>  }\n>\n>  # Helper function to read the first line of a file into a variable.\n> @@ -554,6 +556,7 @@ __git_ps1 ()\n>                 fi\n>         fi\n>\n> +       b=${b##refs/heads/}\n>         local z=\"${GIT_PS1_STATESEPARATOR-\" \"}\"\n>\n>         # NO color option unless in PROMPT_COMMAND mode or it's Zsh\n> @@ -563,7 +566,6 @@ __git_ps1 ()\n>                 fi\n>         fi\n>\n> -       b=${b##refs/heads/}\n>         if [ $pcmode = yes ] && [ $ps1_expanded = yes ]; then\n>                 __git_ps1_branch_name=$b\n>                 b=\"\\${__git_ps1_branch_name}\"\n> diff --git a/t/t9903-bash-prompt.sh b/t/t9903-bash-prompt.sh\n> index bbd513bab0..abd82eec35 100755\n> --- a/t/t9903-bash-prompt.sh\n> +++ b/t/t9903-bash-prompt.sh\n> @@ -541,7 +541,7 @@ test_expect_success 'prompt - pc mode' '\n>  '\n>\n>  test_expect_success 'prompt - bash color pc mode - branch name' '\n> -       printf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear}):AFTER\\\\nmain\" >expected &&\n> +       printf \"BEFORE: (\\${__git_ps1_branch_name}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n>         (\n>                 GIT_PS1_SHOWCOLORHINTS=y &&\n>                 __git_ps1 \"BEFORE:\" \":AFTER\" >\"$actual\" &&\n> @@ -551,7 +551,7 @@ test_expect_success 'prompt - bash color pc mode - branch name' '\n>  '\n>\n>  test_expect_success 'prompt - bash color pc mode - detached head' '\n> -       printf \"BEFORE: (${c_red}\\${__git_ps1_branch_name}${c_clear}):AFTER\\\\n(%s...)\" $(git log -1 --format=\"%h\" b1^) >expected &&\n> +       printf \"BEFORE: (\\${__git_ps1_branch_name}):AFTER\\\\n${c_red}(%s...)\"${c_clear} $(git log -1 --format=\"%h\" b1^) >expected &&\n>         git checkout b1^ &&\n>         test_when_finished \"git checkout main\" &&\n>         (\n> @@ -563,7 +563,7 @@ test_expect_success 'prompt - bash color pc mode - detached head' '\n>  '\n>\n>  test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirty worktree' '\n> -       printf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear} ${c_red}*${c_clear}):AFTER\\\\nmain\" >expected &&\n> +       printf \"BEFORE: (\\${__git_ps1_branch_name} ${c_red}*${c_clear}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n>         echo \"dirty\" >file &&\n>         test_when_finished \"git reset --hard\" &&\n>         (\n> @@ -576,7 +576,7 @@ test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirt\n>  '\n>\n>  test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirty index' '\n> -       printf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear} ${c_green}+${c_clear}):AFTER\\\\nmain\" >expected &&\n> +       printf \"BEFORE: (\\${__git_ps1_branch_name} ${c_green}+${c_clear}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n>         echo \"dirty\" >file &&\n>         test_when_finished \"git reset --hard\" &&\n>         git add -u &&\n> @@ -590,7 +590,7 @@ test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirt\n>  '\n>\n>  test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirty index and worktree' '\n> -       printf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear} ${c_red}*${c_green}+${c_clear}):AFTER\\\\nmain\" >expected &&\n> +       printf \"BEFORE: (\\${__git_ps1_branch_name} ${c_red}*${c_clear}${c_green}+${c_clear}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n>         echo \"dirty index\" >file &&\n>         test_when_finished \"git reset --hard\" &&\n>         git add -u &&\n> @@ -605,7 +605,7 @@ test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirt\n>  '\n>\n>  test_expect_success 'prompt - bash color pc mode - dirty status indicator - before root commit' '\n> -       printf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear} ${c_green}#${c_clear}):AFTER\\\\nmain\" >expected &&\n> +       printf \"BEFORE: (\\${__git_ps1_branch_name} ${c_green}#${c_clear}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n>         (\n>                 GIT_PS1_SHOWDIRTYSTATE=y &&\n>                 GIT_PS1_SHOWCOLORHINTS=y &&\n> @@ -617,7 +617,7 @@ test_expect_success 'prompt - bash color pc mode - dirty status indicator - befo\n>  '\n>\n>  test_expect_success 'prompt - bash color pc mode - inside .git directory' '\n> -       printf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear}):AFTER\\\\nGIT_DIR!\" >expected &&\n> +       printf \"BEFORE: (\\${__git_ps1_branch_name}):AFTER\\\\n${c_green}GIT_DIR!${c_clear}\" >expected &&\n>         echo \"dirty\" >file &&\n>         test_when_finished \"git reset --hard\" &&\n>         (\n> @@ -631,7 +631,7 @@ test_expect_success 'prompt - bash color pc mode - inside .git directory' '\n>  '\n>\n>  test_expect_success 'prompt - bash color pc mode - stash status indicator' '\n> -       printf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear} ${c_lblue}\\$${c_clear}):AFTER\\\\nmain\" >expected &&\n> +       printf \"BEFORE: (\\${__git_ps1_branch_name} ${c_lblue}\\$${c_clear}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n>         echo 2 >file &&\n>         git stash &&\n>         test_when_finished \"git stash drop\" &&\n> @@ -645,7 +645,7 @@ test_expect_success 'prompt - bash color pc mode - stash status indicator' '\n>  '\n>\n>  test_expect_success 'prompt - bash color pc mode - untracked files status indicator' '\n> -       printf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear} ${c_red}%%${c_clear}):AFTER\\\\nmain\" >expected &&\n> +       printf \"BEFORE: (\\${__git_ps1_branch_name} ${c_red}%%${c_clear}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n>         (\n>                 GIT_PS1_SHOWUNTRACKEDFILES=y &&\n>                 GIT_PS1_SHOWCOLORHINTS=y &&\n> --\n> 2.36.1\n>\n\nI like this solution. This isn't new, but does anybody know if there\nis a reason why `$w` is compared for equality to \"*\" as opposed to\njust checking whether it's a nonempty value (`-n`)? I think I'd\ngenerally prefer it to be consistent with the others, which has the\nadded benefit of continuing to work if the asterisk is ever changed to\nsomething else.\n"},{"id":"456690","messageId":"5e6850aa-e2ba-e7d5-0abc-b1190f7b0f9f@online.no","threadId":"57941","inReplyTo":"CAGTqyRxS9aBitVivSTqojX_C_VBdgrD7JkUKgKSE6apjabzvQg@mail.gmail.com","subject":"Re: [PATCH v4] git-prompt: make colourization consistent","fromName":"Joakim Petersen","fromEmail":"joak-pet@online.no","sentAt":"2022-06-04T19:18:53Z","receivedAt":"2022-06-04T19:26:24Z","isPatch":true,"sender":{"key":"joak-pet@online.no","avatar":"https://avatars.githubusercontent.com/u/107927072?v=4"},"body":"On 04/06/2022 19:30, Justin Donnelly wrote:\n> I like this solution. This isn't new, but does anybody know if there\n> is a reason why `$w` is compared for equality to \"*\" as opposed to\n> just checking whether it's a nonempty value (`-n`)? I think I'd\n> generally prefer it to be consistent with the others, which has the\n> added benefit of continuing to work if the asterisk is ever changed to\n> something else.\n> \n\nLooking at the commit that introduced colourization, 9b7e776c0a5 (show \ncolor hints based on state of the git tree, 2012-10-10), it looks like\nthe author wanted the be as specific as possible in the check, with $w\nonly being empty or holding a '*', while $i could hold multiple\ndifferent indicators. Since the layout of the script has changed\nsignificantly since then, I'll submit a v5 shortly with the $w check\naltered.\n"},{"id":"456691","messageId":"20220604192606.176023-1-joak-pet@online.no","threadId":"57941","inReplyTo":"20220604161333.54627-1-joak-pet@online.no","subject":"[PATCH v5] git-prompt: make colourization consistent","fromName":"Joakim Petersen","fromEmail":"joak-pet@online.no","sentAt":"2022-06-04T19:26:06Z","receivedAt":"2022-06-04T19:26:24Z","isPatch":true,"sender":{"key":"joak-pet@online.no","avatar":"https://avatars.githubusercontent.com/u/107927072?v=4"},"body":"The short upstream state indicator inherits the colour of the last short\nstate indicator before it (if there is one), and the sparsity state\nindicator inherits this colour as well. Make the colourization of these\nstate indicators consistent by making all colourized indicators clear\ntheir own colour.\n\nAs of 0ec7c23cdc6 (git-prompt: make upstream state indicator location\nconsistent, 2022-02-27), colourization in the output of __git_ps1 has\nchanged such that the short upstream state indicator inherits the colour\nof the last short state indicator before it (if there is one), while\nbefore this change it was white/the default text colour. Some examples\nto illustrate this behaviour (assuming all indicators are enabled and\ncolourization is on):\n * If there is something in the stash, both the '$' and the short\n   upstream state indicator following it will be blue.\n * If the local tree has new, untracked files and there is nothing in\n   the stash, both the '%' and the    short upstream state indicator\n   will be red.\n * If all local changes are added to the index and the stash is empty,\n   both the '+' and the short upstream state indicator following it will\n   be green.\n * If the local tree is clean and there is nothing in the stash, the\n   short upstream state indicator will be white/${default text colour}.\n\nThis appears to be an unintended side-effect of the change, and makes\nlittle sense semantically (e.g. why is it bad to be in sync with\nupstream when you have uncommitted local changes?). The cause of the\nchange is that previously, the short upstream state indicator appeared\nimmediately after the rebase/revert/bisect/merge state indicator (note\nthe position of $p in $gitstring):\n\n\tlocal f=\"$h$w$i$s$u\"\n\tlocal gitstring=\"$c$b${f:+$z$f}${sparse}$r$p\"\n\t\nSaid indicator is prepended with the clear colour code, and the short\nupstream state indicator is thus also uncoloured. Now, the short\nupstream state indicator follows the sequence of colourized indicators,\nwithout any clearing of colour (again note the position of $p, now in\n$f):\n\n\tlocal f=\"$h$w$i$s$u$p\"\n\tlocal gitstring=\"$c$b${f:+$z$f}${sparse}$r${upstream}\"\n\nIf the user is in a sparse checkout, the sparsity state indicator\nfollows a similar pattern to the short upstream state indicator.\nHowever, clearing colour of the colourized indicators changes how the\nsparsity state indicator is colourized , as it currently inherits (and\nbefore the change referenced also inherited) the colour of the last\nshort state indicator before it. Reading the commit message of the\nchange that introduced the sparsity state indicator, afda36dbf3b\n(git-prompt: include sparsity state as well, 2020-06-21), it appears\nthis colourization also was unintended, so clearing the colour for said\nindicator further increases consistency.\n\nColouring of $c was made dependent on it not being empty, as it is no\nlonger being used to colour the branch name. Removal of $b's prefix was\nmoved to before the colourization so it gets cleared properly now that\ncolour codes are inserted into it.\n\nDue to colour clearing being moved into the variables for each coloured\nindicator, the tests for the coloured Bash prompt had to be changed:\n * All colour tests now have the colour codes around the expected\n   content of the expanded $__git_ps1_branch_name variable instead of\n   the unexpanded variable in the string.\n * The test with two indicators had a clear-colour code inserted after\n   the symbol for the first indicator, since all indicators clear their\n   own colours now.\n\nSigned-off-by: Joakim Petersen <joak-pet@online.no>\n---\nChanges since v4:\n * The check for whether to colourize $w has been altered to match the\n   checks for the other indicators.\n\nRange-diff against v4:\n1:  98ce78ddc5 ! 1:  fffef5f73d git-prompt: make colourization consistent\n    @@ contrib/completion/git-prompt.sh: __git_ps1_colorize_gitstring ()\n     +\tb=\"$branch_color$b$c_clear\"\n      \n     -\tz=\"$c_clear$z\"\n    - \tif [ \"$w\" = \"*\" ]; then\n    +-\tif [ \"$w\" = \"*\" ]; then\n     -\t\tw=\"$bad_color$w\"\n    ++\tif [ -n \"$w\" ]; then\n     +\t\tw=\"$bad_color$w$c_clear\"\n      \tfi\n      \tif [ -n \"$i\" ]; then\n\n contrib/completion/git-prompt.sh | 22 ++++++++++++----------\n t/t9903-bash-prompt.sh           | 18 +++++++++---------\n 2 files changed, 21 insertions(+), 19 deletions(-)\n\ndiff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh\nindex 87b2b916c0..cb01c2fd5d 100644\n--- a/contrib/completion/git-prompt.sh\n+++ b/contrib/completion/git-prompt.sh\n@@ -245,7 +245,8 @@ __git_ps1_show_upstream ()\n \n # Helper function that is meant to be called from __git_ps1.  It\n # injects color codes into the appropriate gitstring variables used\n-# to build a gitstring.\n+# to build a gitstring. Colored variables are responsible for clearing\n+# their own color.\n __git_ps1_colorize_gitstring ()\n {\n \tif [[ -n ${ZSH_VERSION-} ]]; then\n@@ -271,22 +272,23 @@ __git_ps1_colorize_gitstring ()\n \telse\n \t\tbranch_color=\"$bad_color\"\n \tfi\n-\tc=\"$branch_color$c\"\n+\tif [ -n \"$c\" ]; then\n+\t\tc=\"$branch_color$c$c_clear\"\n+\tfi\n+\tb=\"$branch_color$b$c_clear\"\n \n-\tz=\"$c_clear$z\"\n-\tif [ \"$w\" = \"*\" ]; then\n-\t\tw=\"$bad_color$w\"\n+\tif [ -n \"$w\" ]; then\n+\t\tw=\"$bad_color$w$c_clear\"\n \tfi\n \tif [ -n \"$i\" ]; then\n-\t\ti=\"$ok_color$i\"\n+\t\ti=\"$ok_color$i$c_clear\"\n \tfi\n \tif [ -n \"$s\" ]; then\n-\t\ts=\"$flags_color$s\"\n+\t\ts=\"$flags_color$s$c_clear\"\n \tfi\n \tif [ -n \"$u\" ]; then\n-\t\tu=\"$bad_color$u\"\n+\t\tu=\"$bad_color$u$c_clear\"\n \tfi\n-\tr=\"$c_clear$r\"\n }\n \n # Helper function to read the first line of a file into a variable.\n@@ -554,6 +556,7 @@ __git_ps1 ()\n \t\tfi\n \tfi\n \n+\tb=${b##refs/heads/}\n \tlocal z=\"${GIT_PS1_STATESEPARATOR-\" \"}\"\n \n \t# NO color option unless in PROMPT_COMMAND mode or it's Zsh\n@@ -563,7 +566,6 @@ __git_ps1 ()\n \t\tfi\n \tfi\n \n-\tb=${b##refs/heads/}\n \tif [ $pcmode = yes ] && [ $ps1_expanded = yes ]; then\n \t\t__git_ps1_branch_name=$b\n \t\tb=\"\\${__git_ps1_branch_name}\"\ndiff --git a/t/t9903-bash-prompt.sh b/t/t9903-bash-prompt.sh\nindex bbd513bab0..abd82eec35 100755\n--- a/t/t9903-bash-prompt.sh\n+++ b/t/t9903-bash-prompt.sh\n@@ -541,7 +541,7 @@ test_expect_success 'prompt - pc mode' '\n '\n \n test_expect_success 'prompt - bash color pc mode - branch name' '\n-\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear}):AFTER\\\\nmain\" >expected &&\n+\tprintf \"BEFORE: (\\${__git_ps1_branch_name}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n \t(\n \t\tGIT_PS1_SHOWCOLORHINTS=y &&\n \t\t__git_ps1 \"BEFORE:\" \":AFTER\" >\"$actual\" &&\n@@ -551,7 +551,7 @@ test_expect_success 'prompt - bash color pc mode - branch name' '\n '\n \n test_expect_success 'prompt - bash color pc mode - detached head' '\n-\tprintf \"BEFORE: (${c_red}\\${__git_ps1_branch_name}${c_clear}):AFTER\\\\n(%s...)\" $(git log -1 --format=\"%h\" b1^) >expected &&\n+\tprintf \"BEFORE: (\\${__git_ps1_branch_name}):AFTER\\\\n${c_red}(%s...)\"${c_clear} $(git log -1 --format=\"%h\" b1^) >expected &&\n \tgit checkout b1^ &&\n \ttest_when_finished \"git checkout main\" &&\n \t(\n@@ -563,7 +563,7 @@ test_expect_success 'prompt - bash color pc mode - detached head' '\n '\n \n test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirty worktree' '\n-\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear} ${c_red}*${c_clear}):AFTER\\\\nmain\" >expected &&\n+\tprintf \"BEFORE: (\\${__git_ps1_branch_name} ${c_red}*${c_clear}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n \techo \"dirty\" >file &&\n \ttest_when_finished \"git reset --hard\" &&\n \t(\n@@ -576,7 +576,7 @@ test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirt\n '\n \n test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirty index' '\n-\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear} ${c_green}+${c_clear}):AFTER\\\\nmain\" >expected &&\n+\tprintf \"BEFORE: (\\${__git_ps1_branch_name} ${c_green}+${c_clear}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n \techo \"dirty\" >file &&\n \ttest_when_finished \"git reset --hard\" &&\n \tgit add -u &&\n@@ -590,7 +590,7 @@ test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirt\n '\n \n test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirty index and worktree' '\n-\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear} ${c_red}*${c_green}+${c_clear}):AFTER\\\\nmain\" >expected &&\n+\tprintf \"BEFORE: (\\${__git_ps1_branch_name} ${c_red}*${c_clear}${c_green}+${c_clear}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n \techo \"dirty index\" >file &&\n \ttest_when_finished \"git reset --hard\" &&\n \tgit add -u &&\n@@ -605,7 +605,7 @@ test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirt\n '\n \n test_expect_success 'prompt - bash color pc mode - dirty status indicator - before root commit' '\n-\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear} ${c_green}#${c_clear}):AFTER\\\\nmain\" >expected &&\n+\tprintf \"BEFORE: (\\${__git_ps1_branch_name} ${c_green}#${c_clear}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n \t(\n \t\tGIT_PS1_SHOWDIRTYSTATE=y &&\n \t\tGIT_PS1_SHOWCOLORHINTS=y &&\n@@ -617,7 +617,7 @@ test_expect_success 'prompt - bash color pc mode - dirty status indicator - befo\n '\n \n test_expect_success 'prompt - bash color pc mode - inside .git directory' '\n-\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear}):AFTER\\\\nGIT_DIR!\" >expected &&\n+\tprintf \"BEFORE: (\\${__git_ps1_branch_name}):AFTER\\\\n${c_green}GIT_DIR!${c_clear}\" >expected &&\n \techo \"dirty\" >file &&\n \ttest_when_finished \"git reset --hard\" &&\n \t(\n@@ -631,7 +631,7 @@ test_expect_success 'prompt - bash color pc mode - inside .git directory' '\n '\n \n test_expect_success 'prompt - bash color pc mode - stash status indicator' '\n-\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear} ${c_lblue}\\$${c_clear}):AFTER\\\\nmain\" >expected &&\n+\tprintf \"BEFORE: (\\${__git_ps1_branch_name} ${c_lblue}\\$${c_clear}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n \techo 2 >file &&\n \tgit stash &&\n \ttest_when_finished \"git stash drop\" &&\n@@ -645,7 +645,7 @@ test_expect_success 'prompt - bash color pc mode - stash status indicator' '\n '\n \n test_expect_success 'prompt - bash color pc mode - untracked files status indicator' '\n-\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear} ${c_red}%%${c_clear}):AFTER\\\\nmain\" >expected &&\n+\tprintf \"BEFORE: (\\${__git_ps1_branch_name} ${c_red}%%${c_clear}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n \t(\n \t\tGIT_PS1_SHOWUNTRACKEDFILES=y &&\n \t\tGIT_PS1_SHOWCOLORHINTS=y &&\n-- \n2.36.1\n\n"},{"id":"456705","messageId":"466ec54a-825b-c3e6-e9f2-a7007af71b6d@gmail.com","threadId":"57941","inReplyTo":"20220604192606.176023-1-joak-pet@online.no","subject":"Re: [PATCH v5] git-prompt: make colourization consistent","fromName":"Bagas Sanjaya","fromEmail":"bagasdotme@gmail.com","sentAt":"2022-06-06T07:23:11Z","receivedAt":"2022-06-06T07:23:28Z","isPatch":true,"sender":{"key":"bagasdotme@gmail.com","avatar":"https://avatars.githubusercontent.com/u/40219486?v=4"},"body":"On 6/5/22 02:26, Joakim Petersen wrote:\n> If the user is in a sparse checkout, the sparsity state indicator\n> follows a similar pattern to the short upstream state indicator.\n> However, clearing colour of the colourized indicators changes how the\n> sparsity state indicator is colourized , as it currently inherits (and\n> before the change referenced also inherited) the colour of the last\n> short state indicator before it. Reading the commit message of the\n> change that introduced the sparsity state indicator, afda36dbf3b\n> (git-prompt: include sparsity state as well, 2020-06-21), it appears\n> this colourization also was unintended, so clearing the colour for said\n> indicator further increases consistency.\n> \n\ncolourization? I have never heared that. Did you mean \"colorization\" (en-US)\nor \"colourisation\" (en-UK)? I assumed the former.\n\n-- \nAn old man doll... just what I always wanted! - Clara\n"},{"id":"456720","messageId":"xmqq7d5tbwio.fsf@gitster.g","threadId":"57941","inReplyTo":"ed7d78a5-3c70-df5a-81c3-bdb631271700@online.no","subject":"Re: [PATCH v3] git-prompt: make colourization consistent","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-06-06T16:13:19Z","receivedAt":"2022-06-06T16:13:24Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Joakim Petersen <joak-pet@online.no> writes:\n\n> There might be something I'm not seeing, but having it so each element\n> counters whatever colour left by the preceding element seems less\n> intuitive when adding or moving elements in the final $gitstring. Adding\n> an element will then require going into __git_ps1_colorize_gitstring,\n> even when it is not intended to be colourized. All existing uncoloured\n> elements will also need to be prefixed to protect against colour bleed\n> from being moved around. I'm partial to the idea of each coloured\n> element clearing its own colour.\n\nI think that each makes sense in its own way.  Depending on what\nassumption we can make on the use of terminal attributes, one can\nproduce shorter output than the other.\n\nFor example, if you have 3 things, A, B, and C, that are shown in\nthis order, the \"clear after yourselves\" scheme would give\n\n\tgitstring=<red>A<clear><blue>B<clear><green>C<clear>\n\nwhile \"clear the slate for yourself before you draw, the framework\nwill clear the effect of the last one\" scheme can give\n\n\tgitstring=<red>A<blue>B<green>C<clear>\n\nif we know that no additive terminal attributes are used, and the\nlatter gives a shorter output.\n\nIf we need to support some additive ones (like \"reverse\"), on the\nother hand, and if each element is independent (i.e. \"clear the\nslate for me\" cannot use the knowledge of what the previous one\ndid), then we have to write\n\n\tgitstring=<red>A<clear><blue>B<clear><green>C<clear>\n\nfor the latter, which becomes more verbose (but is the same as the\n\"each is on its own, clear after yourselves\" version).\n\nI have no strong preference either way myself.  \"each on its own\"\nmight be conceptually simpler and easier to understand and explain\nwhat is going on.\n\nThanks.\n"},{"id":"456721","messageId":"xmqqzgipah7n.fsf@gitster.g","threadId":"57941","inReplyTo":"20220604192606.176023-1-joak-pet@online.no","subject":"Re: [PATCH v5] git-prompt: make colourization consistent","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-06-06T16:29:16Z","receivedAt":"2022-06-06T16:29:42Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Joakim Petersen <joak-pet@online.no> writes:\n\n> The short upstream state indicator inherits the colour of the last short\n> state indicator before it (if there is one), and the sparsity state\n> indicator inherits this colour as well. Make the colourization of these\n> state indicators consistent by making all colourized indicators clear\n> their own colour.\n\n> As of 0ec7c23cdc6 (git-prompt: make upstream state indicator location\n> consistent, 2022-02-27), colourization in the output of __git_ps1 has\n> changed such that the short upstream state indicator inherits the colour\n> of the last short state indicator before it (if there is one), while\n> before this change it was white/the default text colour. Some examples\n> to illustrate this behaviour (assuming all indicators are enabled and\n> colourization is on):\n>  * If there is something in the stash, both the '$' and the short\n>    upstream state indicator following it will be blue.\n>  * If the local tree has new, untracked files and there is nothing in\n>    the stash, both the '%' and the    short upstream state indicator\n\nlooong space?\n\n>    will be red.\n>  * If all local changes are added to the index and the stash is empty,\n>    both the '+' and the short upstream state indicator following it will\n>    be green.\n>  * If the local tree is clean and there is nothing in the stash, the\n>    short upstream state indicator will be white/${default text colour}.\n>\n> This appears to be an unintended side-effect of the change, and makes\n> little sense semantically (e.g. why is it bad to be in sync with\n> upstream when you have uncommitted local changes?). The cause of the\n> change is that previously, the short upstream state indicator appeared\n> immediately after the rebase/revert/bisect/merge state indicator (note\n> the position of $p in $gitstring):\n>\n> \tlocal f=\"$h$w$i$s$u\"\n> \tlocal gitstring=\"$c$b${f:+$z$f}${sparse}$r$p\"\n> \t\n> Said indicator is prepended with the clear colour code, and the short\n> upstream state indicator is thus also uncoloured. Now, the short\n> upstream state indicator follows the sequence of colourized indicators,\n> without any clearing of colour (again note the position of $p, now in\n> $f):\n>\n> \tlocal f=\"$h$w$i$s$u$p\"\n> \tlocal gitstring=\"$c$b${f:+$z$f}${sparse}$r${upstream}\"\n>\n> If the user is in a sparse checkout, the sparsity state indicator\n> follows a similar pattern to the short upstream state indicator.\n> However, clearing colour of the colourized indicators changes how the\n> sparsity state indicator is colourized , as it currently inherits (and\n> before the change referenced also inherited) the colour of the last\n> short state indicator before it. Reading the commit message of the\n> change that introduced the sparsity state indicator, afda36dbf3b\n> (git-prompt: include sparsity state as well, 2020-06-21), it appears\n> this colourization also was unintended, so clearing the colour for said\n> indicator further increases consistency.\n\nHere, after explaining how bad the current situation is, like the\nabove, is a good place to say what we do, i.e. \"teach indicators to\nclear after themselves\".\n\n> Colouring of $c was made dependent on it not being empty, as it is no\n> longer being used to colour the branch name. Removal of $b's prefix was\n> moved to before the colourization so it gets cleared properly now that\n> colour codes are inserted into it.\n>\n> Due to colour clearing being moved into the variables for each coloured\n> indicator, the tests for the coloured Bash prompt had to be changed:\n>  * All colour tests now have the colour codes around the expected\n>    content of the expanded $__git_ps1_branch_name variable instead of\n>    the unexpanded variable in the string.\n>  * The test with two indicators had a clear-colour code inserted after\n>    the symbol for the first indicator, since all indicators clear their\n>    own colours now.\n>\n> Signed-off-by: Joakim Petersen <joak-pet@online.no>\n> ---\n\nNicely written.\n\nWill queue.\n\nThanks.\n"},{"id":"456729","messageId":"592c0133-d6f3-3376-0fe7-3633f3a91377@online.no","threadId":"57941","inReplyTo":"xmqqzgipah7n.fsf@gitster.g","subject":"Re: [PATCH v5] git-prompt: make colourization consistent","fromName":"Joakim Petersen","fromEmail":"joak-pet@online.no","sentAt":"2022-06-06T17:31:31Z","receivedAt":"2022-06-06T17:31:43Z","isPatch":true,"sender":{"key":"joak-pet@online.no","avatar":"https://avatars.githubusercontent.com/u/107927072?v=4"},"body":"On 06/06/2022 18:29, Junio C Hamano wrote:\n> Joakim Petersen <joak-pet@online.no> writes:\n>>   * If the local tree has new, untracked files and there is nothing in\n>>     the stash, both the '%' and the    short upstream state indicator\n> \n> looong space?\n> \n\nThat is quite the long space indeed, I'll get that fixed.\n\n>> If the user is in a sparse checkout, the sparsity state indicator\n>> follows a similar pattern to the short upstream state indicator.\n>> However, clearing colour of the colourized indicators changes how the\n>> sparsity state indicator is colourized , as it currently inherits (and\n>> before the change referenced also inherited) the colour of the last\n>> short state indicator before it. Reading the commit message of the\n>> change that introduced the sparsity state indicator, afda36dbf3b\n>> (git-prompt: include sparsity state as well, 2020-06-21), it appears\n>> this colourization also was unintended, so clearing the colour for said\n>> indicator further increases consistency.\n> \n> Here, after explaining how bad the current situation is, like the\n> above, is a good place to say what we do, i.e. \"teach indicators to\n> clear after themselves\".\n\nI'll add a clear statement of what this patch does as well.\n\n> \n> Nicely written.\n> \n> Will queue.\n> \n> Thanks.\n> \nAlright, great!\n"},{"id":"456731","messageId":"xmqqleu98za3.fsf@gitster.g","threadId":"57941","inReplyTo":"592c0133-d6f3-3376-0fe7-3633f3a91377@online.no","subject":"Re: [PATCH v5] git-prompt: make colourization consistent","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-06-06T17:41:56Z","receivedAt":"2022-06-06T17:42:03Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Joakim Petersen <joak-pet@online.no> writes:\n\n> On 06/06/2022 18:29, Junio C Hamano wrote:\n>> Joakim Petersen <joak-pet@online.no> writes:\n>>>   * If the local tree has new, untracked files and there is nothing in\n>>>     the stash, both the '%' and the    short upstream state indicator\n>> looong space?\n>> \n>\n> That is quite the long space indeed, I'll get that fixed.\n>\n>>> If the user is in a sparse checkout, the sparsity state indicator\n>>> follows a similar pattern to the short upstream state indicator.\n>>> However, clearing colour of the colourized indicators changes how the\n>>> sparsity state indicator is colourized , as it currently inherits (and\n>>> before the change referenced also inherited) the colour of the last\n>>> short state indicator before it. Reading the commit message of the\n>>> change that introduced the sparsity state indicator, afda36dbf3b\n>>> (git-prompt: include sparsity state as well, 2020-06-21), it appears\n>>> this colourization also was unintended, so clearing the colour for said\n>>> indicator further increases consistency.\n>> Here, after explaining how bad the current situation is, like the\n>> above, is a good place to say what we do, i.e. \"teach indicators to\n>> clear after themselves\".\n>\n> I'll add a clear statement of what this patch does as well.\n\nI think you already have \"Make the coloring of these ... consistent\nby making ...\" much earlier, and moving it here would be sufficient.\n\n>> Nicely written.\n>> Will queue.\n>> Thanks.\n>> \n> Alright, great!\n"},{"id":"456736","messageId":"20220606175022.8410-1-joak-pet@online.no","threadId":"57941","inReplyTo":"20220604192606.176023-1-joak-pet@online.no","subject":"[PATCH v6] git-prompt: make colourization consistent","fromName":"Joakim Petersen","fromEmail":"joak-pet@online.no","sentAt":"2022-06-06T17:50:22Z","receivedAt":"2022-06-06T17:50:55Z","isPatch":true,"sender":{"key":"joak-pet@online.no","avatar":"https://avatars.githubusercontent.com/u/107927072?v=4"},"body":"The short upstream state indicator inherits the colour of the last short\nstate indicator before it (if there is one), and the sparsity state\nindicator inherits this colour as well. Make the colourization of these\nstate indicators consistent by making all colourized indicators clear\ntheir own colour.\n\nAs of 0ec7c23cdc6 (git-prompt: make upstream state indicator location\nconsistent, 2022-02-27), colourization in the output of __git_ps1 has\nchanged such that the short upstream state indicator inherits the colour\nof the last short state indicator before it (if there is one), while\nbefore this change it was white/the default text colour. Some examples\nto illustrate this behaviour (assuming all indicators are enabled and\ncolourization is on):\n * If there is something in the stash, both the '$' and the short\n   upstream state indicator following it will be blue.\n * If the local tree has new, untracked files and there is nothing in\n   the stash, both the '%' and the short upstream state indicator\n   will be red.\n * If all local changes are added to the index and the stash is empty,\n   both the '+' and the short upstream state indicator following it will\n   be green.\n * If the local tree is clean and there is nothing in the stash, the\n   short upstream state indicator will be white/${default text colour}.\n\nThis appears to be an unintended side-effect of the change, and makes\nlittle sense semantically (e.g. why is it bad to be in sync with\nupstream when you have uncommitted local changes?). The cause of the\nchange in colourization is that previously, the short upstream state\nindicator appeared immediately after the rebase/revert/bisect/merge\nstate indicator (note the position of $p in $gitstring):\n\n\tlocal f=\"$h$w$i$s$u\"\n\tlocal gitstring=\"$c$b${f:+$z$f}${sparse}$r$p\"\n\t\nSaid indicator is prepended with the clear colour code, and the short\nupstream state indicator is thus also uncoloured. Now, the short\nupstream state indicator follows the sequence of colourized indicators,\nwithout any clearing of colour (again note the position of $p, now in\n$f):\n\n\tlocal f=\"$h$w$i$s$u$p\"\n\tlocal gitstring=\"$c$b${f:+$z$f}${sparse}$r${upstream}\"\n\nIf the user is in a sparse checkout, the sparsity state indicator\nfollows a similar pattern to the short upstream state indicator.\nHowever, clearing colour of the colourized indicators changes how the\nsparsity state indicator is colourized, as it currently inherits (and\nbefore the change referenced also inherited) the colour of the last\nshort state indicator before it. Reading the commit message of the\nchange that introduced the sparsity state indicator, afda36dbf3b\n(git-prompt: include sparsity state as well, 2020-06-21), it appears\nthis colourization also was unintended, so clearing the colour for said\nindicator further increases consistency.\n\nTeach indicators to clear their own colours. Make colouring of $c\ndependent on it not being empty, as it is no longer being used to colour\nthe branch name. Move clearing of $b's prefix to before colourization so\nit gets cleared properly when colour codes are inserted into it.\n\nChange coloured Bash prompt tests to reflect the colourization changes:\n * Move the colour codes to wrap the expected content of the expanded\n   $__git_ps1_branch_name in all tests.\n * Insert a clear-colour code after the symbol for the first indicator\n   in \"prompt - bash color pc mode - dirty status indicator - dirty\n   index and worktree\", to reflect that all indicators should clear\n   their own colour.\n\nSigned-off-by: Joakim Petersen <joak-pet@online.no>\n---\nChanges since v5:\n * Rephrase the explanation of what this patch does to be in the\n   imperative mood and add a clear summarizing statement of what the\n   patch does.\n * Fixed the long space and removed another stray space.\n\nRange-diff against v5:\n1:  fffef5f73d = 1:  50765eeb95 git-prompt: make colourization consistent\n\n contrib/completion/git-prompt.sh | 22 ++++++++++++----------\n t/t9903-bash-prompt.sh           | 18 +++++++++---------\n 2 files changed, 21 insertions(+), 19 deletions(-)\n\ndiff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh\nindex 87b2b916c0..cb01c2fd5d 100644\n--- a/contrib/completion/git-prompt.sh\n+++ b/contrib/completion/git-prompt.sh\n@@ -245,7 +245,8 @@ __git_ps1_show_upstream ()\n \n # Helper function that is meant to be called from __git_ps1.  It\n # injects color codes into the appropriate gitstring variables used\n-# to build a gitstring.\n+# to build a gitstring. Colored variables are responsible for clearing\n+# their own color.\n __git_ps1_colorize_gitstring ()\n {\n \tif [[ -n ${ZSH_VERSION-} ]]; then\n@@ -271,22 +272,23 @@ __git_ps1_colorize_gitstring ()\n \telse\n \t\tbranch_color=\"$bad_color\"\n \tfi\n-\tc=\"$branch_color$c\"\n+\tif [ -n \"$c\" ]; then\n+\t\tc=\"$branch_color$c$c_clear\"\n+\tfi\n+\tb=\"$branch_color$b$c_clear\"\n \n-\tz=\"$c_clear$z\"\n-\tif [ \"$w\" = \"*\" ]; then\n-\t\tw=\"$bad_color$w\"\n+\tif [ -n \"$w\" ]; then\n+\t\tw=\"$bad_color$w$c_clear\"\n \tfi\n \tif [ -n \"$i\" ]; then\n-\t\ti=\"$ok_color$i\"\n+\t\ti=\"$ok_color$i$c_clear\"\n \tfi\n \tif [ -n \"$s\" ]; then\n-\t\ts=\"$flags_color$s\"\n+\t\ts=\"$flags_color$s$c_clear\"\n \tfi\n \tif [ -n \"$u\" ]; then\n-\t\tu=\"$bad_color$u\"\n+\t\tu=\"$bad_color$u$c_clear\"\n \tfi\n-\tr=\"$c_clear$r\"\n }\n \n # Helper function to read the first line of a file into a variable.\n@@ -554,6 +556,7 @@ __git_ps1 ()\n \t\tfi\n \tfi\n \n+\tb=${b##refs/heads/}\n \tlocal z=\"${GIT_PS1_STATESEPARATOR-\" \"}\"\n \n \t# NO color option unless in PROMPT_COMMAND mode or it's Zsh\n@@ -563,7 +566,6 @@ __git_ps1 ()\n \t\tfi\n \tfi\n \n-\tb=${b##refs/heads/}\n \tif [ $pcmode = yes ] && [ $ps1_expanded = yes ]; then\n \t\t__git_ps1_branch_name=$b\n \t\tb=\"\\${__git_ps1_branch_name}\"\ndiff --git a/t/t9903-bash-prompt.sh b/t/t9903-bash-prompt.sh\nindex bbd513bab0..abd82eec35 100755\n--- a/t/t9903-bash-prompt.sh\n+++ b/t/t9903-bash-prompt.sh\n@@ -541,7 +541,7 @@ test_expect_success 'prompt - pc mode' '\n '\n \n test_expect_success 'prompt - bash color pc mode - branch name' '\n-\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear}):AFTER\\\\nmain\" >expected &&\n+\tprintf \"BEFORE: (\\${__git_ps1_branch_name}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n \t(\n \t\tGIT_PS1_SHOWCOLORHINTS=y &&\n \t\t__git_ps1 \"BEFORE:\" \":AFTER\" >\"$actual\" &&\n@@ -551,7 +551,7 @@ test_expect_success 'prompt - bash color pc mode - branch name' '\n '\n \n test_expect_success 'prompt - bash color pc mode - detached head' '\n-\tprintf \"BEFORE: (${c_red}\\${__git_ps1_branch_name}${c_clear}):AFTER\\\\n(%s...)\" $(git log -1 --format=\"%h\" b1^) >expected &&\n+\tprintf \"BEFORE: (\\${__git_ps1_branch_name}):AFTER\\\\n${c_red}(%s...)\"${c_clear} $(git log -1 --format=\"%h\" b1^) >expected &&\n \tgit checkout b1^ &&\n \ttest_when_finished \"git checkout main\" &&\n \t(\n@@ -563,7 +563,7 @@ test_expect_success 'prompt - bash color pc mode - detached head' '\n '\n \n test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirty worktree' '\n-\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear} ${c_red}*${c_clear}):AFTER\\\\nmain\" >expected &&\n+\tprintf \"BEFORE: (\\${__git_ps1_branch_name} ${c_red}*${c_clear}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n \techo \"dirty\" >file &&\n \ttest_when_finished \"git reset --hard\" &&\n \t(\n@@ -576,7 +576,7 @@ test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirt\n '\n \n test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirty index' '\n-\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear} ${c_green}+${c_clear}):AFTER\\\\nmain\" >expected &&\n+\tprintf \"BEFORE: (\\${__git_ps1_branch_name} ${c_green}+${c_clear}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n \techo \"dirty\" >file &&\n \ttest_when_finished \"git reset --hard\" &&\n \tgit add -u &&\n@@ -590,7 +590,7 @@ test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirt\n '\n \n test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirty index and worktree' '\n-\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear} ${c_red}*${c_green}+${c_clear}):AFTER\\\\nmain\" >expected &&\n+\tprintf \"BEFORE: (\\${__git_ps1_branch_name} ${c_red}*${c_clear}${c_green}+${c_clear}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n \techo \"dirty index\" >file &&\n \ttest_when_finished \"git reset --hard\" &&\n \tgit add -u &&\n@@ -605,7 +605,7 @@ test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirt\n '\n \n test_expect_success 'prompt - bash color pc mode - dirty status indicator - before root commit' '\n-\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear} ${c_green}#${c_clear}):AFTER\\\\nmain\" >expected &&\n+\tprintf \"BEFORE: (\\${__git_ps1_branch_name} ${c_green}#${c_clear}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n \t(\n \t\tGIT_PS1_SHOWDIRTYSTATE=y &&\n \t\tGIT_PS1_SHOWCOLORHINTS=y &&\n@@ -617,7 +617,7 @@ test_expect_success 'prompt - bash color pc mode - dirty status indicator - befo\n '\n \n test_expect_success 'prompt - bash color pc mode - inside .git directory' '\n-\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear}):AFTER\\\\nGIT_DIR!\" >expected &&\n+\tprintf \"BEFORE: (\\${__git_ps1_branch_name}):AFTER\\\\n${c_green}GIT_DIR!${c_clear}\" >expected &&\n \techo \"dirty\" >file &&\n \ttest_when_finished \"git reset --hard\" &&\n \t(\n@@ -631,7 +631,7 @@ test_expect_success 'prompt - bash color pc mode - inside .git directory' '\n '\n \n test_expect_success 'prompt - bash color pc mode - stash status indicator' '\n-\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear} ${c_lblue}\\$${c_clear}):AFTER\\\\nmain\" >expected &&\n+\tprintf \"BEFORE: (\\${__git_ps1_branch_name} ${c_lblue}\\$${c_clear}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n \techo 2 >file &&\n \tgit stash &&\n \ttest_when_finished \"git stash drop\" &&\n@@ -645,7 +645,7 @@ test_expect_success 'prompt - bash color pc mode - stash status indicator' '\n '\n \n test_expect_success 'prompt - bash color pc mode - untracked files status indicator' '\n-\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear} ${c_red}%%${c_clear}):AFTER\\\\nmain\" >expected &&\n+\tprintf \"BEFORE: (\\${__git_ps1_branch_name} ${c_red}%%${c_clear}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n \t(\n \t\tGIT_PS1_SHOWUNTRACKEDFILES=y &&\n \t\tGIT_PS1_SHOWCOLORHINTS=y &&\n-- \n2.36.1\n\n"},{"id":"456785","messageId":"6c73ec69-5246-4386-4e20-b2ed852ec4ff@online.no","threadId":"57941","inReplyTo":"xmqqleu98za3.fsf@gitster.g","subject":"Re: [PATCH v5] git-prompt: make colourization consistent","fromName":"Joakim Petersen","fromEmail":"joak-pet@online.no","sentAt":"2022-06-07T11:49:08Z","receivedAt":"2022-06-07T11:49:18Z","isPatch":true,"sender":{"key":"joak-pet@online.no","avatar":"https://avatars.githubusercontent.com/u/107927072?v=4"},"body":"On 06/06/2022 19:41, Junio C Hamano wrote:\n> Joakim Petersen <joak-pet@online.no> writes:\n>> I'll add a clear statement of what this patch does as well.\n> \n> I think you already have \"Make the coloring of these ... consistent\n> by making ...\" much earlier, and moving it here would be sufficient.\n> \n\nThis comment made me realize there is some additional redundancy in the\nmessage; I'll submit a v7 with a slightly clearer one, incorporating\nyour suggestion as well.\n"},{"id":"456786","messageId":"20220607115024.64724-1-joak-pet@online.no","threadId":"57941","inReplyTo":"20220606175022.8410-1-joak-pet@online.no","subject":"[PATCH v7] git-prompt: make colourization consistent","fromName":"Joakim Petersen","fromEmail":"joak-pet@online.no","sentAt":"2022-06-07T11:50:24Z","receivedAt":"2022-06-07T11:50:47Z","isPatch":true,"sender":{"key":"joak-pet@online.no","avatar":"https://avatars.githubusercontent.com/u/107927072?v=4"},"body":"The short upstream state indicator inherits the colour of the last short\nstate indicator before it (if there is one), and the sparsity state\nindicator inherits this colour as well. This behaviour was introduced by\n0ec7c23cdc6 (git-prompt: make upstream state indicator location\nconsistent, 2022-02-27), while before this change the aforementioned\nindicators were white/the default text colour. Some examples to\nillustrate this behaviour (assuming all indicators are enabled and\ncolourization is on):\n * If there is something in the stash, both the '$' and the short\n   upstream state indicator following it will be blue.\n * If the local tree has new, untracked files and there is nothing in\n   the stash, both the '%' and the short upstream state indicator\n   will be red.\n * If all local changes are added to the index and the stash is empty,\n   both the '+' and the short upstream state indicator following it will\n   be green.\n * If the local tree is clean and there is nothing in the stash, the\n   short upstream state indicator will be white/${default text colour}.\n\nThis appears to be an unintended side-effect of the change, and makes\nlittle sense semantically (e.g. why is it bad to be in sync with\nupstream when you have uncommitted local changes?). The cause of the\nchange in colourization is that previously, the short upstream state\nindicator appeared immediately after the rebase/revert/bisect/merge\nstate indicator (note the position of $p in $gitstring):\n\n\tlocal f=\"$h$w$i$s$u\"\n\tlocal gitstring=\"$c$b${f:+$z$f}${sparse}$r$p\"\n\t\nSaid indicator is prepended with the clear colour code, and the short\nupstream state indicator is thus also uncoloured. Now, the short\nupstream state indicator follows the sequence of colourized indicators,\nwithout any clearing of colour (again note the position of $p, now in\n$f):\n\n\tlocal f=\"$h$w$i$s$u$p\"\n\tlocal gitstring=\"$c$b${f:+$z$f}${sparse}$r${upstream}\"\n\nIf the user is in a sparse checkout, the sparsity state indicator\nfollows a similar pattern to the short upstream state indicator.\nHowever, clearing colour of the colourized indicators changes how the\nsparsity state indicator is colourized, as it currently inherits (and\nbefore the change referenced also inherited) the colour of the last\nshort state indicator before it. Reading the commit message of the\nchange that introduced the sparsity state indicator, afda36dbf3b\n(git-prompt: include sparsity state as well, 2020-06-21), it appears\nthis colourization also was unintended, so clearing the colour for said\nindicator further increases consistency.\n\nMake the colourization of these state indicators consistent by making\nall colourized indicators clear their own colour. Make colouring of $c\ndependent on it not being empty, as it is no longer being used to colour\nthe branch name. Move clearing of $b's prefix to before colourization so\nit gets cleared properly when colour codes are inserted into it. These\nchanges make changing the layout of the prompt less prone to unintended\ncolour changes in the future.\n\nChange coloured Bash prompt tests to reflect the colourization changes:\n * Move the colour codes to wrap the expected content of the expanded\n   $__git_ps1_branch_name in all tests.\n * Insert a clear-colour code after the symbol for the first indicator\n   in \"prompt - bash color pc mode - dirty status indicator - dirty\n   index and worktree\", to reflect that all indicators should clear\n   their own colour.\n\nSigned-off-by: Joakim Petersen <joak-pet@online.no>\n---\nChanges since v6:\n * Remove repeated statements and move all explanation of what the patch\n   does to the latter part of the message.\n * Add a short statement about other benefits of the behavioural change.\n\nRange-diff against v6:\n1:  50765eeb95 = 1:  e25738c667 git-prompt: make colourization consistent\n\n contrib/completion/git-prompt.sh | 22 ++++++++++++----------\n t/t9903-bash-prompt.sh           | 18 +++++++++---------\n 2 files changed, 21 insertions(+), 19 deletions(-)\n\ndiff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh\nindex 87b2b916c0..cb01c2fd5d 100644\n--- a/contrib/completion/git-prompt.sh\n+++ b/contrib/completion/git-prompt.sh\n@@ -245,7 +245,8 @@ __git_ps1_show_upstream ()\n \n # Helper function that is meant to be called from __git_ps1.  It\n # injects color codes into the appropriate gitstring variables used\n-# to build a gitstring.\n+# to build a gitstring. Colored variables are responsible for clearing\n+# their own color.\n __git_ps1_colorize_gitstring ()\n {\n \tif [[ -n ${ZSH_VERSION-} ]]; then\n@@ -271,22 +272,23 @@ __git_ps1_colorize_gitstring ()\n \telse\n \t\tbranch_color=\"$bad_color\"\n \tfi\n-\tc=\"$branch_color$c\"\n+\tif [ -n \"$c\" ]; then\n+\t\tc=\"$branch_color$c$c_clear\"\n+\tfi\n+\tb=\"$branch_color$b$c_clear\"\n \n-\tz=\"$c_clear$z\"\n-\tif [ \"$w\" = \"*\" ]; then\n-\t\tw=\"$bad_color$w\"\n+\tif [ -n \"$w\" ]; then\n+\t\tw=\"$bad_color$w$c_clear\"\n \tfi\n \tif [ -n \"$i\" ]; then\n-\t\ti=\"$ok_color$i\"\n+\t\ti=\"$ok_color$i$c_clear\"\n \tfi\n \tif [ -n \"$s\" ]; then\n-\t\ts=\"$flags_color$s\"\n+\t\ts=\"$flags_color$s$c_clear\"\n \tfi\n \tif [ -n \"$u\" ]; then\n-\t\tu=\"$bad_color$u\"\n+\t\tu=\"$bad_color$u$c_clear\"\n \tfi\n-\tr=\"$c_clear$r\"\n }\n \n # Helper function to read the first line of a file into a variable.\n@@ -554,6 +556,7 @@ __git_ps1 ()\n \t\tfi\n \tfi\n \n+\tb=${b##refs/heads/}\n \tlocal z=\"${GIT_PS1_STATESEPARATOR-\" \"}\"\n \n \t# NO color option unless in PROMPT_COMMAND mode or it's Zsh\n@@ -563,7 +566,6 @@ __git_ps1 ()\n \t\tfi\n \tfi\n \n-\tb=${b##refs/heads/}\n \tif [ $pcmode = yes ] && [ $ps1_expanded = yes ]; then\n \t\t__git_ps1_branch_name=$b\n \t\tb=\"\\${__git_ps1_branch_name}\"\ndiff --git a/t/t9903-bash-prompt.sh b/t/t9903-bash-prompt.sh\nindex bbd513bab0..abd82eec35 100755\n--- a/t/t9903-bash-prompt.sh\n+++ b/t/t9903-bash-prompt.sh\n@@ -541,7 +541,7 @@ test_expect_success 'prompt - pc mode' '\n '\n \n test_expect_success 'prompt - bash color pc mode - branch name' '\n-\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear}):AFTER\\\\nmain\" >expected &&\n+\tprintf \"BEFORE: (\\${__git_ps1_branch_name}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n \t(\n \t\tGIT_PS1_SHOWCOLORHINTS=y &&\n \t\t__git_ps1 \"BEFORE:\" \":AFTER\" >\"$actual\" &&\n@@ -551,7 +551,7 @@ test_expect_success 'prompt - bash color pc mode - branch name' '\n '\n \n test_expect_success 'prompt - bash color pc mode - detached head' '\n-\tprintf \"BEFORE: (${c_red}\\${__git_ps1_branch_name}${c_clear}):AFTER\\\\n(%s...)\" $(git log -1 --format=\"%h\" b1^) >expected &&\n+\tprintf \"BEFORE: (\\${__git_ps1_branch_name}):AFTER\\\\n${c_red}(%s...)\"${c_clear} $(git log -1 --format=\"%h\" b1^) >expected &&\n \tgit checkout b1^ &&\n \ttest_when_finished \"git checkout main\" &&\n \t(\n@@ -563,7 +563,7 @@ test_expect_success 'prompt - bash color pc mode - detached head' '\n '\n \n test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirty worktree' '\n-\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear} ${c_red}*${c_clear}):AFTER\\\\nmain\" >expected &&\n+\tprintf \"BEFORE: (\\${__git_ps1_branch_name} ${c_red}*${c_clear}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n \techo \"dirty\" >file &&\n \ttest_when_finished \"git reset --hard\" &&\n \t(\n@@ -576,7 +576,7 @@ test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirt\n '\n \n test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirty index' '\n-\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear} ${c_green}+${c_clear}):AFTER\\\\nmain\" >expected &&\n+\tprintf \"BEFORE: (\\${__git_ps1_branch_name} ${c_green}+${c_clear}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n \techo \"dirty\" >file &&\n \ttest_when_finished \"git reset --hard\" &&\n \tgit add -u &&\n@@ -590,7 +590,7 @@ test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirt\n '\n \n test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirty index and worktree' '\n-\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear} ${c_red}*${c_green}+${c_clear}):AFTER\\\\nmain\" >expected &&\n+\tprintf \"BEFORE: (\\${__git_ps1_branch_name} ${c_red}*${c_clear}${c_green}+${c_clear}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n \techo \"dirty index\" >file &&\n \ttest_when_finished \"git reset --hard\" &&\n \tgit add -u &&\n@@ -605,7 +605,7 @@ test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirt\n '\n \n test_expect_success 'prompt - bash color pc mode - dirty status indicator - before root commit' '\n-\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear} ${c_green}#${c_clear}):AFTER\\\\nmain\" >expected &&\n+\tprintf \"BEFORE: (\\${__git_ps1_branch_name} ${c_green}#${c_clear}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n \t(\n \t\tGIT_PS1_SHOWDIRTYSTATE=y &&\n \t\tGIT_PS1_SHOWCOLORHINTS=y &&\n@@ -617,7 +617,7 @@ test_expect_success 'prompt - bash color pc mode - dirty status indicator - befo\n '\n \n test_expect_success 'prompt - bash color pc mode - inside .git directory' '\n-\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear}):AFTER\\\\nGIT_DIR!\" >expected &&\n+\tprintf \"BEFORE: (\\${__git_ps1_branch_name}):AFTER\\\\n${c_green}GIT_DIR!${c_clear}\" >expected &&\n \techo \"dirty\" >file &&\n \ttest_when_finished \"git reset --hard\" &&\n \t(\n@@ -631,7 +631,7 @@ test_expect_success 'prompt - bash color pc mode - inside .git directory' '\n '\n \n test_expect_success 'prompt - bash color pc mode - stash status indicator' '\n-\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear} ${c_lblue}\\$${c_clear}):AFTER\\\\nmain\" >expected &&\n+\tprintf \"BEFORE: (\\${__git_ps1_branch_name} ${c_lblue}\\$${c_clear}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n \techo 2 >file &&\n \tgit stash &&\n \ttest_when_finished \"git stash drop\" &&\n@@ -645,7 +645,7 @@ test_expect_success 'prompt - bash color pc mode - stash status indicator' '\n '\n \n test_expect_success 'prompt - bash color pc mode - untracked files status indicator' '\n-\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear} ${c_red}%%${c_clear}):AFTER\\\\nmain\" >expected &&\n+\tprintf \"BEFORE: (\\${__git_ps1_branch_name} ${c_red}%%${c_clear}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n \t(\n \t\tGIT_PS1_SHOWUNTRACKEDFILES=y &&\n \t\tGIT_PS1_SHOWCOLORHINTS=y &&\n-- \n2.36.1\n\n"},{"id":"456792","messageId":"xmqq4k0w1mu7.fsf@gitster.g","threadId":"57941","inReplyTo":"466ec54a-825b-c3e6-e9f2-a7007af71b6d@gmail.com","subject":"Re: [PATCH v5] git-prompt: make colourization consistent","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-06-07T16:04:48Z","receivedAt":"2022-06-07T16:04:57Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Bagas Sanjaya <bagasdotme@gmail.com> writes:\n\n> On 6/5/22 02:26, Joakim Petersen wrote:\n>> If the user is in a sparse checkout, the sparsity state indicator\n>> follows a similar pattern to the short upstream state indicator.\n>> However, clearing colour of the colourized indicators changes how the\n>> sparsity state indicator is colourized , as it currently inherits (and\n>> before the change referenced also inherited) the colour of the last\n>> short state indicator before it. Reading the commit message of the\n>> change that introduced the sparsity state indicator, afda36dbf3b\n>> (git-prompt: include sparsity state as well, 2020-06-21), it appears\n>> this colourization also was unintended, so clearing the colour for said\n>> indicator further increases consistency.\n>> \n>\n> colourization? I have never heared that. Did you mean \"colorization\" (en-US)\n> or \"colourisation\" (en-UK)? I assumed the former.\n\n;-)  \n\nEither way, that word is a mouthful.  Using verb \"to color\" and\n\"coloring\" might be easier to read, perhaps?\n"},{"id":"456793","messageId":"xmqqzgiozbn8.fsf@gitster.g","threadId":"57941","inReplyTo":"20220607115024.64724-1-joak-pet@online.no","subject":"Re: [PATCH v7] git-prompt: make colourization consistent","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-06-07T16:22:35Z","receivedAt":"2022-06-07T16:22:48Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Joakim Petersen <joak-pet@online.no> writes:\n\n> The short upstream state indicator inherits the colour of the last short\n> state indicator before it (if there is one), and the sparsity state\n> indicator inherits this colour as well. This behaviour was introduced by\n> 0ec7c23cdc6 (git-prompt: make upstream state indicator location\n> consistent, 2022-02-27), while before this change the aforementioned\n> indicators were white/the default text colour. Some examples to\n> illustrate this behaviour (assuming all indicators are enabled and\n> colourization is on):\n>  * If there is something in the stash, both the '$' and the short\n>    upstream state indicator following it will be blue.\n>  * If the local tree has new, untracked files and there is nothing in\n>    the stash, both the '%' and the short upstream state indicator\n>    will be red.\n>  * If all local changes are added to the index and the stash is empty,\n>    both the '+' and the short upstream state indicator following it will\n>    be green.\n>  * If the local tree is clean and there is nothing in the stash, the\n>    short upstream state indicator will be white/${default text colour}.\n>\n> This appears to be an unintended side-effect of the change, and makes\n> little sense semantically (e.g. why is it bad to be in sync with\n> upstream when you have uncommitted local changes?). The cause of the\n> change in colourization is that previously, the short upstream state\n> indicator appeared immediately after the rebase/revert/bisect/merge\n> state indicator (note the position of $p in $gitstring):\n>\n> \tlocal f=\"$h$w$i$s$u\"\n> \tlocal gitstring=\"$c$b${f:+$z$f}${sparse}$r$p\"\n> \t\n> Said indicator is prepended with the clear colour code, and the short\n> upstream state indicator is thus also uncoloured. Now, the short\n> upstream state indicator follows the sequence of colourized indicators,\n> without any clearing of colour (again note the position of $p, now in\n> $f):\n>\n> \tlocal f=\"$h$w$i$s$u$p\"\n> \tlocal gitstring=\"$c$b${f:+$z$f}${sparse}$r${upstream}\"\n>\n> If the user is in a sparse checkout, the sparsity state indicator\n> follows a similar pattern to the short upstream state indicator.\n> However, clearing colour of the colourized indicators changes how the\n> sparsity state indicator is colourized, as it currently inherits (and\n> before the change referenced also inherited) the colour of the last\n> short state indicator before it. Reading the commit message of the\n> change that introduced the sparsity state indicator, afda36dbf3b\n> (git-prompt: include sparsity state as well, 2020-06-21), it appears\n> this colourization also was unintended, so clearing the colour for said\n> indicator further increases consistency.\n>\n> Make the colourization of these state indicators consistent by making\n> all colourized indicators clear their own colour. Make colouring of $c\n> dependent on it not being empty, as it is no longer being used to colour\n> the branch name. Move clearing of $b's prefix to before colourization so\n> it gets cleared properly when colour codes are inserted into it. These\n> changes make changing the layout of the prompt less prone to unintended\n> colour changes in the future.\n>\n> Change coloured Bash prompt tests to reflect the colourization changes:\n>  * Move the colour codes to wrap the expected content of the expanded\n>    $__git_ps1_branch_name in all tests.\n>  * Insert a clear-colour code after the symbol for the first indicator\n>    in \"prompt - bash color pc mode - dirty status indicator - dirty\n>    index and worktree\", to reflect that all indicators should clear\n>    their own colour.\n>\n> Signed-off-by: Joakim Petersen <joak-pet@online.no>\n> ---\n> Changes since v6:\n>  * Remove repeated statements and move all explanation of what the patch\n>    does to the latter part of the message.\n>  * Add a short statement about other benefits of the behavioural change.\n\nThe handling of $w is different from the original (it used to be\nthat only '*' was painted in red, now any non-empty strings do), but\n'*' is the only value that can be assigned to $w, so there is no\nmaterial difference.\n\nLooking good.  Will queue.  Thanks.\n"},{"id":"456928","messageId":"20220609090302.GA1738@szeder.dev","threadId":"57941","inReplyTo":"20220607115024.64724-1-joak-pet@online.no","subject":"Re: [PATCH v7] git-prompt: make colourization consistent","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2022-06-09T09:03:02Z","receivedAt":"2022-06-09T09:03:11Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Tue, Jun 07, 2022 at 01:50:24PM +0200, Joakim Petersen wrote:\n> The short upstream state indicator inherits the colour of the last short\n> state indicator before it (if there is one), and the sparsity state\n> indicator inherits this colour as well. This behaviour was introduced by\n> 0ec7c23cdc6 (git-prompt: make upstream state indicator location\n> consistent, 2022-02-27), while before this change the aforementioned\n> indicators were white/the default text colour. Some examples to\n> illustrate this behaviour (assuming all indicators are enabled and\n> colourization is on):\n>  * If there is something in the stash, both the '$' and the short\n>    upstream state indicator following it will be blue.\n>  * If the local tree has new, untracked files and there is nothing in\n>    the stash, both the '%' and the short upstream state indicator\n>    will be red.\n>  * If all local changes are added to the index and the stash is empty,\n>    both the '+' and the short upstream state indicator following it will\n>    be green.\n>  * If the local tree is clean and there is nothing in the stash, the\n>    short upstream state indicator will be white/${default text colour}.\n> \n> This appears to be an unintended side-effect of the change, and makes\n> little sense semantically (e.g. why is it bad to be in sync with\n> upstream when you have uncommitted local changes?). The cause of the\n> change in colourization is that previously, the short upstream state\n> indicator appeared immediately after the rebase/revert/bisect/merge\n> state indicator (note the position of $p in $gitstring):\n> \n> \tlocal f=\"$h$w$i$s$u\"\n> \tlocal gitstring=\"$c$b${f:+$z$f}${sparse}$r$p\"\n> \t\n> Said indicator is prepended with the clear colour code, and the short\n> upstream state indicator is thus also uncoloured. Now, the short\n> upstream state indicator follows the sequence of colourized indicators,\n> without any clearing of colour (again note the position of $p, now in\n> $f):\n> \n> \tlocal f=\"$h$w$i$s$u$p\"\n> \tlocal gitstring=\"$c$b${f:+$z$f}${sparse}$r${upstream}\"\n> \n> If the user is in a sparse checkout, the sparsity state indicator\n> follows a similar pattern to the short upstream state indicator.\n> However, clearing colour of the colourized indicators changes how the\n> sparsity state indicator is colourized, as it currently inherits (and\n> before the change referenced also inherited) the colour of the last\n> short state indicator before it. Reading the commit message of the\n> change that introduced the sparsity state indicator, afda36dbf3b\n> (git-prompt: include sparsity state as well, 2020-06-21), it appears\n> this colourization also was unintended, so clearing the colour for said\n> indicator further increases consistency.\n> \n> Make the colourization of these state indicators consistent by making\n> all colourized indicators clear their own colour. Make colouring of $c\n> dependent on it not being empty, as it is no longer being used to colour\n> the branch name. Move clearing of $b's prefix to before colourization so\n> it gets cleared properly when colour codes are inserted into it. These\n> changes make changing the layout of the prompt less prone to unintended\n> colour changes in the future.\n> \n> Change coloured Bash prompt tests to reflect the colourization changes:\n>  * Move the colour codes to wrap the expected content of the expanded\n>    $__git_ps1_branch_name in all tests.\n>  * Insert a clear-colour code after the symbol for the first indicator\n>    in \"prompt - bash color pc mode - dirty status indicator - dirty\n>    index and worktree\", to reflect that all indicators should clear\n>    their own colour.\n\nThis patch seems to break colorization when __git_ps1() is invoked\nfrom $PROMPT_COMMAND:\n\n  ~/src/git (master)$ echo $PROMPT_COMMAND \n__git_ps1 \"\\[\\e]0;\\w - Terminal\\a\\e[01;32m\\]\\h\\[\\e[01;34m\\] \\w\" \"\\[\\e[01;34m\\]\\$\\[\\e[00m\\] \" \" \\[\\e[01;34m\\](%s\\[\\e[01;34m\\])\"\n  ~/src/git (master)$ git checkout 9470605a1b\n  HEAD is now at 9470605a1b git-prompt: make colourization consistent\n  ~/src/git ((9470605a1b...))$ source contrib/completion/git-prompt.sh \n  ~/src/git (\\[\\e[31m\\](9470605a1b...)\\[\\e[0m\\])$ # uh-oh\n  ~/src/git (\\[\\e[31m\\](9470605a1b...)\\[\\e[0m\\])$ git checkout 9470605a1b^\n  Previous HEAD position was 9470605a1b git-prompt: make colourization consistent\n  HEAD is now at 2668e3608e Sixth batch\n  ~/src/git (\\[\\e[31m\\](2668e3608e...)\\[\\e[0m\\])$ source contrib/completion/git-prompt.sh \n  ~/src/git ((2668e3608e...))$ # Looks good.\n\n\n> Signed-off-by: Joakim Petersen <joak-pet@online.no>\n> ---\n> Changes since v6:\n>  * Remove repeated statements and move all explanation of what the patch\n>    does to the latter part of the message.\n>  * Add a short statement about other benefits of the behavioural change.\n> \n> Range-diff against v6:\n> 1:  50765eeb95 = 1:  e25738c667 git-prompt: make colourization consistent\n> \n>  contrib/completion/git-prompt.sh | 22 ++++++++++++----------\n>  t/t9903-bash-prompt.sh           | 18 +++++++++---------\n>  2 files changed, 21 insertions(+), 19 deletions(-)\n> \n> diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh\n> index 87b2b916c0..cb01c2fd5d 100644\n> --- a/contrib/completion/git-prompt.sh\n> +++ b/contrib/completion/git-prompt.sh\n> @@ -245,7 +245,8 @@ __git_ps1_show_upstream ()\n>  \n>  # Helper function that is meant to be called from __git_ps1.  It\n>  # injects color codes into the appropriate gitstring variables used\n> -# to build a gitstring.\n> +# to build a gitstring. Colored variables are responsible for clearing\n> +# their own color.\n>  __git_ps1_colorize_gitstring ()\n>  {\n>  \tif [[ -n ${ZSH_VERSION-} ]]; then\n> @@ -271,22 +272,23 @@ __git_ps1_colorize_gitstring ()\n>  \telse\n>  \t\tbranch_color=\"$bad_color\"\n>  \tfi\n> -\tc=\"$branch_color$c\"\n> +\tif [ -n \"$c\" ]; then\n> +\t\tc=\"$branch_color$c$c_clear\"\n> +\tfi\n> +\tb=\"$branch_color$b$c_clear\"\n>  \n> -\tz=\"$c_clear$z\"\n> -\tif [ \"$w\" = \"*\" ]; then\n> -\t\tw=\"$bad_color$w\"\n> +\tif [ -n \"$w\" ]; then\n> +\t\tw=\"$bad_color$w$c_clear\"\n>  \tfi\n>  \tif [ -n \"$i\" ]; then\n> -\t\ti=\"$ok_color$i\"\n> +\t\ti=\"$ok_color$i$c_clear\"\n>  \tfi\n>  \tif [ -n \"$s\" ]; then\n> -\t\ts=\"$flags_color$s\"\n> +\t\ts=\"$flags_color$s$c_clear\"\n>  \tfi\n>  \tif [ -n \"$u\" ]; then\n> -\t\tu=\"$bad_color$u\"\n> +\t\tu=\"$bad_color$u$c_clear\"\n>  \tfi\n> -\tr=\"$c_clear$r\"\n>  }\n>  \n>  # Helper function to read the first line of a file into a variable.\n> @@ -554,6 +556,7 @@ __git_ps1 ()\n>  \t\tfi\n>  \tfi\n>  \n> +\tb=${b##refs/heads/}\n>  \tlocal z=\"${GIT_PS1_STATESEPARATOR-\" \"}\"\n>  \n>  \t# NO color option unless in PROMPT_COMMAND mode or it's Zsh\n> @@ -563,7 +566,6 @@ __git_ps1 ()\n>  \t\tfi\n>  \tfi\n>  \n> -\tb=${b##refs/heads/}\n>  \tif [ $pcmode = yes ] && [ $ps1_expanded = yes ]; then\n>  \t\t__git_ps1_branch_name=$b\n>  \t\tb=\"\\${__git_ps1_branch_name}\"\n> diff --git a/t/t9903-bash-prompt.sh b/t/t9903-bash-prompt.sh\n> index bbd513bab0..abd82eec35 100755\n> --- a/t/t9903-bash-prompt.sh\n> +++ b/t/t9903-bash-prompt.sh\n> @@ -541,7 +541,7 @@ test_expect_success 'prompt - pc mode' '\n>  '\n>  \n>  test_expect_success 'prompt - bash color pc mode - branch name' '\n> -\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear}):AFTER\\\\nmain\" >expected &&\n> +\tprintf \"BEFORE: (\\${__git_ps1_branch_name}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n>  \t(\n>  \t\tGIT_PS1_SHOWCOLORHINTS=y &&\n>  \t\t__git_ps1 \"BEFORE:\" \":AFTER\" >\"$actual\" &&\n> @@ -551,7 +551,7 @@ test_expect_success 'prompt - bash color pc mode - branch name' '\n>  '\n>  \n>  test_expect_success 'prompt - bash color pc mode - detached head' '\n> -\tprintf \"BEFORE: (${c_red}\\${__git_ps1_branch_name}${c_clear}):AFTER\\\\n(%s...)\" $(git log -1 --format=\"%h\" b1^) >expected &&\n> +\tprintf \"BEFORE: (\\${__git_ps1_branch_name}):AFTER\\\\n${c_red}(%s...)\"${c_clear} $(git log -1 --format=\"%h\" b1^) >expected &&\n>  \tgit checkout b1^ &&\n>  \ttest_when_finished \"git checkout main\" &&\n>  \t(\n> @@ -563,7 +563,7 @@ test_expect_success 'prompt - bash color pc mode - detached head' '\n>  '\n>  \n>  test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirty worktree' '\n> -\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear} ${c_red}*${c_clear}):AFTER\\\\nmain\" >expected &&\n> +\tprintf \"BEFORE: (\\${__git_ps1_branch_name} ${c_red}*${c_clear}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n>  \techo \"dirty\" >file &&\n>  \ttest_when_finished \"git reset --hard\" &&\n>  \t(\n> @@ -576,7 +576,7 @@ test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirt\n>  '\n>  \n>  test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirty index' '\n> -\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear} ${c_green}+${c_clear}):AFTER\\\\nmain\" >expected &&\n> +\tprintf \"BEFORE: (\\${__git_ps1_branch_name} ${c_green}+${c_clear}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n>  \techo \"dirty\" >file &&\n>  \ttest_when_finished \"git reset --hard\" &&\n>  \tgit add -u &&\n> @@ -590,7 +590,7 @@ test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirt\n>  '\n>  \n>  test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirty index and worktree' '\n> -\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear} ${c_red}*${c_green}+${c_clear}):AFTER\\\\nmain\" >expected &&\n> +\tprintf \"BEFORE: (\\${__git_ps1_branch_name} ${c_red}*${c_clear}${c_green}+${c_clear}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n>  \techo \"dirty index\" >file &&\n>  \ttest_when_finished \"git reset --hard\" &&\n>  \tgit add -u &&\n> @@ -605,7 +605,7 @@ test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirt\n>  '\n>  \n>  test_expect_success 'prompt - bash color pc mode - dirty status indicator - before root commit' '\n> -\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear} ${c_green}#${c_clear}):AFTER\\\\nmain\" >expected &&\n> +\tprintf \"BEFORE: (\\${__git_ps1_branch_name} ${c_green}#${c_clear}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n>  \t(\n>  \t\tGIT_PS1_SHOWDIRTYSTATE=y &&\n>  \t\tGIT_PS1_SHOWCOLORHINTS=y &&\n> @@ -617,7 +617,7 @@ test_expect_success 'prompt - bash color pc mode - dirty status indicator - befo\n>  '\n>  \n>  test_expect_success 'prompt - bash color pc mode - inside .git directory' '\n> -\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear}):AFTER\\\\nGIT_DIR!\" >expected &&\n> +\tprintf \"BEFORE: (\\${__git_ps1_branch_name}):AFTER\\\\n${c_green}GIT_DIR!${c_clear}\" >expected &&\n>  \techo \"dirty\" >file &&\n>  \ttest_when_finished \"git reset --hard\" &&\n>  \t(\n> @@ -631,7 +631,7 @@ test_expect_success 'prompt - bash color pc mode - inside .git directory' '\n>  '\n>  \n>  test_expect_success 'prompt - bash color pc mode - stash status indicator' '\n> -\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear} ${c_lblue}\\$${c_clear}):AFTER\\\\nmain\" >expected &&\n> +\tprintf \"BEFORE: (\\${__git_ps1_branch_name} ${c_lblue}\\$${c_clear}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n>  \techo 2 >file &&\n>  \tgit stash &&\n>  \ttest_when_finished \"git stash drop\" &&\n> @@ -645,7 +645,7 @@ test_expect_success 'prompt - bash color pc mode - stash status indicator' '\n>  '\n>  \n>  test_expect_success 'prompt - bash color pc mode - untracked files status indicator' '\n> -\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear} ${c_red}%%${c_clear}):AFTER\\\\nmain\" >expected &&\n> +\tprintf \"BEFORE: (\\${__git_ps1_branch_name} ${c_red}%%${c_clear}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n>  \t(\n>  \t\tGIT_PS1_SHOWUNTRACKEDFILES=y &&\n>  \t\tGIT_PS1_SHOWCOLORHINTS=y &&\n> -- \n> 2.36.1\n> \n"},{"id":"456931","messageId":"736a5f12-2ab3-977c-8cba-45529e9ebee0@online.no","threadId":"57941","inReplyTo":"20220609090302.GA1738@szeder.dev","subject":"Re: [PATCH v7] git-prompt: make colourization consistent","fromName":"Joakim Petersen","fromEmail":"joak-pet@online.no","sentAt":"2022-06-09T11:13:34Z","receivedAt":"2022-06-09T11:13:46Z","isPatch":true,"sender":{"key":"joak-pet@online.no","avatar":"https://avatars.githubusercontent.com/u/107927072?v=4"},"body":"On 09/06/2022 11:03, SZEDER Gábor wrote:\n> This patch seems to break colorization when __git_ps1() is invoked\n> from $PROMPT_COMMAND:\n> \n>    ~/src/git (master)$ echo $PROMPT_COMMAND\n> __git_ps1 \"\\[\\e]0;\\w - Terminal\\a\\e[01;32m\\]\\h\\[\\e[01;34m\\] \\w\" \"\\[\\e[01;34m\\]\\$\\[\\e[00m\\] \" \" \\[\\e[01;34m\\](%s\\[\\e[01;34m\\])\"\n>    ~/src/git (master)$ git checkout 9470605a1b\n>    HEAD is now at 9470605a1b git-prompt: make colourization consistent\n>    ~/src/git ((9470605a1b...))$ source contrib/completion/git-prompt.sh\n>    ~/src/git (\\[\\e[31m\\](9470605a1b...)\\[\\e[0m\\])$ # uh-oh\n>    ~/src/git (\\[\\e[31m\\](9470605a1b...)\\[\\e[0m\\])$ git checkout 9470605a1b^\n>    Previous HEAD position was 9470605a1b git-prompt: make colourization consistent\n>    HEAD is now at 2668e3608e Sixth batch\n>    ~/src/git (\\[\\e[31m\\](2668e3608e...)\\[\\e[0m\\])$ source contrib/completion/git-prompt.sh\n>    ~/src/git ((2668e3608e...))$ # Looks good.\n> \n\nWhile I did test this on my own prompt for v6 (which is identical to v7\nin terms of code) and not see any breakage, I have the same issue with\nv7. Maybe I forgot to re-source the changed git-prompt.sh. Either way,\nThe issue stems from $b being wrapped in $__git_ps1_branch_name and then\nback into itself after colouring. Moving this wrapping to before colour\nis applied fixes this. I will submit a v8 shortly.\n"},{"id":"456932","messageId":"2b48b94e-44e7-9abb-4afe-51060b6b298a@online.no","threadId":"57941","inReplyTo":"xmqqzgiozbn8.fsf@gitster.g","subject":"Re: [PATCH v7] git-prompt: make colourization consistent","fromName":"Joakim Petersen","fromEmail":"joak-pet@online.no","sentAt":"2022-06-09T11:16:31Z","receivedAt":"2022-06-09T11:16:36Z","isPatch":true,"sender":{"key":"joak-pet@online.no","avatar":"https://avatars.githubusercontent.com/u/107927072?v=4"},"body":"On 07/06/2022 18:22, Junio C Hamano wrote:\n> Joakim Petersen <joak-pet@online.no> writes:\n> \n>> The short upstream state indicator inherits the colour of the last short\n>> state indicator before it (if there is one), and the sparsity state\n>> indicator inherits this colour as well. This behaviour was introduced by\n>> 0ec7c23cdc6 (git-prompt: make upstream state indicator location\n>> consistent, 2022-02-27), while before this change the aforementioned\n>> indicators were white/the default text colour. Some examples to\n>> illustrate this behaviour (assuming all indicators are enabled and\n>> colourization is on):\n>>   * If there is something in the stash, both the '$' and the short\n>>     upstream state indicator following it will be blue.\n>>   * If the local tree has new, untracked files and there is nothing in\n>>     the stash, both the '%' and the short upstream state indicator\n>>     will be red.\n>>   * If all local changes are added to the index and the stash is empty,\n>>     both the '+' and the short upstream state indicator following it will\n>>     be green.\n>>   * If the local tree is clean and there is nothing in the stash, the\n>>     short upstream state indicator will be white/${default text colour}.\n>>\n>> This appears to be an unintended side-effect of the change, and makes\n>> little sense semantically (e.g. why is it bad to be in sync with\n>> upstream when you have uncommitted local changes?). The cause of the\n>> change in colourization is that previously, the short upstream state\n>> indicator appeared immediately after the rebase/revert/bisect/merge\n>> state indicator (note the position of $p in $gitstring):\n>>\n>> \tlocal f=\"$h$w$i$s$u\"\n>> \tlocal gitstring=\"$c$b${f:+$z$f}${sparse}$r$p\"\n>> \t\n>> Said indicator is prepended with the clear colour code, and the short\n>> upstream state indicator is thus also uncoloured. Now, the short\n>> upstream state indicator follows the sequence of colourized indicators,\n>> without any clearing of colour (again note the position of $p, now in\n>> $f):\n>>\n>> \tlocal f=\"$h$w$i$s$u$p\"\n>> \tlocal gitstring=\"$c$b${f:+$z$f}${sparse}$r${upstream}\"\n>>\n>> If the user is in a sparse checkout, the sparsity state indicator\n>> follows a similar pattern to the short upstream state indicator.\n>> However, clearing colour of the colourized indicators changes how the\n>> sparsity state indicator is colourized, as it currently inherits (and\n>> before the change referenced also inherited) the colour of the last\n>> short state indicator before it. Reading the commit message of the\n>> change that introduced the sparsity state indicator, afda36dbf3b\n>> (git-prompt: include sparsity state as well, 2020-06-21), it appears\n>> this colourization also was unintended, so clearing the colour for said\n>> indicator further increases consistency.\n>>\n>> Make the colourization of these state indicators consistent by making\n>> all colourized indicators clear their own colour. Make colouring of $c\n>> dependent on it not being empty, as it is no longer being used to colour\n>> the branch name. Move clearing of $b's prefix to before colourization so\n>> it gets cleared properly when colour codes are inserted into it. These\n>> changes make changing the layout of the prompt less prone to unintended\n>> colour changes in the future.\n>>\n>> Change coloured Bash prompt tests to reflect the colourization changes:\n>>   * Move the colour codes to wrap the expected content of the expanded\n>>     $__git_ps1_branch_name in all tests.\n>>   * Insert a clear-colour code after the symbol for the first indicator\n>>     in \"prompt - bash color pc mode - dirty status indicator - dirty\n>>     index and worktree\", to reflect that all indicators should clear\n>>     their own colour.\n>>\n>> Signed-off-by: Joakim Petersen <joak-pet@online.no>\n>> ---\n>> Changes since v6:\n>>   * Remove repeated statements and move all explanation of what the patch\n>>     does to the latter part of the message.\n>>   * Add a short statement about other benefits of the behavioural change.\n> \n> The handling of $w is different from the original (it used to be\n> that only '*' was painted in red, now any non-empty strings do), but\n> '*' is the only value that can be assigned to $w, so there is no\n> material difference.\n> \n> Looking good.  Will queue.  Thanks.\n> \n\nThe change regarding $w was mentioned below --- for v5:\n > Changes since v4:\n >  * The check for whether to colourize $w has been altered to match the\n >    checks for the other indicators.\nI'll add a mention of this to the commit message as well.\n"},{"id":"456933","messageId":"cd3f62a1-5dee-f482-948f-870fc8e5d441@online.no","threadId":"57941","inReplyTo":"xmqq4k0w1mu7.fsf@gitster.g","subject":"Re: [PATCH v5] git-prompt: make colourization consistent","fromName":"Joakim Petersen","fromEmail":"joak-pet@online.no","sentAt":"2022-06-09T11:25:10Z","receivedAt":"2022-06-09T11:25:18Z","isPatch":true,"sender":{"key":"joak-pet@online.no","avatar":"https://avatars.githubusercontent.com/u/107927072?v=4"},"body":"On 07/06/2022 18:04, Junio C Hamano wrote:\n> Bagas Sanjaya <bagasdotme@gmail.com> writes:\n> \n>> On 6/5/22 02:26, Joakim Petersen wrote:\n>>> If the user is in a sparse checkout, the sparsity state indicator\n>>> follows a similar pattern to the short upstream state indicator.\n>>> However, clearing colour of the colourized indicators changes how the\n>>> sparsity state indicator is colourized , as it currently inherits (and\n>>> before the change referenced also inherited) the colour of the last\n>>> short state indicator before it. Reading the commit message of the\n>>> change that introduced the sparsity state indicator, afda36dbf3b\n>>> (git-prompt: include sparsity state as well, 2020-06-21), it appears\n>>> this colourization also was unintended, so clearing the colour for said\n>>> indicator further increases consistency.\n>>>\n>>\n>> colourization? I have never heared that. Did you mean \"colorization\" (en-US)\n>> or \"colourisation\" (en-UK)? I assumed the former.\n> \n> ;-)\n> \n> Either way, that word is a mouthful.  Using verb \"to color\" and\n> \"coloring\" might be easier to read, perhaps?\n> \n\nI went with \"colourization\" as that is what the process is referred to\nin the code, however, I do agree it is a mouthful compared to \"colour\".\nSince I'm already submitting a v8 for other reasons, I'll make this\nchange in the message as well.\n\nSince the comment about the choice of suffix spelling got picked up,\nI'll repeat what I told Bagas off list: \"-ize\" being American English\nis a misconception; most uses of \"z\" instead of \"s\" are AE, but the verb\nsuffix is closer to its origin in Greek with \"z\", and is preferred by\nOxford for this reason.\n"},{"id":"456937","messageId":"20220609114425.15122-1-joak-pet@online.no","threadId":"57941","inReplyTo":"20220607115024.64724-1-joak-pet@online.no","subject":"[PATCH v8] git-prompt: make colouring consistent","fromName":"Joakim Petersen","fromEmail":"joak-pet@online.no","sentAt":"2022-06-09T11:44:25Z","receivedAt":"2022-06-09T11:47:03Z","isPatch":true,"sender":{"key":"joak-pet@online.no","avatar":"https://avatars.githubusercontent.com/u/107927072?v=4"},"body":"The short upstream state indicator inherits the colour of the last short\nstate indicator before it (if there is one), and the sparsity state\nindicator inherits this colour as well. This behaviour was introduced by\n0ec7c23cdc6 (git-prompt: make upstream state indicator location\nconsistent, 2022-02-27), while before this change the aforementioned\nindicators were white/the default text colour. Some examples to\nillustrate this behaviour (assuming all indicators are enabled and\ncolourization is on):\n * If there is something in the stash, both the '$' and the short\n   upstream state indicator following it will be blue.\n * If the local tree has new, untracked files and there is nothing in\n   the stash, both the '%' and the short upstream state indicator\n   will be red.\n * If all local changes are added to the index and the stash is empty,\n   both the '+' and the short upstream state indicator following it will\n   be green.\n * If the local tree is clean and there is nothing in the stash, the\n   short upstream state indicator will be white/${default text colour}.\n\nThis appears to be an unintended side-effect of the change, and makes\nlittle sense semantically (e.g. why is it bad to be in sync with\nupstream when you have uncommitted local changes?). The cause of the\nchange in colour is that previously, the short upstream state indicator\nappeared immediately after the rebase/revert/bisect/merge state\nindicator (note the position of $p in $gitstring):\n\n\tlocal f=\"$h$w$i$s$u\"\n\tlocal gitstring=\"$c$b${f:+$z$f}${sparse}$r$p\"\n\t\nSaid indicator is prepended with the clear colour code, and the short\nupstream state indicator is thus also uncoloured. Now, the short\nupstream state indicator follows the sequence of coloured indicators,\nwithout any clearing of colour (again note the position of $p, now in\n$f):\n\n\tlocal f=\"$h$w$i$s$u$p\"\n\tlocal gitstring=\"$c$b${f:+$z$f}${sparse}$r${upstream}\"\n\nIf the user is in a sparse checkout, the sparsity state indicator\nfollows a similar pattern to the short upstream state indicator.\nHowever, clearing colour of the coloured indicators changes how the\nsparsity state indicator is coloured, as it currently inherits (and\nbefore the change referenced also inherited) the colour of the last\nshort state indicator before it. Reading the commit message of the\nchange that introduced the sparsity state indicator, afda36dbf3b\n(git-prompt: include sparsity state as well, 2020-06-21), it appears\nthis colouring also was unintended, so clearing the colour for said\nindicator further increases consistency.\n\nMake the colouring of these state indicators consistent by making all\ncoloured indicators clear their own colour. Make colouring of $c\ndependent on it not being empty, as it is no longer being used to colour\nthe branch name. Change $w to follow the same behaviour so changes to\nits content don't change how it is coloured. Move clearing of $b's\nprefix to before colouring so it gets cleared properly when colour codes\nare inserted into it. These changes make changing the layout of the\nprompt less prone to unintended colour changes in the future.\n\nChange coloured Bash prompt tests to reflect the colourization changes:\n * Move the colour codes to wrap the expected content of the expanded\n   $__git_ps1_branch_name in all tests.\n * Insert a clear-colour code after the symbol for the first indicator\n   in \"prompt - bash color pc mode - dirty status indicator - dirty\n   index and worktree\", to reflect that all indicators should clear\n   their own colour.\n\nHaving each indicator clear its own colour lessens the cost of\nrefactoring the prompt layout, as the outcome of colouring becomes\nindependent on the position of indicators in the final prompt.\n\nSigned-off-by: Joakim Petersen <joak-pet@online.no>\n---\nChanges since v7:\n * Fixed branch name ($b) not being coloured, but rather having its\n   colour codes printed as text.\n * Added mention of the change to the check for whether to colour $w.\n * Replaced use of \"colourize\" and derivatives in the message with\n   \"colour\".\n\nRange-diff against v7:\n1:  50765eeb95 ! 1:  1082f46b4c git-prompt: make colourization consistent\n    @@ contrib/completion/git-prompt.sh: __git_ps1_colorize_gitstring ()\n      \n      # Helper function to read the first line of a file into a variable.\n     @@ contrib/completion/git-prompt.sh: __git_ps1 ()\n    - \t\tfi\n      \tfi\n      \n    -+\tb=${b##refs/heads/}\n      \tlocal z=\"${GIT_PS1_STATESEPARATOR-\" \"}\"\n    ++\tb=${b##refs/heads/}\n    ++\tif [ $pcmode = yes ] && [ $ps1_expanded = yes ]; then\n    ++\t\t__git_ps1_branch_name=$b\n    ++\t\tb=\"\\${__git_ps1_branch_name}\"\n    ++\tfi\n    ++\n      \n      \t# NO color option unless in PROMPT_COMMAND mode or it's Zsh\n    + \tif [ -n \"${GIT_PS1_SHOWCOLORHINTS-}\" ]; then\n     @@ contrib/completion/git-prompt.sh: __git_ps1 ()\n      \t\tfi\n      \tfi\n      \n     -\tb=${b##refs/heads/}\n    - \tif [ $pcmode = yes ] && [ $ps1_expanded = yes ]; then\n    - \t\t__git_ps1_branch_name=$b\n    - \t\tb=\"\\${__git_ps1_branch_name}\"\n    +-\tif [ $pcmode = yes ] && [ $ps1_expanded = yes ]; then\n    +-\t\t__git_ps1_branch_name=$b\n    +-\t\tb=\"\\${__git_ps1_branch_name}\"\n    +-\tfi\n    +-\n    + \tlocal f=\"$h$w$i$s$u$p\"\n    + \tlocal gitstring=\"$c$b${f:+$z$f}${sparse}$r${upstream}\"\n    + \n     \n      ## t/t9903-bash-prompt.sh ##\n     @@ t/t9903-bash-prompt.sh: test_expect_success 'prompt - pc mode' '\n\n contrib/completion/git-prompt.sh | 32 +++++++++++++++++---------------\n t/t9903-bash-prompt.sh           | 18 +++++++++---------\n 2 files changed, 26 insertions(+), 24 deletions(-)\n\ndiff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh\nindex 87b2b916c0..44bfc7972e 100644\n--- a/contrib/completion/git-prompt.sh\n+++ b/contrib/completion/git-prompt.sh\n@@ -245,7 +245,8 @@ __git_ps1_show_upstream ()\n \n # Helper function that is meant to be called from __git_ps1.  It\n # injects color codes into the appropriate gitstring variables used\n-# to build a gitstring.\n+# to build a gitstring. Colored variables are responsible for clearing\n+# their own color.\n __git_ps1_colorize_gitstring ()\n {\n \tif [[ -n ${ZSH_VERSION-} ]]; then\n@@ -271,22 +272,23 @@ __git_ps1_colorize_gitstring ()\n \telse\n \t\tbranch_color=\"$bad_color\"\n \tfi\n-\tc=\"$branch_color$c\"\n+\tif [ -n \"$c\" ]; then\n+\t\tc=\"$branch_color$c$c_clear\"\n+\tfi\n+\tb=\"$branch_color$b$c_clear\"\n \n-\tz=\"$c_clear$z\"\n-\tif [ \"$w\" = \"*\" ]; then\n-\t\tw=\"$bad_color$w\"\n+\tif [ -n \"$w\" ]; then\n+\t\tw=\"$bad_color$w$c_clear\"\n \tfi\n \tif [ -n \"$i\" ]; then\n-\t\ti=\"$ok_color$i\"\n+\t\ti=\"$ok_color$i$c_clear\"\n \tfi\n \tif [ -n \"$s\" ]; then\n-\t\ts=\"$flags_color$s\"\n+\t\ts=\"$flags_color$s$c_clear\"\n \tfi\n \tif [ -n \"$u\" ]; then\n-\t\tu=\"$bad_color$u\"\n+\t\tu=\"$bad_color$u$c_clear\"\n \tfi\n-\tr=\"$c_clear$r\"\n }\n \n # Helper function to read the first line of a file into a variable.\n@@ -555,6 +557,12 @@ __git_ps1 ()\n \tfi\n \n \tlocal z=\"${GIT_PS1_STATESEPARATOR-\" \"}\"\n+\tb=${b##refs/heads/}\n+\tif [ $pcmode = yes ] && [ $ps1_expanded = yes ]; then\n+\t\t__git_ps1_branch_name=$b\n+\t\tb=\"\\${__git_ps1_branch_name}\"\n+\tfi\n+\n \n \t# NO color option unless in PROMPT_COMMAND mode or it's Zsh\n \tif [ -n \"${GIT_PS1_SHOWCOLORHINTS-}\" ]; then\n@@ -563,12 +571,6 @@ __git_ps1 ()\n \t\tfi\n \tfi\n \n-\tb=${b##refs/heads/}\n-\tif [ $pcmode = yes ] && [ $ps1_expanded = yes ]; then\n-\t\t__git_ps1_branch_name=$b\n-\t\tb=\"\\${__git_ps1_branch_name}\"\n-\tfi\n-\n \tlocal f=\"$h$w$i$s$u$p\"\n \tlocal gitstring=\"$c$b${f:+$z$f}${sparse}$r${upstream}\"\n \ndiff --git a/t/t9903-bash-prompt.sh b/t/t9903-bash-prompt.sh\nindex bbd513bab0..abd82eec35 100755\n--- a/t/t9903-bash-prompt.sh\n+++ b/t/t9903-bash-prompt.sh\n@@ -541,7 +541,7 @@ test_expect_success 'prompt - pc mode' '\n '\n \n test_expect_success 'prompt - bash color pc mode - branch name' '\n-\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear}):AFTER\\\\nmain\" >expected &&\n+\tprintf \"BEFORE: (\\${__git_ps1_branch_name}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n \t(\n \t\tGIT_PS1_SHOWCOLORHINTS=y &&\n \t\t__git_ps1 \"BEFORE:\" \":AFTER\" >\"$actual\" &&\n@@ -551,7 +551,7 @@ test_expect_success 'prompt - bash color pc mode - branch name' '\n '\n \n test_expect_success 'prompt - bash color pc mode - detached head' '\n-\tprintf \"BEFORE: (${c_red}\\${__git_ps1_branch_name}${c_clear}):AFTER\\\\n(%s...)\" $(git log -1 --format=\"%h\" b1^) >expected &&\n+\tprintf \"BEFORE: (\\${__git_ps1_branch_name}):AFTER\\\\n${c_red}(%s...)\"${c_clear} $(git log -1 --format=\"%h\" b1^) >expected &&\n \tgit checkout b1^ &&\n \ttest_when_finished \"git checkout main\" &&\n \t(\n@@ -563,7 +563,7 @@ test_expect_success 'prompt - bash color pc mode - detached head' '\n '\n \n test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirty worktree' '\n-\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear} ${c_red}*${c_clear}):AFTER\\\\nmain\" >expected &&\n+\tprintf \"BEFORE: (\\${__git_ps1_branch_name} ${c_red}*${c_clear}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n \techo \"dirty\" >file &&\n \ttest_when_finished \"git reset --hard\" &&\n \t(\n@@ -576,7 +576,7 @@ test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirt\n '\n \n test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirty index' '\n-\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear} ${c_green}+${c_clear}):AFTER\\\\nmain\" >expected &&\n+\tprintf \"BEFORE: (\\${__git_ps1_branch_name} ${c_green}+${c_clear}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n \techo \"dirty\" >file &&\n \ttest_when_finished \"git reset --hard\" &&\n \tgit add -u &&\n@@ -590,7 +590,7 @@ test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirt\n '\n \n test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirty index and worktree' '\n-\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear} ${c_red}*${c_green}+${c_clear}):AFTER\\\\nmain\" >expected &&\n+\tprintf \"BEFORE: (\\${__git_ps1_branch_name} ${c_red}*${c_clear}${c_green}+${c_clear}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n \techo \"dirty index\" >file &&\n \ttest_when_finished \"git reset --hard\" &&\n \tgit add -u &&\n@@ -605,7 +605,7 @@ test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirt\n '\n \n test_expect_success 'prompt - bash color pc mode - dirty status indicator - before root commit' '\n-\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear} ${c_green}#${c_clear}):AFTER\\\\nmain\" >expected &&\n+\tprintf \"BEFORE: (\\${__git_ps1_branch_name} ${c_green}#${c_clear}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n \t(\n \t\tGIT_PS1_SHOWDIRTYSTATE=y &&\n \t\tGIT_PS1_SHOWCOLORHINTS=y &&\n@@ -617,7 +617,7 @@ test_expect_success 'prompt - bash color pc mode - dirty status indicator - befo\n '\n \n test_expect_success 'prompt - bash color pc mode - inside .git directory' '\n-\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear}):AFTER\\\\nGIT_DIR!\" >expected &&\n+\tprintf \"BEFORE: (\\${__git_ps1_branch_name}):AFTER\\\\n${c_green}GIT_DIR!${c_clear}\" >expected &&\n \techo \"dirty\" >file &&\n \ttest_when_finished \"git reset --hard\" &&\n \t(\n@@ -631,7 +631,7 @@ test_expect_success 'prompt - bash color pc mode - inside .git directory' '\n '\n \n test_expect_success 'prompt - bash color pc mode - stash status indicator' '\n-\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear} ${c_lblue}\\$${c_clear}):AFTER\\\\nmain\" >expected &&\n+\tprintf \"BEFORE: (\\${__git_ps1_branch_name} ${c_lblue}\\$${c_clear}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n \techo 2 >file &&\n \tgit stash &&\n \ttest_when_finished \"git stash drop\" &&\n@@ -645,7 +645,7 @@ test_expect_success 'prompt - bash color pc mode - stash status indicator' '\n '\n \n test_expect_success 'prompt - bash color pc mode - untracked files status indicator' '\n-\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear} ${c_red}%%${c_clear}):AFTER\\\\nmain\" >expected &&\n+\tprintf \"BEFORE: (\\${__git_ps1_branch_name} ${c_red}%%${c_clear}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n \t(\n \t\tGIT_PS1_SHOWUNTRACKEDFILES=y &&\n \t\tGIT_PS1_SHOWCOLORHINTS=y &&\n-- \n2.36.1\n\n"},{"id":"456958","messageId":"xmqq5yl9lmgq.fsf@gitster.g","threadId":"57941","inReplyTo":"736a5f12-2ab3-977c-8cba-45529e9ebee0@online.no","subject":"Re: [PATCH v7] git-prompt: make colourization consistent","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-06-09T18:29:25Z","receivedAt":"2022-06-09T18:29:32Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Joakim Petersen <joak-pet@online.no> writes:\n\n> On 09/06/2022 11:03, SZEDER Gábor wrote:\n>> This patch seems to break colorization when __git_ps1() is invoked\n>> from $PROMPT_COMMAND:\n>>    ~/src/git (master)$ echo $PROMPT_COMMAND\n>> __git_ps1 \"\\[\\e]0;\\w - Terminal\\a\\e[01;32m\\]\\h\\[\\e[01;34m\\] \\w\" \"\\[\\e[01;34m\\]\\$\\[\\e[00m\\] \" \" \\[\\e[01;34m\\](%s\\[\\e[01;34m\\])\"\n>>    ~/src/git (master)$ git checkout 9470605a1b\n>>    HEAD is now at 9470605a1b git-prompt: make colourization consistent\n>>    ~/src/git ((9470605a1b...))$ source contrib/completion/git-prompt.sh\n>>    ~/src/git (\\[\\e[31m\\](9470605a1b...)\\[\\e[0m\\])$ # uh-oh\n>>    ~/src/git (\\[\\e[31m\\](9470605a1b...)\\[\\e[0m\\])$ git checkout 9470605a1b^\n>>    Previous HEAD position was 9470605a1b git-prompt: make colourization consistent\n>>    HEAD is now at 2668e3608e Sixth batch\n>>    ~/src/git (\\[\\e[31m\\](2668e3608e...)\\[\\e[0m\\])$ source contrib/completion/git-prompt.sh\n>>    ~/src/git ((2668e3608e...))$ # Looks good.\n>> \n>\n> While I did test this on my own prompt for v6 (which is identical to v7\n> in terms of code) and not see any breakage, I have the same issue with\n> v7. Maybe I forgot to re-source the changed git-prompt.sh. Either way,\n> The issue stems from $b being wrapped in $__git_ps1_branch_name and then\n> back into itself after colouring. Moving this wrapping to before colour\n> is applied fixes this. I will submit a v8 shortly.\n\nAs the topic is already in 'next' (and presumably that is how SZEDER\nnoticed the breakage), please make it an incremental fix-up.\n\nThanks.\n"},{"id":"456966","messageId":"20220609204447.32841-1-joak-pet@online.no","threadId":"57941","inReplyTo":"20220607115024.64724-1-joak-pet@online.no","subject":"[PATCH] git-prompt: fix expansion of branch colour codes","fromName":"Joakim Petersen","fromEmail":"joak-pet@online.no","sentAt":"2022-06-09T20:44:47Z","receivedAt":"2022-06-09T20:44:59Z","isPatch":true,"sender":{"key":"joak-pet@online.no","avatar":"https://avatars.githubusercontent.com/u/107927072?v=4"},"body":"Because of the wrapping of the branch name variable $b, the colour codes\nin the variable don't get applied, but are instead printed directly in\nthe output. Move the wrapping of $b to before colour codes are inserted\nto correct this.\n\nSigned-off-by: Joakim Petersen <joak-pet@online.no>\n---\n contrib/completion/git-prompt.sh | 12 ++++++------\n 1 file changed, 6 insertions(+), 6 deletions(-)\n\ndiff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh\nindex cb01c2fd5d..1435548e00 100644\n--- a/contrib/completion/git-prompt.sh\n+++ b/contrib/completion/git-prompt.sh\n@@ -556,9 +556,14 @@ __git_ps1 ()\n \t\tfi\n \tfi\n \n-\tb=${b##refs/heads/}\n \tlocal z=\"${GIT_PS1_STATESEPARATOR-\" \"}\"\n \n+\tb=${b##refs/heads/}\n+\tif [ $pcmode = yes ] && [ $ps1_expanded = yes ]; then\n+\t\t__git_ps1_branch_name=$b\n+\t\tb=\"\\${__git_ps1_branch_name}\"\n+\tfi\n+\n \t# NO color option unless in PROMPT_COMMAND mode or it's Zsh\n \tif [ -n \"${GIT_PS1_SHOWCOLORHINTS-}\" ]; then\n \t\tif [ $pcmode = yes ] || [ -n \"${ZSH_VERSION-}\" ]; then\n@@ -566,11 +571,6 @@ __git_ps1 ()\n \t\tfi\n \tfi\n \n-\tif [ $pcmode = yes ] && [ $ps1_expanded = yes ]; then\n-\t\t__git_ps1_branch_name=$b\n-\t\tb=\"\\${__git_ps1_branch_name}\"\n-\tfi\n-\n \tlocal f=\"$h$w$i$s$u$p\"\n \tlocal gitstring=\"$c$b${f:+$z$f}${sparse}$r${upstream}\"\n \n\nbase-commit: 9470605a1b03dac8fc4f801132e36964b4fbb8c3\n-- \n2.36.1\n\n"},{"id":"456971","messageId":"xmqq4k0tgz6s.fsf@gitster.g","threadId":"57941","inReplyTo":"20220609204447.32841-1-joak-pet@online.no","subject":"Re: [PATCH] git-prompt: fix expansion of branch colour codes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-06-10T00:05:47Z","receivedAt":"2022-06-10T00:05:56Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Joakim Petersen <joak-pet@online.no> writes:\n\n> Because of the wrapping of the branch name variable $b, the colour codes\n> in the variable don't get applied, but are instead printed directly in\n> the output. Move the wrapping of $b to before colour codes are inserted\n> to correct this.\n>\n> Signed-off-by: Joakim Petersen <joak-pet@online.no>\n> ---\n>  contrib/completion/git-prompt.sh | 12 ++++++------\n>  1 file changed, 6 insertions(+), 6 deletions(-)\n\nt9903 seems to fail with this, though...?\n\n> diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh\n> index cb01c2fd5d..1435548e00 100644\n> --- a/contrib/completion/git-prompt.sh\n> +++ b/contrib/completion/git-prompt.sh\n> @@ -556,9 +556,14 @@ __git_ps1 ()\n>  \t\tfi\n>  \tfi\n>  \n> -\tb=${b##refs/heads/}\n>  \tlocal z=\"${GIT_PS1_STATESEPARATOR-\" \"}\"\n>  \n> +\tb=${b##refs/heads/}\n> +\tif [ $pcmode = yes ] && [ $ps1_expanded = yes ]; then\n> +\t\t__git_ps1_branch_name=$b\n> +\t\tb=\"\\${__git_ps1_branch_name}\"\n> +\tfi\n> +\n>  \t# NO color option unless in PROMPT_COMMAND mode or it's Zsh\n>  \tif [ -n \"${GIT_PS1_SHOWCOLORHINTS-}\" ]; then\n>  \t\tif [ $pcmode = yes ] || [ -n \"${ZSH_VERSION-}\" ]; then\n> @@ -566,11 +571,6 @@ __git_ps1 ()\n>  \t\tfi\n>  \tfi\n>  \n> -\tif [ $pcmode = yes ] && [ $ps1_expanded = yes ]; then\n> -\t\t__git_ps1_branch_name=$b\n> -\t\tb=\"\\${__git_ps1_branch_name}\"\n> -\tfi\n> -\n>  \tlocal f=\"$h$w$i$s$u$p\"\n>  \tlocal gitstring=\"$c$b${f:+$z$f}${sparse}$r${upstream}\"\n>  \n>\n> base-commit: 9470605a1b03dac8fc4f801132e36964b4fbb8c3\n"},{"id":"456981","messageId":"8bfdf2eb-70f8-ad28-5dac-5ee598cd487a@online.no","threadId":"57941","inReplyTo":"xmqq4k0tgz6s.fsf@gitster.g","subject":"Re: [PATCH] git-prompt: fix expansion of branch colour codes","fromName":"Joakim Petersen","fromEmail":"joak-pet@online.no","sentAt":"2022-06-10T00:33:53Z","receivedAt":"2022-06-10T00:34:06Z","isPatch":true,"sender":{"key":"joak-pet@online.no","avatar":"https://avatars.githubusercontent.com/u/107927072?v=4"},"body":"On 10/06/2022 02:05, Junio C Hamano wrote:\n> t9903 seems to fail with this, though...?\n> \n\nAh yes, sorry about that, I seem to have gotten a bit ahead of myself.\nSince the wrapping of $b was entirely moved to before colouring happens,\nthe tests need to be reverted back to their state from before the\nprevious commit, with the exception of the extra $c_clear in the test\nwith two active indicators. I'll submit a v2 with this change shortly.\n"},{"id":"456982","messageId":"20220610004737.17683-1-joak-pet@online.no","threadId":"57941","inReplyTo":"20220609204447.32841-1-joak-pet@online.no","subject":"[PATCH v2] git-prompt: fix expansion of branch colour codes","fromName":"Joakim Petersen","fromEmail":"joak-pet@online.no","sentAt":"2022-06-10T00:47:37Z","receivedAt":"2022-06-10T00:47:49Z","isPatch":true,"sender":{"key":"joak-pet@online.no","avatar":"https://avatars.githubusercontent.com/u/107927072?v=4"},"body":"Because of the wrapping of the branch name variable $b, the colour codes\nin the variable don't get applied, but are instead printed directly in\nthe output. Move the wrapping of $b to before colour codes are inserted\nto correct this. Revert move of branch name colour codes in tests, as\nthe branch name is now coloured after the wrapping instead of before.\n\nSigned-off-by: Joakim Petersen <joak-pet@online.no>\n---\nChanges since v1:\n * Tests have been reverted to how they were before the initial\n   colouring change in 9470605a1b0 (git-prompt: make colourization\n   consistent, 2022-06-07), with the exception of the added $c_clear for\n   the test with two active indicators.\n\nRange-diff against v1:\n1:  f4e46d37a5 < -:  ---------- git-prompt: fix expansion of branch colour codes\n-:  ---------- > 1:  2520d60f0f git-prompt: fix expansion of branch colour codes\n\n contrib/completion/git-prompt.sh | 12 ++++++------\n t/t9903-bash-prompt.sh           | 18 +++++++++---------\n 2 files changed, 15 insertions(+), 15 deletions(-)\n\ndiff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh\nindex cb01c2fd5d..1435548e00 100644\n--- a/contrib/completion/git-prompt.sh\n+++ b/contrib/completion/git-prompt.sh\n@@ -556,9 +556,14 @@ __git_ps1 ()\n \t\tfi\n \tfi\n \n-\tb=${b##refs/heads/}\n \tlocal z=\"${GIT_PS1_STATESEPARATOR-\" \"}\"\n \n+\tb=${b##refs/heads/}\n+\tif [ $pcmode = yes ] && [ $ps1_expanded = yes ]; then\n+\t\t__git_ps1_branch_name=$b\n+\t\tb=\"\\${__git_ps1_branch_name}\"\n+\tfi\n+\n \t# NO color option unless in PROMPT_COMMAND mode or it's Zsh\n \tif [ -n \"${GIT_PS1_SHOWCOLORHINTS-}\" ]; then\n \t\tif [ $pcmode = yes ] || [ -n \"${ZSH_VERSION-}\" ]; then\n@@ -566,11 +571,6 @@ __git_ps1 ()\n \t\tfi\n \tfi\n \n-\tif [ $pcmode = yes ] && [ $ps1_expanded = yes ]; then\n-\t\t__git_ps1_branch_name=$b\n-\t\tb=\"\\${__git_ps1_branch_name}\"\n-\tfi\n-\n \tlocal f=\"$h$w$i$s$u$p\"\n \tlocal gitstring=\"$c$b${f:+$z$f}${sparse}$r${upstream}\"\n \ndiff --git a/t/t9903-bash-prompt.sh b/t/t9903-bash-prompt.sh\nindex abd82eec35..6a30f5719c 100755\n--- a/t/t9903-bash-prompt.sh\n+++ b/t/t9903-bash-prompt.sh\n@@ -541,7 +541,7 @@ test_expect_success 'prompt - pc mode' '\n '\n \n test_expect_success 'prompt - bash color pc mode - branch name' '\n-\tprintf \"BEFORE: (\\${__git_ps1_branch_name}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n+\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear}):AFTER\\\\nmain\" >expected &&\n \t(\n \t\tGIT_PS1_SHOWCOLORHINTS=y &&\n \t\t__git_ps1 \"BEFORE:\" \":AFTER\" >\"$actual\" &&\n@@ -551,7 +551,7 @@ test_expect_success 'prompt - bash color pc mode - branch name' '\n '\n \n test_expect_success 'prompt - bash color pc mode - detached head' '\n-\tprintf \"BEFORE: (\\${__git_ps1_branch_name}):AFTER\\\\n${c_red}(%s...)\"${c_clear} $(git log -1 --format=\"%h\" b1^) >expected &&\n+\tprintf \"BEFORE: (${c_red}\\${__git_ps1_branch_name}${c_clear}):AFTER\\\\n(%s...)\" $(git log -1 --format=\"%h\" b1^) >expected &&\n \tgit checkout b1^ &&\n \ttest_when_finished \"git checkout main\" &&\n \t(\n@@ -563,7 +563,7 @@ test_expect_success 'prompt - bash color pc mode - detached head' '\n '\n \n test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirty worktree' '\n-\tprintf \"BEFORE: (\\${__git_ps1_branch_name} ${c_red}*${c_clear}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n+\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear} ${c_red}*${c_clear}):AFTER\\\\nmain\" >expected &&\n \techo \"dirty\" >file &&\n \ttest_when_finished \"git reset --hard\" &&\n \t(\n@@ -576,7 +576,7 @@ test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirt\n '\n \n test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirty index' '\n-\tprintf \"BEFORE: (\\${__git_ps1_branch_name} ${c_green}+${c_clear}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n+\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear} ${c_green}+${c_clear}):AFTER\\\\nmain\" >expected &&\n \techo \"dirty\" >file &&\n \ttest_when_finished \"git reset --hard\" &&\n \tgit add -u &&\n@@ -590,7 +590,7 @@ test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirt\n '\n \n test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirty index and worktree' '\n-\tprintf \"BEFORE: (\\${__git_ps1_branch_name} ${c_red}*${c_clear}${c_green}+${c_clear}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n+\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear} ${c_red}*${c_clear}${c_green}+${c_clear}):AFTER\\\\nmain\" >expected &&\n \techo \"dirty index\" >file &&\n \ttest_when_finished \"git reset --hard\" &&\n \tgit add -u &&\n@@ -605,7 +605,7 @@ test_expect_success 'prompt - bash color pc mode - dirty status indicator - dirt\n '\n \n test_expect_success 'prompt - bash color pc mode - dirty status indicator - before root commit' '\n-\tprintf \"BEFORE: (\\${__git_ps1_branch_name} ${c_green}#${c_clear}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n+\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear} ${c_green}#${c_clear}):AFTER\\\\nmain\" >expected &&\n \t(\n \t\tGIT_PS1_SHOWDIRTYSTATE=y &&\n \t\tGIT_PS1_SHOWCOLORHINTS=y &&\n@@ -617,7 +617,7 @@ test_expect_success 'prompt - bash color pc mode - dirty status indicator - befo\n '\n \n test_expect_success 'prompt - bash color pc mode - inside .git directory' '\n-\tprintf \"BEFORE: (\\${__git_ps1_branch_name}):AFTER\\\\n${c_green}GIT_DIR!${c_clear}\" >expected &&\n+\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear}):AFTER\\\\nGIT_DIR!\" >expected &&\n \techo \"dirty\" >file &&\n \ttest_when_finished \"git reset --hard\" &&\n \t(\n@@ -631,7 +631,7 @@ test_expect_success 'prompt - bash color pc mode - inside .git directory' '\n '\n \n test_expect_success 'prompt - bash color pc mode - stash status indicator' '\n-\tprintf \"BEFORE: (\\${__git_ps1_branch_name} ${c_lblue}\\$${c_clear}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n+\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear} ${c_lblue}\\$${c_clear}):AFTER\\\\nmain\" >expected &&\n \techo 2 >file &&\n \tgit stash &&\n \ttest_when_finished \"git stash drop\" &&\n@@ -645,7 +645,7 @@ test_expect_success 'prompt - bash color pc mode - stash status indicator' '\n '\n \n test_expect_success 'prompt - bash color pc mode - untracked files status indicator' '\n-\tprintf \"BEFORE: (\\${__git_ps1_branch_name} ${c_red}%%${c_clear}):AFTER\\\\n${c_green}main${c_clear}\" >expected &&\n+\tprintf \"BEFORE: (${c_green}\\${__git_ps1_branch_name}${c_clear} ${c_red}%%${c_clear}):AFTER\\\\nmain\" >expected &&\n \t(\n \t\tGIT_PS1_SHOWUNTRACKEDFILES=y &&\n \t\tGIT_PS1_SHOWCOLORHINTS=y &&\n-- \n2.36.1\n\n"},{"id":"457062","messageId":"20220611090131.GB1785@szeder.dev","threadId":"57941","inReplyTo":"xmqq5yl9lmgq.fsf@gitster.g","subject":"Re: [PATCH v7] git-prompt: make colourization consistent","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2022-06-11T09:01:31Z","receivedAt":"2022-06-11T09:01:44Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Thu, Jun 09, 2022 at 11:29:25AM -0700, Junio C Hamano wrote:\n> Joakim Petersen <joak-pet@online.no> writes:\n> \n> > On 09/06/2022 11:03, SZEDER Gábor wrote:\n> >> This patch seems to break colorization when __git_ps1() is invoked\n> >> from $PROMPT_COMMAND:\n> >>    ~/src/git (master)$ echo $PROMPT_COMMAND\n> >> __git_ps1 \"\\[\\e]0;\\w - Terminal\\a\\e[01;32m\\]\\h\\[\\e[01;34m\\] \\w\" \"\\[\\e[01;34m\\]\\$\\[\\e[00m\\] \" \" \\[\\e[01;34m\\](%s\\[\\e[01;34m\\])\"\n> >>    ~/src/git (master)$ git checkout 9470605a1b\n> >>    HEAD is now at 9470605a1b git-prompt: make colourization consistent\n> >>    ~/src/git ((9470605a1b...))$ source contrib/completion/git-prompt.sh\n> >>    ~/src/git (\\[\\e[31m\\](9470605a1b...)\\[\\e[0m\\])$ # uh-oh\n> >>    ~/src/git (\\[\\e[31m\\](9470605a1b...)\\[\\e[0m\\])$ git checkout 9470605a1b^\n> >>    Previous HEAD position was 9470605a1b git-prompt: make colourization consistent\n> >>    HEAD is now at 2668e3608e Sixth batch\n> >>    ~/src/git (\\[\\e[31m\\](2668e3608e...)\\[\\e[0m\\])$ source contrib/completion/git-prompt.sh\n> >>    ~/src/git ((2668e3608e...))$ # Looks good.\n> >> \n> >\n> > While I did test this on my own prompt for v6 (which is identical to v7\n> > in terms of code) and not see any breakage, I have the same issue with\n> > v7. Maybe I forgot to re-source the changed git-prompt.sh. Either way,\n> > The issue stems from $b being wrapped in $__git_ps1_branch_name and then\n> > back into itself after colouring. Moving this wrapping to before colour\n> > is applied fixes this. I will submit a v8 shortly.\n> \n> As the topic is already in 'next' (and presumably that is how SZEDER\n> noticed the breakage),\n\nIndeed.  I usually use a custom git built from 'next' with a couple of\nmy forever-WIP topics merged on top, and I just happened to build and\ndeploy a version with this patch already merged the other day, with\nthe additional stroke of luck that I opened a new terminal window\n(what I normally rarely do) whose shell sourced the buggy prompt\nscript.\n\nI did notice this patch being discussed on the ML, and found the\namount of changes to the expected output in the tests somewhat\nsuspicious, but, alas, haven't managed to take a closer look before\nthe patch went into 'next'.  Still hasn't, actually, but FWIW Joakim's\nfix (as 0e5d9ef395 in 'seen') does work for me.\n\n\nThanks,\nGábor\n\n"}]}