{"thread":{"id":"31656","subject":"bash completion with colour hints","startedAt":"2012-09-26T15:00:21Z","lastAt":"2012-10-17T07:17:44Z","messageCount":49,"participants":["Simon Oosthoek","Ramkumar Ramachandra","Junio C Hamano","Michael J Gruber","Andreas Schwab"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"199950","messageId":"50631885.8090604@nieuwland.nl","threadId":"31656","inReplyTo":null,"subject":"bash completion with colour hints","fromName":"Simon Oosthoek","fromEmail":"soosthoek@nieuwland.nl","sentAt":"2012-09-26T15:00:21Z","receivedAt":"2012-09-26T15:00:21Z","isPatch":false,"sender":{"key":"soosthoek@nieuwland.nl","avatar":null},"body":"Hi Shawn\n\nI only recently found the __git_ps1 function, but it wasn't directly \nable to replace my own contraption. I've modified the version I found \nafter installing bash-completion in debian 6.\n\nThe patch is attached, it contains an escape character, so it is hard to \ninclude in plain text. I've gzipped it for convenience...\n\nThis is only a first step, I had a hard time figuring out what exactly \nthe one-letter variables were doing (and still a bit unclear), so I'm \nsure this can be improved!\n\nAnyway, the functionality of this patch is to show the output in green \nif the repo is up to date and red or other colours if it isn't.\n\nCheers\n\nSimon\n"},{"id":"199951","messageId":"CALkWK0=9KKZvvNFoLUNRKWkfrqR7+RByYaWP9XXg7Pd3ym7CUQ@mail.gmail.com","threadId":"31656","inReplyTo":"50631885.8090604@nieuwland.nl","subject":"Re: bash completion with colour hints","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2012-09-26T15:24:25Z","receivedAt":"2012-09-26T15:24:25Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi Simon,\n\nCould you follow the guidelines in Documentation/SubmittingPatches, so\nthat the patch can be considered for inclusion?\n\n> --- git-orig-bak\t2012-09-26 16:39:47.000000000 +0200\n> +++ git-bashcompletion\t2012-09-26 16:50:57.000000000 +0200\n> @@ -59,6 +59,9 @@\n> # per-repository basis by setting the bash.showUpstream config\n> # variable.\n> #\n> +# If you would like an additional hint in colour in your prompt\n> +# set GIT_PS1_SHOWCOLORHINT to a nonempty value. Currently\n> +# the colours are hardcoded in the function...\n\nNit: I think it's spelt \"color\" everywhere else in git.\n\n> #\n> # To submit patches:\n> #\n> @@ -302,9 +305,35 @@\n> \t\t\t\t__git_ps1_show_upstream\n> \t\t\tfi\n> \t\tfi\n> -\n> +\t\n\nWhitespace damage.\n\n> +\t\tlocal c_red=' [31m'\n> +\t\tlocal c_yellow=' [33m'\n> +\t\tlocal c_lblue=' [1,34m'\n> +\t\tlocal c_green=' [32m'\n> +\t\tlocal c_purple=' [35m'\n> +\t\tlocal c_cyan=' [36m'\n> +\t\tlocal c_clear=' [0m'\n> +\t\tlocal printf_format=\"${1:- (%s)}\"\n> +\n> +\t\tif [ -n \"${GIT_PS1_SHOWCOLORHINT-}\" ]; then\n> +\t\t\tif [ \"$w\" != \"*\" ]; then\n> +\t\t\t\tprintf_format=\"$c_green$printf_format$c_clear\"\n> +\t\t\telse\n> +\t\t\t\tprintf_format=\"$c_red$printf_format$c_clear\"\n> +\t\t\tfi\n> +\t\t\tif [ -n \"$i\" ]; then\n> +\t\t\t\ti=\"$c_yellow$i$c_clear\"\n> +\t\t\tfi\n> +\t\t\tif [ -n \"$s\" ]; then\n> +\t\t\t\ts=\"$c_lblue$i$c_clear\"\n> +\t\t\tfi\n> +\t\t\tif [ -n \"$u\" ]; then\n> +\t\t\t\tu=\"$c_purple$i$c_clear\"\n> +\t\t\tfi\n> +\t\tfi\n> +\t\t\t\n> \t\tlocal f=\"$w$i$s$u\"\n> -\t\tprintf \"${1:- (%s)}\" \"$c${b##refs/heads/}${f:+ $f}$r$p\"\n> +\t\techo $(printf \"$printf_format\" \"$c${b##refs/heads/}${f:+ $f}$r$p\")\n> \tfi\n> }\n\nLooks okay from a glance.\n\nRam\n"},{"id":"199961","messageId":"506356AA.3050005@nieuwland.nl","threadId":"31656","inReplyTo":"CALkWK0=9KKZvvNFoLUNRKWkfrqR7+RByYaWP9XXg7Pd3ym7CUQ@mail.gmail.com","subject":"Re: bash completion with colour hints","fromName":"Simon Oosthoek","fromEmail":"soosthoek@nieuwland.nl","sentAt":"2012-09-26T19:25:30Z","receivedAt":"2012-09-26T19:25:30Z","isPatch":false,"sender":{"key":"soosthoek@nieuwland.nl","avatar":null},"body":"On 26/09/12 17:24, Ramkumar Ramachandra wrote:\n> Hi Simon,\n> \n> Could you follow the guidelines in Documentation/SubmittingPatches, so\n> that the patch can be considered for inclusion?\n\nHi Ram, thanks for your feedback.\n\nI gather now that this file is part of the entire git tree ;-)\n\nthis is my first time to submit a patch to git and frankly I coded this\nup very quickly and did only a small test.\n\nI read the guide and now I have some questions:\n\n- It suggests to use the oldest commit that contains the \"bug\" and can\nsupport the fix. This would be the very first mention of __git_ps1\nfunction I think commit d3d717a4ad0c8d7329e79f7d0313baec57c6b585\nHowever, I guess that although I have been using something similar since\nabout 2009, I should at least base it on the relatively new\ngit-prompt.sh file, is this a correct interpretation of the guide?\n(BTW, I wonder how this will affect ultimately the current master?)\n\n- I read that git-prompt.sh is meant to support bash and zsh, I have\nonly tested it on bash. Should I attempt to test it on zsh or is there a\nkind person with zsh as his/her shell to test it for me?\n\nMy instinct is to just apply my patch to the current master, but I'm\nopen to starting from a different base, but I'm too new to the tree to\nknow which one, any suggestions?\n\n\n\n> \n>> --- git-orig-bak\t2012-09-26 16:39:47.000000000 +0200\n>> +++ git-bashcompletion\t2012-09-26 16:50:57.000000000 +0200\n>> @@ -59,6 +59,9 @@\n>> # per-repository basis by setting the bash.showUpstream config\n>> # variable.\n>> #\n>> +# If you would like an additional hint in colour in your prompt\n>> +# set GIT_PS1_SHOWCOLORHINT to a nonempty value. Currently\n>> +# the colours are hardcoded in the function...\n> \n> Nit: I think it's spelt \"color\" everywhere else in git.\n> \n\nI can adapt ;-)\n\n>> +\t\tlocal c_red=' [31m'\n>> +\t\tlocal c_yellow=' [33m'\n>> +\t\tlocal c_lblue=' [1,34m'\n>> +\t\tlocal c_green=' [32m'\n>> +\t\tlocal c_purple=' [35m'\n>> +\t\tlocal c_cyan=' [36m'\n>> +\t\tlocal c_clear=' [0m'\n>> +\t\tlocal printf_format=\"${1:- (%s)}\"\n>> +\n>> +\t\tif [ -n \"${GIT_PS1_SHOWCOLORHINT-}\" ]; then\n>> +\t\t\tif [ \"$w\" != \"*\" ]; then\n>> +\t\t\t\tprintf_format=\"$c_green$printf_format$c_clear\"\n>> +\t\t\telse\n>> +\t\t\t\tprintf_format=\"$c_red$printf_format$c_clear\"\n>> +\t\t\tfi\n>> +\t\t\tif [ -n \"$i\" ]; then\n>> +\t\t\t\ti=\"$c_yellow$i$c_clear\"\n>> +\t\t\tfi\n>> +\t\t\tif [ -n \"$s\" ]; then\n>> +\t\t\t\ts=\"$c_lblue$i$c_clear\"\n>> +\t\t\tfi\n>> +\t\t\tif [ -n \"$u\" ]; then\n>> +\t\t\t\tu=\"$c_purple$i$c_clear\"\n>> +\t\t\tfi\n>> +\t\tfi\n>> +\t\t\t\n>> \t\tlocal f=\"$w$i$s$u\"\n>> -\t\tprintf \"${1:- (%s)}\" \"$c${b##refs/heads/}${f:+ $f}$r$p\"\n>> +\t\techo $(printf \"$printf_format\" \"$c${b##refs/heads/}${f:+ $f}$r$p\")\n\nI'm still in some doubt over this last line, including the color codes\nis confusing me...\n\nI'll go ahead and try some more polishing and whatever more comes as\nsuggestions. Is it ok to bother the list with intermediate stuff in this\nthread?\n\nCheers\n\nSimon\n"},{"id":"199999","messageId":"7vfw64rm6s.fsf@alter.siamese.dyndns.org","threadId":"31656","inReplyTo":"506356AA.3050005@nieuwland.nl","subject":"Re: bash completion with colour hints","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-09-27T06:53:31Z","receivedAt":"2012-09-27T06:53:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Simon Oosthoek writes:\n\n> I read the guide and now I have some questions:\n>\n> - It suggests to use the oldest commit that contains the \"bug\" and can\n> support the fix. This would be the very first mention of __git_ps1\n> function I think commit d3d717a4ad0c8d7329e79f7d0313baec57c6b585\n\nYou could claim that the lack of coloring is a bug, but nobody\ncomplained about it so far (and I personally hate coloring in\nprompts as they are distracting noise, and would reject a patch if\nit weren't made conditional), so I would think this is more about\n\"adding a feature the users can choose to use but they do not have\nto\".\n\nWe do not usually add new features to maintenance tracks, so the\nresult of applying the patch does not have to be merge-able to maint\nor amything older. I would base the patch on v1.7.12 (the latest\nstable release) if I were you.\n\n> - I read that git-prompt.sh is meant to support bash and zsh, I have\n> only tested it on bash. Should I attempt to test it on zsh or is there a\n> kind person with zsh as his/her shell to test it for me?\n\nThat is something you should ask on list, like you did here, but the\nmost effective way to do so is do so when you send a patch you\nworked on and tested with bash. Say \"I've tested it only with bash;\ncan you please take a look?\" and Cc the folks you find in the output\nof \"git log contrib/completion/\" who worked on making it workable\nwith zsh.\n"},{"id":"200000","messageId":"5064140E.50007@drmicha.warpmail.net","threadId":"31656","inReplyTo":"7vfw64rm6s.fsf@alter.siamese.dyndns.org","subject":"Re: bash completion with colour hints","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2012-09-27T08:53:34Z","receivedAt":"2012-09-27T08:53:34Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 27.09.2012 08:53:\n> Simon Oosthoek writes:\n> \n>> I read the guide and now I have some questions:\n>>\n>> - It suggests to use the oldest commit that contains the \"bug\" and can\n>> support the fix. This would be the very first mention of __git_ps1\n>> function I think commit d3d717a4ad0c8d7329e79f7d0313baec57c6b585\n> \n> You could claim that the lack of coloring is a bug, but nobody\n> complained about it so far (and I personally hate coloring in\n> prompts as they are distracting noise, and would reject a patch if\n> it weren't made conditional), so I would think this is more about\n> \"adding a feature the users can choose to use but they do not have\n> to\".\n> \n> We do not usually add new features to maintenance tracks, so the\n> result of applying the patch does not have to be merge-able to maint\n> or amything older. I would base the patch on v1.7.12 (the latest\n> stable release) if I were you.\n> \n>> - I read that git-prompt.sh is meant to support bash and zsh, I have\n>> only tested it on bash. Should I attempt to test it on zsh or is there a\n>> kind person with zsh as his/her shell to test it for me?\n\nActually, the instructions in the prompt script are not complete for zsh\n(you need to activate expansion in the prompt), and I think there is\nsome breakage because bash uses \"\\h\" etc. for PS1 format specifiers\nwhereas zsh uses '%h', and so the '%' in the prompt is a problem for zsh.\n\n> That is something you should ask on list, like you did here, but the\n> most effective way to do so is do so when you send a patch you\n> worked on and tested with bash. Say \"I've tested it only with bash;\n> can you please take a look?\" and Cc the folks you find in the output\n> of \"git log contrib/completion/\" who worked on making it workable\n> with zsh.\n> \n\nAdditionally, there have been several attempts already for prompt. So\nI'd suggest you check the list archives to see whether you addressed the\nissues which were raised back then. I've actually been toying with that\nmyself lately. A few hints:\n\n- You need to escape the escapes '\\[', i.e. tell the shell that color\nescapes produce zero length output, or else line wrapping is distorted.\n\n- Bash interpretes '\\' only when PS1 is assigned, not when an expansion\nin PS1 produces it.\n\n- Some don't like it colorful, so the coloring needs to depend on a\nconfig setting or env variable.\n\n- Coloring should be consistent with other coloring in Git, such as\n'status -s -b'.\n\n- Coloring provides the way to make the prompt characters analogous to\n'status -s -b' because a green 'M' is different from red 'M', and is\nmuch clearer then having to remember '+' vs. '*' (so there is a logic in\nthat).\n\n>From trying myself, I'm convinced that you need a clever combination of\nPROMPT_COMMAND and PS1 to make this work. Setting PS1 in PROMPT_COMMAND\nis probably a no-go because that makes it difficult to customize PS1. I\nhave something in the works which reproduces the current prompt but need\nto clean it up further. The actual coloring would require setting a lot\nof variables which communicate data from PROMPT_COMMAND to PS1, and I\nactually don't like that.\n\nAn alternative approach would be:\n\n- Tell users to activate git prompt by doing something like\n\nPROMPT_COMMAND='__git_prompt \"[\\u@\\h \\W (%s)]\\$ '\n\nrather than the current\n\nPS1='[\\u@\\h \\W$(__git_ps1 \" (%s)\")]\\$ '\n\n- set PS1 from __git_prompt\n\nI'm not sure about the performance implications of re-setting PS1 on\n(before) each prompt invocation, though. Would that be OK?\n\nMichael\n"},{"id":"200001","messageId":"50641492.3020204@drmicha.warpmail.net","threadId":"31656","inReplyTo":"5064140E.50007@drmicha.warpmail.net","subject":"Re: bash completion with colour hints","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2012-09-27T08:55:46Z","receivedAt":"2012-09-27T08:55:46Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Michael J Gruber venit, vidit, dixit 27.09.2012 10:53:\n...and I just checked that gzipped attached patch. No, it doesn't work\nthat way at all.\n\nMichael\n"},{"id":"200002","messageId":"50641989.6060001@nieuwland.nl","threadId":"31656","inReplyTo":"5064140E.50007@drmicha.warpmail.net","subject":"Re: bash completion with colour hints","fromName":"Simon Oosthoek","fromEmail":"soosthoek@nieuwland.nl","sentAt":"2012-09-27T09:16:57Z","receivedAt":"2012-09-27T09:16:57Z","isPatch":false,"sender":{"key":"soosthoek@nieuwland.nl","avatar":null},"body":"On 09/27/2012 10:53 AM, Michael J Gruber wrote:\n>> We do not usually add new features to maintenance tracks, so the\n>> result of applying the patch does not have to be merge-able to maint\n>> or amything older. I would base the patch on v1.7.12 (the latest\n>> stable release) if I were you.\n>>\n\nI now have a patch based on 1.7.12\n\n>>> - I read that git-prompt.sh is meant to support bash and zsh, I have\n>>> only tested it on bash. Should I attempt to test it on zsh or is there a\n>>> kind person with zsh as his/her shell to test it for me?\n>\n> Actually, the instructions in the prompt script are not complete for zsh\n> (you need to activate expansion in the prompt), and I think there is\n> some breakage because bash uses \"\\h\" etc. for PS1 format specifiers\n> whereas zsh uses '%h', and so the '%' in the prompt is a problem for zsh.\n\nThe only feature using it is untracked files, so that should probably be \nchanged to work with zsh?\n\n>\n> Additionally, there have been several attempts already for prompt. So\n> I'd suggest you check the list archives to see whether you addressed the\n> issues which were raised back then. I've actually been toying with that\n> myself lately. A few hints:\n\nThis would take me too much time\n\n>\n> - You need to escape the escapes '\\[', i.e. tell the shell that color\n> escapes produce zero length output, or else line wrapping is distorted.\n\nA: this is something I've run into with my own contraption and I'm not \nsure I fixed it with my patch :-(\n\nCan you give a more complete example of how that should work?\n\n>\n> - Bash interpretes '\\' only when PS1 is assigned, not when an expansion\n> in PS1 produces it.\n\nis that true? how can \\w produce the current working dir in the prompt?\nOr do you mean it is translated to $PWD in some form internally?\n\n>\n> - Some don't like it colorful, so the coloring needs to depend on a\n> config setting or env variable.\n\nIt is.\n\n>\n> - Coloring should be consistent with other coloring in Git, such as\n> 'status -s -b'.\n\nThat would be nice, I suppose the coloring is configurable for git, so \nthe values would need to be dynamically imported from the git config. I \ndon't know how to do that.\n\n>\n> - Coloring provides the way to make the prompt characters analogous to\n> 'status -s -b' because a green 'M' is different from red 'M', and is\n> much clearer then having to remember '+' vs. '*' (so there is a logic in\n> that).\n\nAre you suggesting to use M instead of * or +? wouldn't that interfere \nwith branchnames?\n\n>\n> From trying myself, I'm convinced that you need a clever combination of\n> PROMPT_COMMAND and PS1 to make this work. Setting PS1 in PROMPT_COMMAND\n> is probably a no-go because that makes it difficult to customize PS1. I\n> have something in the works which reproduces the current prompt but need\n> to clean it up further. The actual coloring would require setting a lot\n> of variables which communicate data from PROMPT_COMMAND to PS1, and I\n> actually don't like that.\n\nI think it should be possible in PS1 only.\n\n>\n> An alternative approach would be:\n>\n> - Tell users to activate git prompt by doing something like\n>\n> PROMPT_COMMAND='__git_prompt \"[\\u@\\h \\W (%s)]\\$ '\n>\n> rather than the current\n>\n> PS1='[\\u@\\h \\W$(__git_ps1 \" (%s)\")]\\$ '\n>\n> - set PS1 from __git_prompt\n>\n> I'm not sure about the performance implications of re-setting PS1 on\n> (before) each prompt invocation, though. Would that be OK?\n\nI doubt you can set PS1 from a function (effectively a subshell?)\n\nThanks for your comments\n\nI will send an updated patch later....\n\n/Simon\n"},{"id":"200003","messageId":"m2fw63g4qo.fsf@igel.home","threadId":"31656","inReplyTo":"5064140E.50007@drmicha.warpmail.net","subject":"Re: bash completion with colour hints","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2012-09-27T10:05:51Z","receivedAt":"2012-09-27T10:05:51Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Michael J Gruber writes:\n\n> - Bash interpretes '\\' only when PS1 is assigned, not when an expansion\n> in PS1 produces it.\n\nWhat you probably mean is that bash does not rescan expansions for\nbackslash escapes, thus only literal occurences in PS1 are processed\n(which is consistent with ordinary expansion).\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"200005","messageId":"50643F41.8090301@nieuwland.nl","threadId":"31656","inReplyTo":"5064140E.50007@drmicha.warpmail.net","subject":"Re: bash completion with colour hints","fromName":"Simon Oosthoek","fromEmail":"soosthoek@nieuwland.nl","sentAt":"2012-09-27T11:57:53Z","receivedAt":"2012-09-27T11:57:53Z","isPatch":false,"sender":{"key":"soosthoek@nieuwland.nl","avatar":null},"body":"On 09/27/2012 10:53 AM, Michael J Gruber wrote:\n\n>\n> From trying myself, I'm convinced that you need a clever combination of\n> PROMPT_COMMAND and PS1 to make this work. Setting PS1 in PROMPT_COMMAND\n> is probably a no-go because that makes it difficult to customize PS1. I\n> have something in the works which reproduces the current prompt but need\n> to clean it up further. The actual coloring would require setting a lot\n> of variables which communicate data from PROMPT_COMMAND to PS1, and I\n> actually don't like that.\n>\n> An alternative approach would be:\n>\n> - Tell users to activate git prompt by doing something like\n>\n> PROMPT_COMMAND='__git_prompt \"[\\u@\\h \\W (%s)]\\$ '\n>\n> rather than the current\n>\n> PS1='[\\u@\\h \\W$(__git_ps1 \" (%s)\")]\\$ '\n>\n> - set PS1 from __git_prompt\n>\n> I'm not sure about the performance implications of re-setting PS1 on\n> (before) each prompt invocation, though. Would that be OK?\n\nAfter some research, I completely agree with your assessment!\n\nI don't think the performance issue is that big and it's the only way to \nget the colors in there without messing up word wrapping.\n\nI'm afraid that either this will need a new function just to get the \ncoloring hints or that it will break the usage of __git_ps1 entirely (if \nyou'd require the user to use it as PROMPT_COMMAND instead of via PS1)\n\nAnd I suppose this will not be compatible with zsh?\n\n/Simon\n\nPS, I'd rather have colours with wrapping issues, than no colour hints. \nBut I realise this has to be fixed before inclusion into the main tree.\n"},{"id":"200084","messageId":"50658C9B.6030809@nieuwland.nl","threadId":"31656","inReplyTo":"5064140E.50007@drmicha.warpmail.net","subject":"[PATCH] Add __git_ps1_pc to use as PROMPT_COMMAND","fromName":"Simon Oosthoek","fromEmail":"soosthoek@nieuwland.nl","sentAt":"2012-09-28T11:40:11Z","receivedAt":"2012-09-28T11:40:11Z","isPatch":true,"sender":{"key":"soosthoek@nieuwland.nl","avatar":null},"body":"Hi again\n\nAfter the previous comments, I decided to attempt it using \nPROMPT_COMMAND rather than calling a function from command substitution \nin PS1. This new code works and doesn't have the wrapping issue anymore.\nI've simplified some of the coloring stuff and for now there's no \nparameters to customize the PS1. Users will have to customize the \nfunction itself for now...\nAs a small observation, I think it's more logical to use PROMPT_COMMAND, \nsince that explicitly uses a function, rather than using command \nsubstitution when setting PS1.\nObviously, as I didn't remove __git_ps1, the older use is unchanged, but \nnow there is about 80% duplication of code between __git_ps1 and \n__git-ps1_pc\nAnd AFAICT zsh is not supported here due to different escape characters \n(\\ in bash, % in zsh)\nPlease let me know if and how this can/should be integrated!\n\nCheers\n\nSimon\n\n\n\n\nThe function can set the PS1 varible optionally with\nColored hints about the state of the tree when\nGIT_PS1_SHOWCOLORHINTS is set to a nonempty value.\nThis version doesn't accept arguments to customize the\nprompt. And it has not been tested with zsh.\n\nSigned-off-by: Simon Oosthoek \n---\n contrib/completion/git-prompt.sh | 135 \n++++++++++++++++++++++++++++++++++++++\n 1 file changed, 135 insertions(+)\n\ndiff --git a/contrib/completion/git-prompt.sh \nb/contrib/completion/git-prompt.sh\nindex 29b1ec9..8ed6b84 100644\n--- a/contrib/completion/git-prompt.sh\n+++ b/contrib/completion/git-prompt.sh\n@@ -48,6 +48,16 @@\n # find one, or @{upstream} otherwise. Once you have set\n # GIT_PS1_SHOWUPSTREAM, you can override it on a per-repository basis by\n # setting the bash.showUpstream config variable.\n+#\n+# If you would like colored hints in the branchname shown in the prompt\n+# you can set PROMPT_COMMAND (bash) to __git_ps1_pc and export the +# \nvariables GIT_PS1_SHOWDIRTYSTATE and GIT_PS1_SHOWCOLORHINT:\n+# example:\n+# export GIT_PS1_SHOWDIRTYSTATE=true\n+# export GIT_PS1_SHOWCOLORHINT=true\n+# export PROMPT_COMMAND=__git_ps1_pc\n+# The prompt command function will directly set PS1, in order to +# \ninsert color commands in a way that doesn't mess up wrapping.\n # __gitdir accepts 0 or 1 arguments (i.e., location)\n # returns location of .git repo\n@@ -287,3 +297,128 @@ __git_ps1 ()\n \t\tprintf -- \"${1:- (%s)}\" \"$c${b##refs/heads/}${f:+ $f}$r$p\"\n \tfi\n }\n+\n+\n+# __git_ps1_pc accepts 0 arguments (for now)\n+# It is meant to be used as PROMPT_COMMAND, it sets PS1\n+__git_ps1_pc ()\n+{\n+\tlocal g=\"$(__gitdir)\"\n+\tif [ -n \"$g\" ]; then\n+\t\tlocal r=\"\"\n+\t\tlocal b=\"\"\n+\t\tif [ -f \"$g/rebase-merge/interactive\" ]; then\n+\t\t\tr=\"|REBASE-i\"\n+\t\t\tb=\"$(cat \"$g/rebase-merge/head-name\")\"\n+\t\telif [ -d \"$g/rebase-merge\" ]; then\n+\t\t\tr=\"|REBASE-m\"\n+\t\t\tb=\"$(cat \"$g/rebase-merge/head-name\")\"\n+\t\telse\n+\t\t\tif [ -d \"$g/rebase-apply\" ]; then\n+\t\t\t\tif [ -f \"$g/rebase-apply/rebasing\" ]; then\n+\t\t\t\t\tr=\"|REBASE\"\n+\t\t\t\telif [ -f \"$g/rebase-apply/applying\" ]; then\n+\t\t\t\t\tr=\"|AM\"\n+\t\t\t\telse\n+\t\t\t\t\tr=\"|AM/REBASE\"\n+\t\t\t\tfi\n+\t\t\telif [ -f \"$g/MERGE_HEAD\" ]; then\n+\t\t\t\tr=\"|MERGING\"\n+\t\t\telif [ -f \"$g/CHERRY_PICK_HEAD\" ]; then\n+\t\t\t\tr=\"|CHERRY-PICKING\"\n+\t\t\telif [ -f \"$g/BISECT_LOG\" ]; then\n+\t\t\t\tr=\"|BISECTING\"\n+\t\t\tfi\n+\n+\t\t\tb=\"$(git symbolic-ref HEAD 2>/dev/null)\" || {\n+\n+\t\t\t\tb=\"$(\n+\t\t\t\tcase \"${GIT_PS1_DESCRIBE_STYLE-}\" in\n+\t\t\t\t(contains)\n+\t\t\t\t\tgit describe --contains HEAD ;;\n+\t\t\t\t(branch)\n+\t\t\t\t\tgit describe --contains --all HEAD ;;\n+\t\t\t\t(describe)\n+\t\t\t\t\tgit describe HEAD ;;\n+\t\t\t\t(* | default)\n+\t\t\t\t\tgit describe --tags --exact-match HEAD ;;\n+\t\t\t\tesac 2>/dev/null)\" ||\n+\n+\t\t\t\tb=\"$(cut -c1-7 \"$g/HEAD\" 2>/dev/null)...\" ||\n+\t\t\t\tb=\"unknown\"\n+\t\t\t\tb=\"($b)\"\n+\t\t\t}\n+\t\tfi\n+\n+\t\tlocal w=\"\"\n+\t\tlocal i=\"\"\n+\t\tlocal s=\"\"\n+\t\tlocal u=\"\"\n+\t\tlocal c=\"\"\n+\t\tlocal p=\"\"\n+\n+\t\tif [ \"true\" = \"$(git rev-parse --is-inside-git-dir 2>/dev/null)\" ]; then\n+\t\t\tif [ \"true\" = \"$(git rev-parse --is-bare-repository 2>/dev/null)\" ]; \nthen\n+\t\t\t\tc=\"BARE:\"\n+\t\t\telse\n+\t\t\t\tb=\"GIT_DIR!\"\n+\t\t\tfi\n+\t\telif [ \"true\" = \"$(git rev-parse --is-inside-work-tree 2>/dev/null)\" \n]; then\n+\t\t\tif [ -n \"${GIT_PS1_SHOWDIRTYSTATE-}\" ]; then\n+\t\t\t\tif [ \"$(git config --bool bash.showDirtyState)\" != \"false\" ]; then\n+\t\t\t\t\tgit diff --no-ext-diff --quiet || w=\"*\"\n+\t\t\t\t\tif git rev-parse --quiet --verify HEAD >/dev/null; then\n+\t\t\t\t\t\tgit diff-index --cached --quiet HEAD -- || i=\"+\"\n+\t\t\t\t\telse\n+\t\t\t\t\t\ti=\"#\"\n+\t\t\t\t\tfi\n+\t\t\t\tfi\n+\t\t\tfi\n+\t\t\tif [ -n \"${GIT_PS1_SHOWSTASHSTATE-}\" ]; then\n+\t\t\t\tgit rev-parse --verify refs/stash >/dev/null 2>&1 && s=\"$\"\n+\t\t\tfi\n+\n+\t\t\tif [ -n \"${GIT_PS1_SHOWUNTRACKEDFILES-}\" ]; then\n+\t\t\t\tif [ -n \"$(git ls-files --others --exclude-standard)\" ]; then\n+\t\t\t\t\tu=\"%\"\n+\t\t\t\tfi\n+\t\t\tfi\n+\n+\t\t\tif [ -n \"${GIT_PS1_SHOWUPSTREAM-}\" ]; then\n+\t\t\t\t__git_ps1_show_upstream\n+\t\t\tfi\n+\t\tfi\n+\n+\t\tPS1='\\u@\\h:\\w ('\n+\t\tif [ -n \"${GIT_PS1_SHOWCOLORHINT-}\" ]; then\n+\t\t\tlocal c_red='\\e[31m'\n+\t\t\tlocal c_green='\\e[32m'\n+\t\t\tlocal c_yellow='\\e[33m'\n+\t\t\tlocal c_lblue='\\e[1;34m'\n+\t\t\tlocal c_purple='\\e[35m'\n+\t\t\tlocal c_cyan='\\e[36m'\n+\t\t\tlocal c_clear='\\e[0m'\n+\t\t\tlocal branchstring=\"$c${b##refs/heads/}\"\n+\t\t\tlocal branch_color=\"$c_green\"\n+\t\t\tlocal flags_color=\"$c_cyan\"\n+\n+\t\t\tif [ \"$w\" = \"*\" ]; then\n+\t\t\t\tbranch_color=\"$c_red\"\n+\t\t\telif [ -n \"$i\" ]; then\n+\t\t\t\tbranch_color=\"$c_yellow\"\n+\t\t\tfi\n+\t\t\t\n+\t\t\t# Setting PS1 directly with \\[ and \\] around colors\n+\t\t\t# is necessary to prevent wrapping issues!\n+\t\t\tPS1=\"$PS1\\[$branch_color\\]$branchstring\\[$c_clear\\]\"\n+\t\t\tif [ -n \"$w$i$s$u\" ]; then\n+\t\t\t\tPS1=\"$PS1 \\[$flags_color\\]$w$i$s$u\\[$c_clear\\]\"\n+\t\t\tfi\n+\t\telse\n+\t\t\tlocal f=\"$w$i$s$u\"\n+\t\t\tPS1=\"$PS1$c${b##refs/heads/}${f:+ $f}$r$p\"\n+\t\tfi\n+\t\tPS1=\"$PS1)\\$ \"\n+\n+\tfi\n+}\n-- \n1.7.9.5\n"},{"id":"200117","messageId":"7vipaym3ks.fsf@alter.siamese.dyndns.org","threadId":"31656","inReplyTo":"50658C9B.6030809@nieuwland.nl","subject":"Re: [PATCH] Add __git_ps1_pc to use as PROMPT_COMMAND","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-09-28T17:58:59Z","receivedAt":"2012-09-28T17:58:59Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Simon Oosthoek writes:\n\n> +# __git_ps1_pc accepts 0 arguments (for now)\n> +# It is meant to be used as PROMPT_COMMAND, it sets PS1\n> +__git_ps1_pc ()\n> +{\n> +\tlocal g=\"$(__gitdir)\"\n> +\tif [ -n \"$g\" ]; then\n> +...\n> +\tfi\n> +}\n\nThis looks awfully similar to the existing code in __git_ps1\nfunction. Without refactoring to share the logic between them, it\nwon't be maintainable.\n"},{"id":"200252","messageId":"50695ECE.5010101@nieuwland.nl","threadId":"31656","inReplyTo":"7vipaym3ks.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Add __git_ps1_pc to use as PROMPT_COMMAND","fromName":"Simon Oosthoek","fromEmail":"soosthoek@nieuwland.nl","sentAt":"2012-10-01T09:13:50Z","receivedAt":"2012-10-01T09:13:50Z","isPatch":true,"sender":{"key":"soosthoek@nieuwland.nl","avatar":null},"body":"On 09/28/2012 07:58 PM, Junio C Hamano wrote:\n> Simon Oosthoek writes:\n>\n>> +# __git_ps1_pc accepts 0 arguments (for now)\n>> +# It is meant to be used as PROMPT_COMMAND, it sets PS1\n>> +__git_ps1_pc ()\n>> +{\n>> +\tlocal g=\"$(__gitdir)\"\n>> +\tif [ -n \"$g\" ]; then\n>> +...\n>> +\tfi\n>> +}\n>\n> This looks awfully similar to the existing code in __git_ps1\n> function. Without refactoring to share the logic between them, it\n> won't be maintainable.\n>\n\nI agree that it's ugly. How about the following:\n\nI modified __git_ps1 to work both in PROMPT_COMMAND mode and in that \nmode support color hints.\n\nThis way there's one function, so no overlap.\n\nShall I send patches for the two changes separately (to support \nPROMPT_COMMAND mode and another to support color hints) or in one?\n\nAnd what about zsh support? I doubt the PROMPT_COMMAND thing is \ncompatible with zsh, but the command substitution mode should probably \nwork, unless it is already broken by the use of % to indicate untracked \nfiles (when GIT_PS1_SHOWUNTRACKEDFILES is set). Unless it is tested \nfurther in zsh, I'd say it might be better not to claim zsh is supported.\n\nCheers\n\nSimon\n"},{"id":"200267","messageId":"7v626udse6.fsf@alter.siamese.dyndns.org","threadId":"31656","inReplyTo":"50695ECE.5010101@nieuwland.nl","subject":"Re: [PATCH] Add __git_ps1_pc to use as PROMPT_COMMAND","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-10-01T17:16:49Z","receivedAt":"2012-10-01T17:16:49Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Simon Oosthoek writes:\n\n> On 09/28/2012 07:58 PM, Junio C Hamano wrote:\n>> Simon Oosthoek writes:\n>>\n>>> +# __git_ps1_pc accepts 0 arguments (for now)\n>>> +# It is meant to be used as PROMPT_COMMAND, it sets PS1\n>>> +__git_ps1_pc ()\n>>> +{\n>>> +\tlocal g=\"$(__gitdir)\"\n>>> +\tif [ -n \"$g\" ]; then\n>>> +...\n>>> +\tfi\n>>> +}\n>>\n>> This looks awfully similar to the existing code in __git_ps1\n>> function. Without refactoring to share the logic between them, it\n>> won't be maintainable.\n>>\n>\n> I agree that it's ugly. How about the following:\n>\n> I modified __git_ps1 to work both in PROMPT_COMMAND mode and in that\n> mode support color hints.\n>\n> This way there's one function, so no overlap.\n\nI think the logical progression would be\n\n - there are parts of __git_ps1 you want to reuse for your\n __git_ps1_pc; separate that part out as a helper function,\n and make __git_ps1 call it, without changing what __git_ps1\n does (i.e. no colors, etc.)\n\n - add __git_ps1_pc that uses the helper function you separated\n out.\n\n - add whatever bells and whistles that are useful for users of\n either __git_ps1 or __git_ps1_pc to that helper function.\n"},{"id":"200282","messageId":"5069E41E.3040809@xs4all.nl","threadId":"31656","inReplyTo":"7v626udse6.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Add __git_ps1_pc to use as PROMPT_COMMAND","fromName":"Simon Oosthoek","fromEmail":"s.oosthoek@xs4all.nl","sentAt":"2012-10-01T18:42:38Z","receivedAt":"2012-10-01T18:42:38Z","isPatch":true,"sender":{"key":"s.oosthoek@xs4all.nl","avatar":"https://avatars.githubusercontent.com/u/11677720?v=4"},"body":"On 01/10/12 19:16, Junio C Hamano wrote:\n> Simon Oosthoek writes:\n> \n>> On 09/28/2012 07:58 PM, Junio C Hamano wrote:\n>>> Simon Oosthoek writes:\n>>>\n>>>> +# __git_ps1_pc accepts 0 arguments (for now)\n>>>> +# It is meant to be used as PROMPT_COMMAND, it sets PS1\n>>>> +__git_ps1_pc ()\n>>>> +{\n>>>> +\tlocal g=\"$(__gitdir)\"\n>>>> +\tif [ -n \"$g\" ]; then\n>>>> +...\n>>>> +\tfi\n>>>> +}\n>>>\n>>> This looks awfully similar to the existing code in __git_ps1\n>>> function. Without refactoring to share the logic between them, it\n>>> won't be maintainable.\n>>>\n>>\n>> I agree that it's ugly. How about the following:\n>>\n>> I modified __git_ps1 to work both in PROMPT_COMMAND mode and in that\n>> mode support color hints.\n>>\n>> This way there's one function, so no overlap.\n> \n> I think the logical progression would be\n> \n> - there are parts of __git_ps1 you want to reuse for your\n> __git_ps1_pc; separate that part out as a helper function,\n> and make __git_ps1 call it, without changing what __git_ps1\n> does (i.e. no colors, etc.)\n> \n> - add __git_ps1_pc that uses the helper function you separated\n> out.\n> \n> - add whatever bells and whistles that are useful for users of\n> either __git_ps1 or __git_ps1_pc to that helper function.\n> \n> \n\nSince this is the shell, it could turn out to be ugly this way:\n\nfunction ps1_common {\n\tset global variable (branchname, dirty state, untracked files,\ndivergence from upstream, etc.)\n}\n\nfunction __git_ps1 {\n\tcall ps1_common\n\tprint PS1 string based on format string or default (color in prompt\nisn't an option) and include global variables where necessary\n}\n\nfunction __git_ps1_pc {\n\tcall ps1_common\n\tset PS1=....\n\tbased on hardcoded PS1 definition, expand the PS1 using global\nvariables (add color if requested)\n}\n\nThe problem I see is that it would involve a lot of global variables\nvisible in the shell (OTOH, they could be used by other scripts, but\nonly when using this prompt ;-).\nOr you could print a string, which can be caught in the relevant _ps1\nfunction, but then this string needs to be chopped up and processed (by\na bunch of awk oneliners or bash-voodoo)\n\nThe latter introduces so much overhead (in processing and\nmaintainability) that I think it should not be considered.\n\nThat leaves passing the variables from one function to another using\nglobally scoped variables in the shell.\n\nIt can be done, but the current combined implementation has only the\nglobal variables set by the user (GIT_PS1_SHOWDIRTYSTATE and so on) and\nthe rest remains local to the function.\n\nThe main obstacle to better code here is the need to work around the\nshell's oddities. :-(\n\nCheers\n\nSimon\n"},{"id":"200283","messageId":"7v4nmec8fi.fsf@alter.siamese.dyndns.org","threadId":"31656","inReplyTo":"7v626udse6.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Add __git_ps1_pc to use as PROMPT_COMMAND","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-10-01T19:13:21Z","receivedAt":"2012-10-01T19:13:21Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n>> I agree that it's ugly. How about the following:\n>>\n>> I modified __git_ps1 to work both in PROMPT_COMMAND mode and in that\n>> mode support color hints.\n>>\n>> This way there's one function, so no overlap.\n>\n> I think the logical progression would be\n>\n> - there are parts of __git_ps1 you want to reuse for your\n> __git_ps1_pc; separate that part out as a helper function,\n> and make __git_ps1 call it, without changing what __git_ps1\n> does (i.e. no colors, etc.)\n>\n> - add __git_ps1_pc that uses the helper function you separated\n> out.\n>\n> - add whatever bells and whistles that are useful for users of\n> either __git_ps1 or __git_ps1_pc to that helper function.\n\nHrm, let me ask a stupid question. Why do we even need __git_ps1_pc\nin the first place? Wouldn't it be just the matter of\n\n\tPROMPT_COMMAND='__git_ps1 \"%s\"'\n\nonce you have __git_ps1 that works?\n"},{"id":"200286","messageId":"5069EE8D.6050200@nieuwland.nl","threadId":"31656","inReplyTo":"7v4nmec8fi.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Add __git_ps1_pc to use as PROMPT_COMMAND","fromName":"Simon Oosthoek","fromEmail":"soosthoek@nieuwland.nl","sentAt":"2012-10-01T19:27:09Z","receivedAt":"2012-10-01T19:27:09Z","isPatch":true,"sender":{"key":"soosthoek@nieuwland.nl","avatar":null},"body":"On 01/10/12 21:13, Junio C Hamano wrote:\n\n> Hrm, let me ask a stupid question. Why do we even need __git_ps1_pc\n> in the first place? Wouldn't it be just the matter of\n> \n> \tPROMPT_COMMAND='__git_ps1 \"%s\"'\n> \n> once you have __git_ps1 that works?\n\nApart from one small detail, PS1 must be set directly when __git_ps1 is\ncalled as a PROMPT_COMMAND, while in command substitution mode,\n__git_ps1 needs to put out a string value to substitute...\n\nThis is the way it works now (I'll send the patch later this week, I\nwant to test it some more...)\n\n/Simon\n"},{"id":"200287","messageId":"7vr4piaryi.fsf@alter.siamese.dyndns.org","threadId":"31656","inReplyTo":"5069EE8D.6050200@nieuwland.nl","subject":"Re: [PATCH] Add __git_ps1_pc to use as PROMPT_COMMAND","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-10-01T19:54:29Z","receivedAt":"2012-10-01T19:54:29Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Simon Oosthoek writes:\n\n> On 01/10/12 21:13, Junio C Hamano wrote:\n>\n>> Hrm, let me ask a stupid question. Why do we even need __git_ps1_pc\n>> in the first place? Wouldn't it be just the matter of\n>> \n>> \tPROMPT_COMMAND='__git_ps1 \"%s\"'\n>> \n>> once you have __git_ps1 that works?\n>\n> Apart from one small detail, PS1 must be set directly when __git_ps1 is\n> called as a PROMPT_COMMAND, while in command substitution mode,\n> __git_ps1 needs to put out a string value to substitute...\n\nNow you lost me. The documentation of PROMPT_COMMAND in \"man bash\"\nsays this:\n\n PROMPT_COMMAND\n If set, the value is executed as a command prior to\n issuing each primary prompt.\n\nSo yes, if you say \"PROMPT_COMMAND='whatever'\", you will get output\nfrom 'whatever' followed by what $PS1 would normally give you. \nIf you do not want to see PS1 after 'whatever' gives you, you have\nto set it to an empty string.\n\nOn the other hand, they way people have been using __git_ps1 is (as\ndescribed in the prompt script) to do something like this:\n\n\tPS1='...cruft... $(__git_ps1 \"%s\") ...cruft...'\n\nTo keep supporting them, __git_ps1 has to be a function that writes\nthe prompt string to its standard output. The external interface of\nPROMPT_COMMAND also is that it wants a command that emits the string\ndesired for the prompt to its standard output. I do not see any\n\"when it is used like this, X, but when it is used like that, Y\"\nkind of issue around it, either.\n\nSo what is the problem????\n"},{"id":"200291","messageId":"506A0366.6030009@xs4all.nl","threadId":"31656","inReplyTo":"7vr4piaryi.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Add __git_ps1_pc to use as PROMPT_COMMAND","fromName":"Simon Oosthoek","fromEmail":"s.oosthoek@xs4all.nl","sentAt":"2012-10-01T20:56:06Z","receivedAt":"2012-10-01T20:56:06Z","isPatch":true,"sender":{"key":"s.oosthoek@xs4all.nl","avatar":"https://avatars.githubusercontent.com/u/11677720?v=4"},"body":"On 01/10/12 21:54, Junio C Hamano wrote:\n> Now you lost me. The documentation of PROMPT_COMMAND in \"man bash\"\n> says this:\n> \n> PROMPT_COMMAND\n> If set, the value is executed as a command prior to\n> issuing each primary prompt.\n> \n> So yes, if you say \"PROMPT_COMMAND='whatever'\", you will get output\n> from 'whatever' followed by what $PS1 would normally give you. \n> If you do not want to see PS1 after 'whatever' gives you, you have\n> to set it to an empty string.\n> \n> On the other hand, they way people have been using __git_ps1 is (as\n> described in the prompt script) to do something like this:\n> \n> \tPS1='...cruft... $(__git_ps1 \"%s\") ...cruft...'\n> \n> To keep supporting them, __git_ps1 has to be a function that writes\n> the prompt string to its standard output. The external interface of\n> PROMPT_COMMAND also is that it wants a command that emits the string\n> desired for the prompt to its standard output. I do not see any\n> \"when it is used like this, X, but when it is used like that, Y\"\n> kind of issue around it, either.\n> \n> So what is the problem????\n> \n\nWell, I hadn't thought about that way of using it. It works in a way...\n\nBut PS1 is set and interpreted in a special way by bash (I gather from\nexamples, I'm kind of confused by it).\n\nIt's possible to set PS1 to nothing and print a string from\nPROMPT_COMMAND, but then you miss out on all the features of the PS1\ninterpretation by bash and compared to the use of __git_ps1 at the\nmoment, it has to put out quite a different string. Because if you like\nto see user@host+workdir (git-status)[$#]\nthe current users of __git_ps1 say PS1=\"\\u@host+\\w $(__git_ps1 \"%s\")\\$\n\", but all __git+ps1 has to put out is \"(branch)\" or \"(branch *)\", etc.\n\nIf it has to print the same prompt in PC mode, it has to add all the\nuser/host/workdir/[$#] data as well, withouth being able to use the bash\ninternal interpretation (because that is only working when PS1 is set).\n\nThe example(s) I found when googling for a solution were to set PS1\ninside the PC function, in a way that it was possible to add color\nencodings, without messing up the wrapping. This is _impossible_ using\ncommand substitution, because then bash doesn't interpret the \\[ and \\]\naround the color codes, and that messes up the accounting of how long\nthe prompt string is.\n\n/Simon\n"},{"id":"200293","messageId":"7va9w5c31w.fsf@alter.siamese.dyndns.org","threadId":"31656","inReplyTo":"506A0366.6030009@xs4all.nl","subject":"Re: [PATCH] Add __git_ps1_pc to use as PROMPT_COMMAND","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-10-01T21:09:31Z","receivedAt":"2012-10-01T21:09:31Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Simon Oosthoek writes:\n\n> It's possible to set PS1 to nothing and print a string from\n> PROMPT_COMMAND, but then you miss out on all the features of the PS1\n> interpretation by bash and compared to the use of __git_ps1 at the\n> moment, it has to put out quite a different string. Because if you like\n> to see user@host+workdir (git-status)[$#]\n> the current users of __git_ps1 say PS1=\"\\u@host+\\w $(__git_ps1 \"%s\")\\$\n> \", but all __git+ps1 has to put out is \"(branch)\" or \"(branch *)\", etc.\n>\n> If it has to print the same prompt in PC mode, it has to add all the\n> user/host/workdir/[$#] data as well, withouth being able to use the bash\n> internal interpretation (because that is only working when PS1 is set).\n\nThe longer I read your explanation, the less useful the \"PC mode\"\nsounds like, at least to me. So why does an user even want to use\nsuch a mechanism, instead of PS1? And even if the user wants to use\nit by doing \\w, \\u etc. himself, she can do that with\n\n\tPROMPT_COMMAND='\n\t\tPS1=$(printf \"\\u \\h \\w %s$ \" $(__git_ps1 \"%s\"))\n '\n\njust fine, no?\n\nSo I still do not see the problem, even taking your \"Set PS1 in the\ncommand, without spitting anything out of the command\" use case into\naccount.\n\nConfused....\n"},{"id":"200311","messageId":"506A99DE.7080503@drmicha.warpmail.net","threadId":"31656","inReplyTo":"7va9w5c31w.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Add __git_ps1_pc to use as PROMPT_COMMAND","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2012-10-02T07:38:06Z","receivedAt":"2012-10-02T07:38:06Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 01.10.2012 23:09:\n> Simon Oosthoek writes:\n> \n>> It's possible to set PS1 to nothing and print a string from\n>> PROMPT_COMMAND, but then you miss out on all the features of the PS1\n>> interpretation by bash and compared to the use of __git_ps1 at the\n>> moment, it has to put out quite a different string. Because if you like\n>> to see user@host+workdir (git-status)[$#]\n>> the current users of __git_ps1 say PS1=\"\\u@host+\\w $(__git_ps1 \"%s\")\\$\n>> \", but all __git+ps1 has to put out is \"(branch)\" or \"(branch *)\", etc.\n>>\n>> If it has to print the same prompt in PC mode, it has to add all the\n>> user/host/workdir/[$#] data as well, withouth being able to use the bash\n>> internal interpretation (because that is only working when PS1 is set).\n> \n> The longer I read your explanation, the less useful the \"PC mode\"\n> sounds like, at least to me. So why does an user even want to use\n> such a mechanism, instead of PS1? And even if the user wants to use\n> it by doing \\w, \\u etc. himself, she can do that with\n> \n> \tPROMPT_COMMAND='\n> \t\tPS1=$(printf \"\\u \\h \\w %s$ \" $(__git_ps1 \"%s\"))\n> '\n> \n> just fine, no?\n> \n> So I still do not see the problem, even taking your \"Set PS1 in the\n> command, without spitting anything out of the command\" use case into\n> account.\n> \n> Confused....\n> \n\nThe \"problem\" (as far as I see) is only: What user interface do we want\nto expose to the user, or rather, do we want to expose the user to ;)\n\nSo far, we say:\n\n# 1) Copy this file to somewhere (e.g. ~/.git-prompt.sh).\n# 2) Add the following line to your .bashrc/.zshrc:\n# source ~/.git-prompt.sh\n# 3) Change your PS1 to also show the current branch:\n# Bash: PS1='[\\u@\\h \\W$(__git_ps1 \" (%s)\")]\\$ '\n# ZSH: PS1='[%n@%m %c$(__git_ps1 \" (%s)\")]\\$ '\n\n(That's incomplete for zsh, but I'm digressing...). With the above, we\nwould change the bash instruction to\n\nPROMPT_COMMAND='\n\tPS1=$(printf \"\\u \\h \\w %s$ \" $(__git_ps1 \"%s\"))\n '\n\nwhich may look more complicated to some. I think we can aim for\nsomething like\n\nPROMPT_COMMAND='__git_ps1_color \"\\u \\h \\w%s$ \" \" (%s)\"'\n\nso that the first arg is a PS1 string, %s there gets replaced by the git\nprompt (if any), and the second arg defines the formatting of the git\nprompt. This makes the \"ui\" (what you have to set the shells vars to) as\nsimple as possible.\n\nAs I said, I had done some fixes and refactoring to that effect already,\nbut I'm not going to race Simon.\n\nMichael\n"},{"id":"200314","messageId":"506A9F44.1000209@nieuwland.nl","threadId":"31656","inReplyTo":"506A99DE.7080503@drmicha.warpmail.net","subject":"Re: [PATCH] Add __git_ps1_pc to use as PROMPT_COMMAND","fromName":"Simon Oosthoek","fromEmail":"soosthoek@nieuwland.nl","sentAt":"2012-10-02T08:01:08Z","receivedAt":"2012-10-02T08:01:08Z","isPatch":true,"sender":{"key":"soosthoek@nieuwland.nl","avatar":null},"body":"On 10/02/2012 09:38 AM, Michael J Gruber wrote:\n>> The longer I read your explanation, the less useful the \"PC mode\"\n>> sounds like, at least to me. So why does an user even want to use\n>> such a mechanism, instead of PS1? And even if the user wants to use\n>> it by doing \\w, \\u etc. himself, she can do that with\n>>\n>> \tPROMPT_COMMAND='\n>> \t\tPS1=$(printf \"\\u \\h \\w %s$ \" $(__git_ps1 \"%s\"))\n>> '\n>>\n>> just fine, no?\n\nWell, in that way, it doesn't work and setting PS1 directly would be \nbetter. But this way you cannot do colors.\n\n>>\n>> Confused....\n\nI know the feeling ;-)\n\n>\n> The \"problem\" (as far as I see) is only: What user interface do we want\n> to expose to the user, or rather, do we want to expose the user to ;)\n>\n> So far, we say:\n>\n> # 1) Copy this file to somewhere (e.g. ~/.git-prompt.sh).\n> # 2) Add the following line to your .bashrc/.zshrc:\n> # source ~/.git-prompt.sh\n> # 3) Change your PS1 to also show the current branch:\n> # Bash: PS1='[\\u@\\h \\W$(__git_ps1 \" (%s)\")]\\$ '\n> # ZSH: PS1='[%n@%m %c$(__git_ps1 \" (%s)\")]\\$ '\n>\n> (That's incomplete for zsh, but I'm digressing...). With the above, we\n> would change the bash instruction to\n>\n> PROMPT_COMMAND='\n> \tPS1=$(printf \"\\u \\h \\w %s$ \" $(__git_ps1 \"%s\"))\n> '\n>\n> which may look more complicated to some. I think we can aim for\n> something like\n>\n> PROMPT_COMMAND='__git_ps1_color \"\\u \\h \\w%s$ \" \" (%s)\"'\n>\n> so that the first arg is a PS1 string, %s there gets replaced by the git\n> prompt (if any), and the second arg defines the formatting of the git\n> prompt. This makes the \"ui\" (what you have to set the shells vars to) as\n> simple as possible.\n>\n> As I said, I had done some fixes and refactoring to that effect already,\n> but I'm not going to race Simon.\n\nI don't quite see how you're going to smurf the formatted string into \nthe PS1 string at %s...\n\nWouldn't it be easier in this case to have the user provide 3 arguments:\n\nPROMPT_COMMAND='__git_ps1 \"\\u@\\h:\\w \" \"(%s)\" \"\\$ \"'\n\nThe first and last can be directly assigned to PS1 and the format string \ncan be put in the middle.\n\nBUT. In this way, it is still impossible to change the colors inside the \nformat string, unless you ignore that when the user requested color \nhints. Because the output of printf will not be interpreted by bash when \nput in via command substitution.\n\nThe whole point of this exercise (for me at least) was to be able to \ncolor different parts of the bit that __git_ps1 put in, based on the \ncurrent state of the tree.\n\nI think the user interface could be something like:\n\nuse either:\nPROMPT_COMMAND='__git_ps1 \"\\u@\\h:\\w \" \"\\$ \"' # 2 args!\nor\nPS1=\"\\u@\\h:\\w $(__git_ps1 '(%s)')\\$ \"\n\n(I just realised that I still need to handle the case where both PS1 and \nPROMPT_COMMAND contain __git_ps1 ;-)\n\nNote that in the PS1 case, no color codes should be put into the string, \nas they will mangle the prompt length and wrapping problems start happening.\n\nCheers\n\nSimon.\n"},{"id":"200344","messageId":"7vhaqcajvt.fsf@alter.siamese.dyndns.org","threadId":"31656","inReplyTo":"506A99DE.7080503@drmicha.warpmail.net","subject":"Re: [PATCH] Add __git_ps1_pc to use as PROMPT_COMMAND","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-10-02T17:01:10Z","receivedAt":"2012-10-02T17:01:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber writes:\n\n> Junio C Hamano venit, vidit, dixit 01.10.2012 23:09:\n>\n>> Confused....\n>> \n>\n> The \"problem\" (as far as I see) is only: What user interface do we want\n> to expose to the user, or rather, do we want to expose the user to ;)\n>\n> So far, we say:\n>\n> # 1) Copy this file to somewhere (e.g. ~/.git-prompt.sh).\n> # 2) Add the following line to your .bashrc/.zshrc:\n> # source ~/.git-prompt.sh\n> # 3) Change your PS1 to also show the current branch:\n> # Bash: PS1='[\\u@\\h \\W$(__git_ps1 \" (%s)\")]\\$ '\n> # ZSH: PS1='[%n@%m %c$(__git_ps1 \" (%s)\")]\\$ '\n>\n> (That's incomplete for zsh, but I'm digressing...). With the above, we\n> would change the bash instruction to\n>\n> PROMPT_COMMAND='\n> \tPS1=$(printf \"\\u \\h \\w %s$ \" $(__git_ps1 \"%s\"))\n> '\n>\n> which may look more complicated to some. I think we can aim for\n> something like\n>\n> PROMPT_COMMAND='__git_ps1_color \"\\u \\h \\w%s$ \" \" (%s)\"'\n\nIf your goal is to use PROMPT_COMMAND and not PS1, then yes between\nthe two definitions of PROMPT_COMMAND above, the latter may look\nsimpler. But that does not explain why you want to prefer it over\nPS1 in the first place, which was the central point of my question\nthat still has not been answered.\n\nEven more confused...\n"},{"id":"200365","messageId":"506B4598.1020206@xs4all.nl","threadId":"31656","inReplyTo":"7vhaqcajvt.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Add __git_ps1_pc to use as PROMPT_COMMAND","fromName":"Simon Oosthoek","fromEmail":"s.oosthoek@xs4all.nl","sentAt":"2012-10-02T19:50:48Z","receivedAt":"2012-10-02T19:50:48Z","isPatch":true,"sender":{"key":"s.oosthoek@xs4all.nl","avatar":"https://avatars.githubusercontent.com/u/11677720?v=4"},"body":"On 02/10/12 19:01, Junio C Hamano wrote:\n> If your goal is to use PROMPT_COMMAND and not PS1, then yes between\n> the two definitions of PROMPT_COMMAND above, the latter may look\n> simpler. But that does not explain why you want to prefer it over\n> PS1 in the first place, which was the central point of my question\n> that still has not been answered.\n> \n> Even more confused...\n> \n\nThe specific answer to your question is that without using\nPROMPT_COMMAND it doesn't seem to be possible to use colors based on the\nstate of the git tree. The reason being that in order to prevent\nwrapping problems on the command line (specifically going up/down the\nhistory list in bash or line wrapping on a long command). This is\nprevented (and quite the norm in static PS1 strings) by enclosing the\nterminal code for color inside \\[ and \\] so bash doesn't count these and\nwhat is in between them in the length of the prompt string.\n\nThe only way to get the colors in without messing up normal functioning\nof the prompt is to use PROMPT_COMMAND to set PS1, with colors based\ndynamically on the state of the tree.\n\nIn my current version (which I haven't had time to properly send out,\nsorry!) it can do both using the same __git_ps1 function. But only color\nin the PROMPT_COMMAND mode for the reason laid out above.\n\nHaving said that, I think there's another benefit to using\nPROMPT_COMMAND; I think it is more elegant to use a function via\nPROMPT_COMMAND (now that I know of it), than using a function via\ncommand substitution inside the PS1.\n\nI guess your (and my) confusion is more caused by unfamiliarity with\nthis feature of bash than it being used. Is that correct?\n\n*desperately trying to get out of confused mode*\n\nCheers\n\nSimon\n"},{"id":"200368","messageId":"7v8vbo7hmd.fsf@alter.siamese.dyndns.org","threadId":"31656","inReplyTo":"506B4598.1020206@xs4all.nl","subject":"Re: [PATCH] Add __git_ps1_pc to use as PROMPT_COMMAND","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-10-02T20:18:18Z","receivedAt":"2012-10-02T20:18:18Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Simon Oosthoek writes:\n\n> ... This is\n> prevented (and quite the norm in static PS1 strings) by enclosing the\n> terminal code for color inside \\[ and \\] so bash doesn't count these and\n> what is in between them in the length of the prompt string.\n\nAh, OK, and these \\[ things \\] behave like other magics like \\h and \\W\nin PS1 in that PS1='\\h $(echo_bs_w)' will not work as expected with\n\n\techo_bs_w () {\n\t\tprintf \"%s\" \"\\\\W\"\n\t}\n\nhence cannot be used in __git_ps1 function that is called as $(command\nsubstitution).\n\nThat was what I was missing.\n\n> The only way to get the colors in without messing up normal functioning\n> of the prompt is to use PROMPT_COMMAND to set PS1, with colors based\n> dynamically on the state of the tree.\n\nOK. Thanks for explanation.\n"},{"id":"200640","messageId":"20121005210945.GA4961@simaj.xs4all.nl","threadId":"31656","inReplyTo":"7v8vbo7hmd.fsf@alter.siamese.dyndns.org","subject":"[PATCH 1/2] Allow __git_ps1 to be used in PROMPT_COMMAND","fromName":"Simon Oosthoek","fromEmail":"s.oosthoek@xs4all.nl","sentAt":"2012-10-05T21:09:45Z","receivedAt":"2012-10-05T21:09:45Z","isPatch":true,"sender":{"key":"s.oosthoek@xs4all.nl","avatar":"https://avatars.githubusercontent.com/u/11677720?v=4"},"body":"changes __git_ps1 to not just allow use in setting PS1\nwith __git_ps1 in a command substitution, but also allows\n__git_ps1 to be used as PROMPT_COMMAND in bash.\nThis has advantages for using color and I think it is more\nelegant\n\nSigned-off-by: Simon Oosthoek \n---\n contrib/completion/git-prompt.sh | 51 +++++++++++++++++++++++++++++++++-----\n 1 file changed, 45 insertions(+), 6 deletions(-)\n\ndiff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh\nindex 29b1ec9..c50c94a 100644\n--- a/contrib/completion/git-prompt.sh\n+++ b/contrib/completion/git-prompt.sh\n@@ -10,9 +10,14 @@\n # 1) Copy this file to somewhere (e.g. ~/.git-prompt.sh).\n # 2) Add the following line to your .bashrc/.zshrc:\n # source ~/.git-prompt.sh\n-# 3) Change your PS1 to also show the current branch:\n-# Bash: PS1='[\\u@\\h \\W$(__git_ps1 \" (%s)\")]\\$ '\n-# ZSH: PS1='[%n@%m %c$(__git_ps1 \" (%s)\")]\\$ '\n+# 3a) In ~/.bashrc set PROMPT_COMMAND=__git_ps1\n+# To customize the prompt, provide start/end arguments\n+# PROMPT_COMMAND=\"__git_ps1 '\\u@\\h:\\w (' ')\\$ '\"\n+# 3b) Alternatively change your PS1 to call __git_ps1 as\n+# command-substitution:\n+# Bash: PS1='[\\u@\\h \\W$(__git_ps1 \" (%s)\")]\\$ '\n+# ZSH: PS1='[%n@%m %c$(__git_ps1 \" (%s)\")]\\$ '\n+# the optional argument will be used as format string\n #\n # The argument to __git_ps1 will be displayed only if you are currently\n # in a git repository. The %s token will be the name of the current\n@@ -194,11 +199,41 @@ __git_ps1_show_upstream ()\n \n \n # __git_ps1 accepts 0 or 1 arguments (i.e., format string)\n-# returns text to add to bash PS1 prompt (includes branch name)\n+# when called from PS1 using command substitution\n+# in this mode it returns text to add to bash PS1 prompt (includes branch name) or\n+# __git_ps1 accepts 0 or 2 arguments when called from PROMPT_COMMAND\n+# in that case it _sets_ PS1. The arguments are parts of a PS1 string.\n+# when both arguments are given, the first is prepended and the second appended\n+# to the state string when assigned to PS1, otherwise default start/end strings\n+# are used.\n __git_ps1 ()\n {\n+\tlocal pcmode=yes\n+\tlocal ps1pc_start='\\u@\\h:\\w '\n+\tlocal ps1pc_end='\\$ '\n+\n+\tcase \"$PROMPT_COMMAND\" in\n+\t\t__git_ps1*)\n+\t\t\tif [ $# = 2 ]; then\n+\t\t\t\tps1pc_start=\"$1\"\n+\t\t\t\tps1pc_end=\"$2\"\n+\t\t\tfi\n+\t\t\tcase \"$PS1\" in\n+\t\t\t*__git_ps1*)\n+\t\t\t\techo '\u001b[31m__git_ps1: overwriting PS1 due to PROMPT_COMMAND\u001b[0m'\n+\t\t\t;;\n+\t\t\tesac\n+\t\t;;\n+\t\t*) pcmode=no ;; #no output\n+\tesac\n+\n \tlocal g=\"$(__gitdir)\"\n-\tif [ -n \"$g\" ]; then\n+\tif [ -z \"$g\" ]; then\n+\t\tif [ $pcmode = yes ]; then\n+\t\t\t#In PC mode PS1 always needs to be set\n+\t\t\tPS1=\"$ps1pc_start$ps1pc_end\"\n+\t\tfi\n+\telse\n \t\tlocal r=\"\"\n \t\tlocal b=\"\"\n \t\tif [ -f \"$g/rebase-merge/interactive\" ]; then\n@@ -284,6 +319,10 @@ __git_ps1 ()\n \t\tfi\n \n \t\tlocal f=\"$w$i$s$u\"\n-\t\tprintf -- \"${1:- (%s)}\" \"$c${b##refs/heads/}${f:+ $f}$r$p\"\n+\t\tif [ $pcmode = yes ]; then\n+\t\t\tPS1=\"$ps1pc_start($c${b##refs/heads/}${f:+ $f}$r$p)$ps1pc_end\"\n+\t\telif [ $pcmode = no ]; then\n+\t\t\tprintf -- \"${1:- (%s)}\" \"$c${b##refs/heads/}${f:+ $f}$r$p\"\n+\t\tfi\n \tfi\n }\n-- \n1.7.9.5\n"},{"id":"200639","messageId":"20121005211030.GA5414@simaj.xs4all.nl","threadId":"31656","inReplyTo":"7v8vbo7hmd.fsf@alter.siamese.dyndns.org","subject":"[PATCH 2/2] show color hints based on state of the git tree","fromName":"Simon Oosthoek","fromEmail":"s.oosthoek@xs4all.nl","sentAt":"2012-10-05T21:10:30Z","receivedAt":"2012-10-05T21:10:30Z","isPatch":true,"sender":{"key":"s.oosthoek@xs4all.nl","avatar":"https://avatars.githubusercontent.com/u/11677720?v=4"},"body":"By setting GIT_PS1_SHOW_COLORHINTS when using __git_ps1\nas PROMPT_COMMAND, you will get color hints in addition to\na different character (*+% etc.)\n\nSigned-off-by: Simon Oosthoek \n---\n contrib/completion/git-prompt.sh | 42 +++++++++++++++++++++++++++++++++++---\n 1 file changed, 39 insertions(+), 3 deletions(-)\n\ndiff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh\nindex c50c94a..51285d7 100644\n--- a/contrib/completion/git-prompt.sh\n+++ b/contrib/completion/git-prompt.sh\n@@ -53,6 +53,12 @@\n # find one, or @{upstream} otherwise. Once you have set\n # GIT_PS1_SHOWUPSTREAM, you can override it on a per-repository basis by\n # setting the bash.showUpstream config variable.\n+#\n+# If you would like a colored hint about the current dirty state, set\n+# GIT_PS1_SHOWCOLORHINTS to a nonempty value. When tracked files are\n+# modified, the branch name turns red, when all modifications are staged\n+# the branch name turns yellow and when all changes are checked in, the\n+# color changes to green. The colors are currently hardcoded in the function.\n \n # __gitdir accepts 0 or 1 arguments (i.e., location)\n # returns location of .git repo\n@@ -201,11 +207,12 @@ __git_ps1_show_upstream ()\n # __git_ps1 accepts 0 or 1 arguments (i.e., format string)\n # when called from PS1 using command substitution\n # in this mode it returns text to add to bash PS1 prompt (includes branch name) or\n-# __git_ps1 accepts 0 or 2 arguments when called from PROMPT_COMMAND\n+# __git_ps1 accepts 0 or 2 arguments when called from PROMPT_COMMAND (pc)\n # in that case it _sets_ PS1. The arguments are parts of a PS1 string.\n # when both arguments are given, the first is prepended and the second appended\n # to the state string when assigned to PS1, otherwise default start/end strings\n # are used.\n+# In pcmode you can request colored hints using GIT_PS1_SHOWCOLORHINTS=true\n __git_ps1 ()\n {\n \tlocal pcmode=yes\n@@ -320,8 +327,37 @@ __git_ps1 ()\n \n \t\tlocal f=\"$w$i$s$u\"\n \t\tif [ $pcmode = yes ]; then\n-\t\t\tPS1=\"$ps1pc_start($c${b##refs/heads/}${f:+ $f}$r$p)$ps1pc_end\"\n-\t\telif [ $pcmode = no ]; then\n+\t\t\tPS1=\"$ps1pc_start(\"\n+\t\t\tif [ -n \"${GIT_PS1_SHOWCOLORHINT-}\" ]; then\n+\t\t\t\tlocal c_red='\\e[31m'\n+\t\t\t\tlocal c_green='\\e[32m'\n+\t\t\t\tlocal c_yellow='\\e[33m'\n+\t\t\t\tlocal c_lblue='\\e[1;34m'\n+\t\t\t\tlocal c_purple='\\e[35m'\n+\t\t\t\tlocal c_cyan='\\e[36m'\n+\t\t\t\tlocal c_clear='\\e[0m'\n+\t\t\t\tlocal branchstring=\"$c${b##refs/heads/}\"\n+\t\t\t\tlocal branch_color=\"$c_green\"\n+\t\t\t\tlocal flags_color=\"$c_cyan\"\n+\n+\t\t\t\tif [ \"$w\" = \"*\" ]; then\n+\t\t\t\t\tbranch_color=\"$c_red\"\n+\t\t\t\telif [ -n \"$i\" ]; then\n+\t\t\t\t\tbranch_color=\"$c_yellow\"\n+\t\t\t\tfi\n+\n+\t\t\t\t# Setting PS1 directly with \\[ and \\] around colors\n+\t\t\t\t# is necessary to prevent wrapping issues!\n+\t\t\t\tPS1=\"$PS1\\[$branch_color\\]$branchstring\\[$c_clear\\]\"\n+\t\t\t\tif [ -n \"$f\" ]; then\n+\t\t\t\t\tPS1=\"$PS1 \\[$flags_color\\]$f\\[$c_clear\\]\"\n+\t\t\t\tfi\n+\t\t\telse\n+\t\t\t\tPS1=\"$PS1$c${b##refs/heads/}${f:+ $f}$r$p\"\n+\t\t\tfi\n+\t\t\tPS1=\"$PS1)$ps1pc_end\"\n+\t\telse\n+\t\t\t# NO color option unless in PROMPT_COMMAND mode\n \t\t\tprintf -- \"${1:- (%s)}\" \"$c${b##refs/heads/}${f:+ $f}$r$p\"\n \t\tfi\n \tfi\n-- \n1.7.9.5\n"},{"id":"200747","messageId":"5072EA97.3060503@nieuwland.nl","threadId":"31656","inReplyTo":"7v8vbo7hmd.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Add __git_ps1_pc to use as PROMPT_COMMAND","fromName":"Simon Oosthoek","fromEmail":"soosthoek@nieuwland.nl","sentAt":"2012-10-08T15:00:39Z","receivedAt":"2012-10-08T15:00:39Z","isPatch":true,"sender":{"key":"soosthoek@nieuwland.nl","avatar":null},"body":"Hi Junio\n\nI hope you found my patches, if not, I'll try to send them out again. \n(Unfortunately my current mail setup is a mess and I need time to figure \nout what to fix...)\n\nAs for the zsh support, I found out a little bit more.\nZSH doesn't have a variable like PROMPT_COMMAND in bash. The precmd name \nis a function the user has to define herself to have it called before \nthe prompt is shown. Functionally this is almost, but not quite, the \nsame as PROMPT_COMMAND. The subtle difference is that with \nPROMPT_COMMAND you can use parameters to customize the prompt, so in \nbash you can say:\n\nPROMPT_COMMAND=\"__git_ps1 '\\u@\\[\\e[1;34m\\]\\h\\[\\e[0m\\]:\\w' '\\\\\\$ '\"\n\nwhere in zsh, if you want the status in the prompt, you can either use \n$(__git_ps1 \"(%s)\") or something like it in setting the PS1 (and forget \nabout the color hints!) or you can copy the __git_ps1 function and \nmodify and rename it as precmd to set PS1 via that function. Obviously \nit is probably even more complicated, but I'd have to try it to be certain.\n\nAn alternative way might be to set special variables from __git_set_vars \nfunction which may be used in a custom precmd to set the prompt.\n\ne.g. say __git_set_vars sets __GIT_VAR_STATE=dirty|stage|clean\n\nin precmd you could do\ncase $__GIT_VAR_STATE in\n(dirty) PS1=\"$PS1 files modified in __GIT_VAR_BRANCHNAME\"\n;;\n(stage) PS1=\"$PS1 files staged in __GIT_VAR_BRANCHNAME\"\n;;\n(clean) PS1=\"$PS1 __GIT_VAR_BRANCHNAME clean\"\n;;\nesac\n\n(more or less of course)..\n\nIn that way it would be possible to add the colors relatively easily \nbased on the state of the tree in a custom precmd function of zsh.\n\n/Simon\n"},{"id":"200770","messageId":"7vr4p8lto5.fsf@alter.siamese.dyndns.org","threadId":"31656","inReplyTo":"20121005210945.GA4961@simaj.xs4all.nl","subject":"Re: [PATCH 1/2] Allow __git_ps1 to be used in PROMPT_COMMAND","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-10-08T18:12:26Z","receivedAt":"2012-10-08T18:12:26Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Simon Oosthoek writes:\n\n> changes __git_ps1 to not just allow use in setting PS1\n> with __git_ps1 in a command substitution, but also allows\n> __git_ps1 to be used as PROMPT_COMMAND in bash.\n> This has advantages for using color and I think it is more\n> elegant\n\nIs \"and I think\" necessary? I do not think it matters what _you_\nthink when judging it is worth including in the future releases ;-)\n\nA lot more important thing to say is why it has advantages for using\ncolor (remember, it took a few rounds of back and forth with me).\nUnless you are going to explain the same to all the people who are\nreading the \"git log\" output 6 months down the road, that is a more\nappropriate thing to write here.\n\n> contrib/completion/git-prompt.sh | 51 +++++++++++++++++++++++++++++++++-----\n> 1 file changed, 45 insertions(+), 6 deletions(-)\n>\n> diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh\n> index 29b1ec9..c50c94a 100644\n> --- a/contrib/completion/git-prompt.sh\n> +++ b/contrib/completion/git-prompt.sh\n> @@ -10,9 +10,14 @@\n> # 1) Copy this file to somewhere (e.g. ~/.git-prompt.sh).\n> # 2) Add the following line to your .bashrc/.zshrc:\n> # source ~/.git-prompt.sh\n> -# 3) Change your PS1 to also show the current branch:\n> -# Bash: PS1='[\\u@\\h \\W$(__git_ps1 \" (%s)\")]\\$ '\n> -# ZSH: PS1='[%n@%m %c$(__git_ps1 \" (%s)\")]\\$ '\n> +# 3a) In ~/.bashrc set PROMPT_COMMAND=__git_ps1\n> +# To customize the prompt, provide start/end arguments\n> +# PROMPT_COMMAND=\"__git_ps1 '\\u@\\h:\\w (' ')\\$ '\"\n> +# 3b) Alternatively change your PS1 to call __git_ps1 as\n> +# command-substitution:\n> +# Bash: PS1='[\\u@\\h \\W$(__git_ps1 \" (%s)\")]\\$ '\n> +# ZSH: PS1='[%n@%m %c$(__git_ps1 \" (%s)\")]\\$ '\n> +# the optional argument will be used as format string\n> #\n> # The argument to __git_ps1 will be displayed only if you are currently\n> # in a git repository. The %s token will be the name of the current\n> @@ -194,11 +199,41 @@ __git_ps1_show_upstream ()\n> \n> \n> # __git_ps1 accepts 0 or 1 arguments (i.e., format string)\n> +# when called from PS1 using command substitution\n> +# in this mode it returns text to add to bash PS1 prompt (includes branch name) or\n> +# __git_ps1 accepts 0 or 2 arguments when called from PROMPT_COMMAND\n> +# in that case it _sets_ PS1. The arguments are parts of a PS1 string.\n> +# when both arguments are given, the first is prepended and the second appended\n> +# to the state string when assigned to PS1, otherwise default start/end strings\n> +# are used.\n\nSorry, but I cannot parse this. Is this meant to be a two-item list,\none describing the command substitution mode (zero or 1 arguments) and\nthe other describing the prompt command mode? If so, perhaps replacing\nthe \" or\" at the end of the first item with \".\\n#\\n\" would make it readable.\n\n> __git_ps1 ()\n> {\n> +\tlocal pcmode=yes\n> +\tlocal ps1pc_start='\\u@\\h:\\w '\n> +\tlocal ps1pc_end='\\$ '\n> +\n> +\tcase \"$PROMPT_COMMAND\" in\n> +\t\t__git_ps1*)\n> +\t\t\tif [ $# = 2 ]; then\n> +\t\t\t\tps1pc_start=\"$1\"\n> +\t\t\t\tps1pc_end=\"$2\"\n> +\t\t\tfi\n> +\t\t\tcase \"$PS1\" in\n> +\t\t\t*__git_ps1*)\n> +\t\t\t\techo '__git_ps1: overwriting PS1 due to PROMPT_COMMAND'\n\nIs this supposed to be an error and/or warning message? Why is it\nworth warning only when you are overwriting __git_ps1 style of PS1\nand not other user customization?\n\n> +\t\t\t;;\n> +\t\t\tesac\n> +\t\t;;\n> +\t\t*) pcmode=no ;; #no output\n> +\tesac\n\nPlease align outer \"case\" \"its arms)\" and \"esac\" at the same column,\nlike you did for the inner \"case/esac\".\n\nAuto-detetction based on PROMPT_COMMAND is a flaky approach. In\npractice, nobody will call PROMPT_COMMAND with the __git_ps1 without\nany parameter (100% people want their prompt to end with some sort\nof whitespace so they want the \"what comes after what is computed\",\naka $2), and even more importantly, nobody has been relying on use\nof 0 argument form of __git_ps1 in PROMPT_COMMAND. So why not\nalways require 2 args and take that as a cue to go into the pc mode?\n\n> +\n> \tlocal g=\"$(__gitdir)\"\n> -\tif [ -n \"$g\" ]; then\n> +\tif [ -z \"$g\" ]; then\n> +\t\tif [ $pcmode = yes ]; then\n> +\t\t\t#In PC mode PS1 always needs to be set\n> +\t\t\tPS1=\"$ps1pc_start$ps1pc_end\"\n> +\t\tfi\n> +\telse\n> \t\tlocal r=\"\"\n> \t\tlocal b=\"\"\n> \t\tif [ -f \"$g/rebase-merge/interactive\" ]; then\n> @@ -284,6 +319,10 @@ __git_ps1 ()\n> \t\tfi\n> \n> \t\tlocal f=\"$w$i$s$u\"\n> -\t\tprintf -- \"${1:- (%s)}\" \"$c${b##refs/heads/}${f:+ $f}$r$p\"\n> +\t\tif [ $pcmode = yes ]; then\n> +\t\t\tPS1=\"$ps1pc_start($c${b##refs/heads/}${f:+ $f}$r$p)$ps1pc_end\"\n> +\t\telif [ $pcmode = no ]; then\n> +\t\t\tprintf -- \"${1:- (%s)}\" \"$c${b##refs/heads/}${f:+ $f}$r$p\"\n> +\t\tfi\n\nAre there $pcmode other than yes or no? Why not just \"else\",\ninstead of performing the test twice?\n\n> \tfi\n> }\n"},{"id":"200781","messageId":"50732EA1.7040608@xs4all.nl","threadId":"31656","inReplyTo":"7vr4p8lto5.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 1/2] Allow __git_ps1 to be used in PROMPT_COMMAND","fromName":"Simon Oosthoek","fromEmail":"s.oosthoek@xs4all.nl","sentAt":"2012-10-08T19:50:57Z","receivedAt":"2012-10-08T19:50:57Z","isPatch":true,"sender":{"key":"s.oosthoek@xs4all.nl","avatar":"https://avatars.githubusercontent.com/u/11677720?v=4"},"body":"Hi Junio\n\nthanks for your feedback!\n\nOn 08/10/12 20:12, Junio C Hamano wrote:\n> Simon Oosthoek writes:\n> \n>> changes __git_ps1 to not just allow use in setting PS1\n>> with __git_ps1 in a command substitution, but also allows\n>> __git_ps1 to be used as PROMPT_COMMAND in bash.\n>> This has advantages for using color and I think it is more\n>> elegant\n> \n> Is \"and I think\" necessary? I do not think it matters what _you_\n> think when judging it is worth including in the future releases ;-)\n\nHmm, right :-P\n\nHow about \"This has advantages for using color without running into\nprompt-wrapping issues. Only by assigning \\[ and \\] to PS1 directly can\nbash know these and the color codes in between don't count in the length\nof the prompt.\"?\n\nI'll rewrite the patch later on...\n\nIsn't it confusing that the color codes don't figure in this patch at all?\n\n>> \n>> # __git_ps1 accepts 0 or 1 arguments (i.e., format string)\n>> +# when called from PS1 using command substitution\n>> +# in this mode it returns text to add to bash PS1 prompt (includes branch name) or\n>> +# __git_ps1 accepts 0 or 2 arguments when called from PROMPT_COMMAND\n>> +# in that case it _sets_ PS1. The arguments are parts of a PS1 string.\n>> +# when both arguments are given, the first is prepended and the second appended\n>> +# to the state string when assigned to PS1, otherwise default start/end strings\n>> +# are used.\n> \n> Sorry, but I cannot parse this. Is this meant to be a two-item list,\n> one describing the command substitution mode (zero or 1 arguments) and\n> the other describing the prompt command mode? If so, perhaps replacing\n> the \" or\" at the end of the first item with \".\\n#\\n\" would make it readable.\n\nI agree, that would make it more readable.\n\n> \n>> __git_ps1 ()\n>> {\n>> +\tlocal pcmode=yes\n>> +\tlocal ps1pc_start='\\u@\\h:\\w '\n>> +\tlocal ps1pc_end='\\$ '\n>> +\n>> +\tcase \"$PROMPT_COMMAND\" in\n>> +\t\t__git_ps1*)\n>> +\t\t\tif [ $# = 2 ]; then\n>> +\t\t\t\tps1pc_start=\"$1\"\n>> +\t\t\t\tps1pc_end=\"$2\"\n>> +\t\t\tfi\n>> +\t\t\tcase \"$PS1\" in\n>> +\t\t\t*__git_ps1*)\n>> +\t\t\t\techo '__git_ps1: overwriting PS1 due to PROMPT_COMMAND'\n> \n> Is this supposed to be an error and/or warning message? Why is it\n> worth warning only when you are overwriting __git_ps1 style of PS1\n> and not other user customization?\n\nThat's what this is doing, I wasn't able to make it the other way\naround. I thought that I could detect when PS1 contained __git_ps1 that\nit shouldn't overwrite the PS1, which worked, but when PROMPT_COMMAND\nwas set with __git_ps1 and PS1=$(__git_ps1) as well, it gave double output.\nAs PROMPT_COMMAND is relatively obscure I thought a warning when\noverwriting the PS1 was good, but not unless there was a real conflict\n(double call to __git_ps1).\nThe warning is only shown once.\n\nI don't think it would be possible to detect any other kind of\ncustomization without including specific code for it. Do you think it's\nunnecessary to include a warning? (I think it would take people a long\ntime to figure out why their prompt goes whoopsy without getting a hint\nthat PROMPT_COMMAND messes up the PS1)\n\n(OTOH, if you configure PROMPT_COMMAND, you're bound to know a little\nbit about what you're doing...)\n\nPerhaps it's better to just do it.\n\n\n> \n>> +\t\t\t;;\n>> +\t\t\tesac\n>> +\t\t;;\n>> +\t\t*) pcmode=no ;; #no output\n>> +\tesac\n> \n> Please align outer \"case\" \"its arms)\" and \"esac\" at the same column,\n> like you did for the inner \"case/esac\".\n\nok\n\n> \n> Auto-detetction based on PROMPT_COMMAND is a flaky approach. In\n> practice, nobody will call PROMPT_COMMAND with the __git_ps1 without\n> any parameter (100% people want their prompt to end with some sort\n> of whitespace so they want the \"what comes after what is computed\",\n> aka $2), and even more importantly, nobody has been relying on use\n> of 0 argument form of __git_ps1 in PROMPT_COMMAND. So why not\n> always require 2 args and take that as a cue to go into the pc mode?\n\nThat's a good idea, I'll change that.\n\n\n>> +\t\tif [ $pcmode = yes ]; then\n>> +\t\t\tPS1=\"$ps1pc_start($c${b##refs/heads/}${f:+ $f}$r$p)$ps1pc_end\"\n>> +\t\telif [ $pcmode = no ]; then\n>> +\t\t\tprintf -- \"${1:- (%s)}\" \"$c${b##refs/heads/}${f:+ $f}$r$p\"\n>> +\t\tfi\n> \n> Are there $pcmode other than yes or no? Why not just \"else\",\n> instead of performing the test twice?\n\nI forgot to remove that one, I had a default at some point ;-)\n\nCheers\n\nSimon.\n"},{"id":"200788","messageId":"7v7gr0k6jv.fsf@alter.siamese.dyndns.org","threadId":"31656","inReplyTo":"50732EA1.7040608@xs4all.nl","subject":"Re: [PATCH 1/2] Allow __git_ps1 to be used in PROMPT_COMMAND","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-10-08T21:17:08Z","receivedAt":"2012-10-08T21:17:08Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Simon Oosthoek writes:\n\n> How about \"This has advantages for using color without running\n> into prompt-wrapping issues. Only by assigning \\[ and \\] to PS1\n> directly can bash know these and the color codes in between don't\n> count in the length of the prompt.\"?\n>\n> I'll rewrite the patch later on...\n>\n> Isn't it confusing that the color codes don't figure in this patch at all?\n\nSince the \"Subject:\" is \"allow ... to be used in PROMPT_COMMAND\", it\nvery much is relevant to mention that we need to use PROMPT_COMMAND\nin order to correctly use \\[ and \\] to generated zero-width escape\nsequences, which cannot be done by simply setting PS1 to command\nsubstitution.\n\n\"color\" is just an example; if it makes you uneasy to say \"color\",\nyou can say zero-width escape sequences. It could be \\007 (BEL) ;-)\n\n> I don't think it would be possible to detect any other kind of\n> customization without including specific code for it. Do you think it's\n> unnecessary to include a warning? (I think it would take people a long\n> time to figure out why their prompt goes whoopsy without getting a hint\n> that PROMPT_COMMAND messes up the PS1)\n\nI think you need your warning _only_ because you attempt to\nauto-detect it, when you do not have to.\n\n> (OTOH, if you configure PROMPT_COMMAND, you're bound to know a little\n> bit about what you're doing...)\n\nYup.\n"},{"id":"200940","messageId":"20121010193158.GA6454@simaj.xs4all.nl","threadId":"31656","inReplyTo":"7v7gr0k6jv.fsf@alter.siamese.dyndns.org","subject":"[PATCH 1/2] Allow __git_ps1 to be used in PROMPT_COMMAND","fromName":"Simon Oosthoek","fromEmail":"s.oosthoek@xs4all.nl","sentAt":"2012-10-10T19:31:58Z","receivedAt":"2012-10-10T19:31:58Z","isPatch":true,"sender":{"key":"s.oosthoek@xs4all.nl","avatar":"https://avatars.githubusercontent.com/u/11677720?v=4"},"body":"Changes __git_ps1 to allow its use as PROMPT_COMMAND in bash\nin addition to setting PS1 with __git_ps1 in a command substitution.\nPROMPT_COMMAND has advantages for using color without running\ninto prompt-wrapping issues. Only by assigning \\[ and \\] to PS1\ndirectly can bash know that these and the enclosed zero-width codes in\nbetween don't count in the length of the prompt.\n\nSigned-off-by: Simon Oosthoek \n---\n contrib/completion/git-prompt.sh | 51 +++++++++++++++++++++++++++++++++-----\n 1 file changed, 45 insertions(+), 6 deletions(-)\n\ndiff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh\nindex 29b1ec9..4fbc1e6 100644\n--- a/contrib/completion/git-prompt.sh\n+++ b/contrib/completion/git-prompt.sh\n@@ -10,9 +10,14 @@\n # 1) Copy this file to somewhere (e.g. ~/.git-prompt.sh).\n # 2) Add the following line to your .bashrc/.zshrc:\n # source ~/.git-prompt.sh\n-# 3) Change your PS1 to also show the current branch:\n-# Bash: PS1='[\\u@\\h \\W$(__git_ps1 \" (%s)\")]\\$ '\n-# ZSH: PS1='[%n@%m %c$(__git_ps1 \" (%s)\")]\\$ '\n+# 3a) In ~/.bashrc set PROMPT_COMMAND=__git_ps1\n+# To customize the prompt, provide start/end arguments\n+# PROMPT_COMMAND='__git_ps1 \"\\u@\\h:\\w\" \"\\\\\\$ \"'\n+# 3b) Alternatively change your PS1 to call __git_ps1 as\n+# command-substitution:\n+# Bash: PS1='[\\u@\\h \\W$(__git_ps1 \" (%s)\")]\\$ '\n+# ZSH: PS1='[%n@%m %c$(__git_ps1 \" (%s)\")]\\$ '\n+# the optional argument will be used as format string\n #\n # The argument to __git_ps1 will be displayed only if you are currently\n # in a git repository. The %s token will be the name of the current\n@@ -194,11 +199,39 @@ __git_ps1_show_upstream ()\n \n \n # __git_ps1 accepts 0 or 1 arguments (i.e., format string)\n-# returns text to add to bash PS1 prompt (includes branch name)\n+# when called from PS1 using command substitution\n+# in this mode it prints text to add to bash PS1 prompt (includes branch name)\n+#\n+# __git_ps1 requires 2 arguments when called from PROMPT_COMMAND (pc)\n+# in that case it _sets_ PS1. The arguments are parts of a PS1 string.\n+# when both arguments are given, the first is prepended and the second appended\n+# to the state string when assigned to PS1.\n __git_ps1 ()\n {\n+\tlocal pcmode=no\n+\t#defaults/examples:\n+\tlocal ps1pc_start='\\u@\\h:\\w '\n+\tlocal ps1pc_end='\\$ '\n+\tlocal printf_format='(%s)'\n+\n+\tcase \"$#\" in\n+\t\t2)\tpcmode=yes\n+\t\t\tps1pc_start=\"$1\"\n+\t\t\tps1pc_end=\"$2\"\n+\t\t;;\n+\t\t0|1)\tprintf_format=\"${1:-$printf_format}\"\n+\t\t;;\n+\t\t*)\treturn\n+\t\t;;\n+\tesac\n+\n \tlocal g=\"$(__gitdir)\"\n-\tif [ -n \"$g\" ]; then\n+\tif [ -z \"$g\" ]; then\n+\t\tif [ $pcmode = yes ]; then\n+\t\t\t#In PC mode PS1 always needs to be set\n+\t\t\tPS1=\"$ps1pc_start$ps1pc_end\"\n+\t\tfi\n+\telse\n \t\tlocal r=\"\"\n \t\tlocal b=\"\"\n \t\tif [ -f \"$g/rebase-merge/interactive\" ]; then\n@@ -284,6 +317,12 @@ __git_ps1 ()\n \t\tfi\n \n \t\tlocal f=\"$w$i$s$u\"\n-\t\tprintf -- \"${1:- (%s)}\" \"$c${b##refs/heads/}${f:+ $f}$r$p\"\n+\t\tif [ $pcmode = yes ]; then\n+\t\t\tPS1=\"$ps1pc_start(\"\n+\t\t\tPS1=\"$PS1$c${b##refs/heads/}${f:+ $f}$r$p\"\n+\t\t\tPS1=\"$PS1)$ps1pc_end\"\n+\t\telse\n+\t\t\tprintf -- \"$printf_format\" \"$c${b##refs/heads/}${f:+ $f}$r$p\"\n+\t\tfi\n \tfi\n }\n-- \n1.7.9.5\n"},{"id":"200941","messageId":"20121010193224.GA6769@simaj.xs4all.nl","threadId":"31656","inReplyTo":"7v7gr0k6jv.fsf@alter.siamese.dyndns.org","subject":"[PATCH 2/2] show color hints based on state of the git tree","fromName":"Simon Oosthoek","fromEmail":"s.oosthoek@xs4all.nl","sentAt":"2012-10-10T19:32:24Z","receivedAt":"2012-10-10T19:32:24Z","isPatch":true,"sender":{"key":"s.oosthoek@xs4all.nl","avatar":"https://avatars.githubusercontent.com/u/11677720?v=4"},"body":"By setting GIT_PS1_SHOW_COLORHINTS when using __git_ps1\nas PROMPT_COMMAND, you will get color hints in addition to\na different character (*+% etc.) to indicate the state of\nthe tree.\n\nSigned-off-by: Simon Oosthoek \n---\n contrib/completion/git-prompt.sh | 36 +++++++++++++++++++++++++++++++++++-\n 1 file changed, 35 insertions(+), 1 deletion(-)\n\ndiff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh\nindex 4fbc1e6..a693565 100644\n--- a/contrib/completion/git-prompt.sh\n+++ b/contrib/completion/git-prompt.sh\n@@ -53,6 +53,12 @@\n # find one, or @{upstream} otherwise. Once you have set\n # GIT_PS1_SHOWUPSTREAM, you can override it on a per-repository basis by\n # setting the bash.showUpstream config variable.\n+#\n+# If you would like a colored hint about the current dirty state, set\n+# GIT_PS1_SHOWCOLORHINTS to a nonempty value. When tracked files are\n+# modified, the branch name turns red, when all modifications are staged\n+# the branch name turns yellow and when all changes are checked in, the\n+# color changes to green. The colors are currently hardcoded in the function.\n \n # __gitdir accepts 0 or 1 arguments (i.e., location)\n # returns location of .git repo\n@@ -206,6 +212,7 @@ __git_ps1_show_upstream ()\n # in that case it _sets_ PS1. The arguments are parts of a PS1 string.\n # when both arguments are given, the first is prepended and the second appended\n # to the state string when assigned to PS1.\n+# In this mode you can request colored hints using GIT_PS1_SHOWCOLORHINTS=true\n __git_ps1 ()\n {\n \tlocal pcmode=no\n@@ -319,9 +326,36 @@ __git_ps1 ()\n \t\tlocal f=\"$w$i$s$u\"\n \t\tif [ $pcmode = yes ]; then\n \t\t\tPS1=\"$ps1pc_start(\"\n-\t\t\tPS1=\"$PS1$c${b##refs/heads/}${f:+ $f}$r$p\"\n+\t\t\tif [ -n \"${GIT_PS1_SHOWCOLORHINT-}\" ]; then\n+\t\t\t\tlocal c_red='\\e[31m'\n+\t\t\t\tlocal c_green='\\e[32m'\n+\t\t\t\tlocal c_yellow='\\e[33m'\n+\t\t\t\tlocal c_lblue='\\e[1;34m'\n+\t\t\t\tlocal c_purple='\\e[35m'\n+\t\t\t\tlocal c_cyan='\\e[36m'\n+\t\t\t\tlocal c_clear='\\e[0m'\n+\t\t\t\tlocal branchstring=\"$c${b##refs/heads/}\"\n+\t\t\t\tlocal branch_color=\"$c_green\"\n+\t\t\t\tlocal flags_color=\"$c_cyan\"\n+\n+\t\t\t\tif [ \"$w\" = \"*\" ]; then\n+\t\t\t\t\tbranch_color=\"$c_red\"\n+\t\t\t\telif [ -n \"$i\" ]; then\n+\t\t\t\t\tbranch_color=\"$c_yellow\"\n+\t\t\t\tfi\n+\n+\t\t\t\t# Setting PS1 directly with \\[ and \\] around colors\n+\t\t\t\t# is necessary to prevent wrapping issues!\n+\t\t\t\tPS1=\"$PS1\\[$branch_color\\]$branchstring\\[$c_clear\\]\"\n+\t\t\t\tif [ -n \"$f\" ]; then\n+\t\t\t\t\tPS1=\"$PS1 \\[$flags_color\\]$f\\[$c_clear\\]\"\n+\t\t\t\tfi\n+\t\t\telse\n+\t\t\t\tPS1=\"$PS1$c${b##refs/heads/}${f:+ $f}$r$p\"\n+\t\t\tfi\n \t\t\tPS1=\"$PS1)$ps1pc_end\"\n \t\telse\n+\t\t\t# NO color option unless in PROMPT_COMMAND mode\n \t\t\tprintf -- \"$printf_format\" \"$c${b##refs/heads/}${f:+ $f}$r$p\"\n \t\tfi\n \tfi\n-- \n1.7.9.5\n"},{"id":"200943","messageId":"20121010193750.GA7155@simaj.xs4all.nl","threadId":"31656","inReplyTo":"7v7gr0k6jv.fsf@alter.siamese.dyndns.org","subject":"[PATCH 1/2] Allow __git_ps1 to be used in PROMPT_COMMAND","fromName":"Simon Oosthoek","fromEmail":"s.oosthoek@xs4all.nl","sentAt":"2012-10-10T19:37:51Z","receivedAt":"2012-10-10T19:37:51Z","isPatch":true,"sender":{"key":"s.oosthoek@xs4all.nl","avatar":"https://avatars.githubusercontent.com/u/11677720?v=4"},"body":"Apologies if you receive this e-mail multiple times, my MTA was misconfigured...\n\n\nChanges __git_ps1 to allow its use as PROMPT_COMMAND in bash\nin addition to setting PS1 with __git_ps1 in a command substitution.\nPROMPT_COMMAND has advantages for using color without running\ninto prompt-wrapping issues. Only by assigning \\[ and \\] to PS1\ndirectly can bash know that these and the enclosed zero-width codes in\nbetween don't count in the length of the prompt.\n\nSigned-off-by: Simon Oosthoek \n---\n contrib/completion/git-prompt.sh | 51 +++++++++++++++++++++++++++++++++-----\n 1 file changed, 45 insertions(+), 6 deletions(-)\n\ndiff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh\nindex 29b1ec9..4fbc1e6 100644\n--- a/contrib/completion/git-prompt.sh\n+++ b/contrib/completion/git-prompt.sh\n@@ -10,9 +10,14 @@\n # 1) Copy this file to somewhere (e.g. ~/.git-prompt.sh).\n # 2) Add the following line to your .bashrc/.zshrc:\n # source ~/.git-prompt.sh\n-# 3) Change your PS1 to also show the current branch:\n-# Bash: PS1='[\\u@\\h \\W$(__git_ps1 \" (%s)\")]\\$ '\n-# ZSH: PS1='[%n@%m %c$(__git_ps1 \" (%s)\")]\\$ '\n+# 3a) In ~/.bashrc set PROMPT_COMMAND=__git_ps1\n+# To customize the prompt, provide start/end arguments\n+# PROMPT_COMMAND='__git_ps1 \"\\u@\\h:\\w\" \"\\\\\\$ \"'\n+# 3b) Alternatively change your PS1 to call __git_ps1 as\n+# command-substitution:\n+# Bash: PS1='[\\u@\\h \\W$(__git_ps1 \" (%s)\")]\\$ '\n+# ZSH: PS1='[%n@%m %c$(__git_ps1 \" (%s)\")]\\$ '\n+# the optional argument will be used as format string\n #\n # The argument to __git_ps1 will be displayed only if you are currently\n # in a git repository. The %s token will be the name of the current\n@@ -194,11 +199,39 @@ __git_ps1_show_upstream ()\n \n \n # __git_ps1 accepts 0 or 1 arguments (i.e., format string)\n-# returns text to add to bash PS1 prompt (includes branch name)\n+# when called from PS1 using command substitution\n+# in this mode it prints text to add to bash PS1 prompt (includes branch name)\n+#\n+# __git_ps1 requires 2 arguments when called from PROMPT_COMMAND (pc)\n+# in that case it _sets_ PS1. The arguments are parts of a PS1 string.\n+# when both arguments are given, the first is prepended and the second appended\n+# to the state string when assigned to PS1.\n __git_ps1 ()\n {\n+\tlocal pcmode=no\n+\t#defaults/examples:\n+\tlocal ps1pc_start='\\u@\\h:\\w '\n+\tlocal ps1pc_end='\\$ '\n+\tlocal printf_format='(%s)'\n+\n+\tcase \"$#\" in\n+\t\t2)\tpcmode=yes\n+\t\t\tps1pc_start=\"$1\"\n+\t\t\tps1pc_end=\"$2\"\n+\t\t;;\n+\t\t0|1)\tprintf_format=\"${1:-$printf_format}\"\n+\t\t;;\n+\t\t*)\treturn\n+\t\t;;\n+\tesac\n+\n \tlocal g=\"$(__gitdir)\"\n-\tif [ -n \"$g\" ]; then\n+\tif [ -z \"$g\" ]; then\n+\t\tif [ $pcmode = yes ]; then\n+\t\t\t#In PC mode PS1 always needs to be set\n+\t\t\tPS1=\"$ps1pc_start$ps1pc_end\"\n+\t\tfi\n+\telse\n \t\tlocal r=\"\"\n \t\tlocal b=\"\"\n \t\tif [ -f \"$g/rebase-merge/interactive\" ]; then\n@@ -284,6 +317,12 @@ __git_ps1 ()\n \t\tfi\n \n \t\tlocal f=\"$w$i$s$u\"\n-\t\tprintf -- \"${1:- (%s)}\" \"$c${b##refs/heads/}${f:+ $f}$r$p\"\n+\t\tif [ $pcmode = yes ]; then\n+\t\t\tPS1=\"$ps1pc_start(\"\n+\t\t\tPS1=\"$PS1$c${b##refs/heads/}${f:+ $f}$r$p\"\n+\t\t\tPS1=\"$PS1)$ps1pc_end\"\n+\t\telse\n+\t\t\tprintf -- \"$printf_format\" \"$c${b##refs/heads/}${f:+ $f}$r$p\"\n+\t\tfi\n \tfi\n }\n-- \n1.7.9.5\n"},{"id":"200944","messageId":"20121010193814.GA7186@simaj.xs4all.nl","threadId":"31656","inReplyTo":"7v7gr0k6jv.fsf@alter.siamese.dyndns.org","subject":"[PATCH 2/2] show color hints based on state of the git tree","fromName":"Simon Oosthoek","fromEmail":"s.oosthoek@xs4all.nl","sentAt":"2012-10-10T19:38:14Z","receivedAt":"2012-10-10T19:38:14Z","isPatch":true,"sender":{"key":"s.oosthoek@xs4all.nl","avatar":"https://avatars.githubusercontent.com/u/11677720?v=4"},"body":"By setting GIT_PS1_SHOW_COLORHINTS when using __git_ps1\nas PROMPT_COMMAND, you will get color hints in addition to\na different character (*+% etc.) to indicate the state of\nthe tree.\n\nSigned-off-by: Simon Oosthoek \n---\n contrib/completion/git-prompt.sh | 36 +++++++++++++++++++++++++++++++++++-\n 1 file changed, 35 insertions(+), 1 deletion(-)\n\ndiff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh\nindex 4fbc1e6..a693565 100644\n--- a/contrib/completion/git-prompt.sh\n+++ b/contrib/completion/git-prompt.sh\n@@ -53,6 +53,12 @@\n # find one, or @{upstream} otherwise. Once you have set\n # GIT_PS1_SHOWUPSTREAM, you can override it on a per-repository basis by\n # setting the bash.showUpstream config variable.\n+#\n+# If you would like a colored hint about the current dirty state, set\n+# GIT_PS1_SHOWCOLORHINTS to a nonempty value. When tracked files are\n+# modified, the branch name turns red, when all modifications are staged\n+# the branch name turns yellow and when all changes are checked in, the\n+# color changes to green. The colors are currently hardcoded in the function.\n \n # __gitdir accepts 0 or 1 arguments (i.e., location)\n # returns location of .git repo\n@@ -206,6 +212,7 @@ __git_ps1_show_upstream ()\n # in that case it _sets_ PS1. The arguments are parts of a PS1 string.\n # when both arguments are given, the first is prepended and the second appended\n # to the state string when assigned to PS1.\n+# In this mode you can request colored hints using GIT_PS1_SHOWCOLORHINTS=true\n __git_ps1 ()\n {\n \tlocal pcmode=no\n@@ -319,9 +326,36 @@ __git_ps1 ()\n \t\tlocal f=\"$w$i$s$u\"\n \t\tif [ $pcmode = yes ]; then\n \t\t\tPS1=\"$ps1pc_start(\"\n-\t\t\tPS1=\"$PS1$c${b##refs/heads/}${f:+ $f}$r$p\"\n+\t\t\tif [ -n \"${GIT_PS1_SHOWCOLORHINT-}\" ]; then\n+\t\t\t\tlocal c_red='\\e[31m'\n+\t\t\t\tlocal c_green='\\e[32m'\n+\t\t\t\tlocal c_yellow='\\e[33m'\n+\t\t\t\tlocal c_lblue='\\e[1;34m'\n+\t\t\t\tlocal c_purple='\\e[35m'\n+\t\t\t\tlocal c_cyan='\\e[36m'\n+\t\t\t\tlocal c_clear='\\e[0m'\n+\t\t\t\tlocal branchstring=\"$c${b##refs/heads/}\"\n+\t\t\t\tlocal branch_color=\"$c_green\"\n+\t\t\t\tlocal flags_color=\"$c_cyan\"\n+\n+\t\t\t\tif [ \"$w\" = \"*\" ]; then\n+\t\t\t\t\tbranch_color=\"$c_red\"\n+\t\t\t\telif [ -n \"$i\" ]; then\n+\t\t\t\t\tbranch_color=\"$c_yellow\"\n+\t\t\t\tfi\n+\n+\t\t\t\t# Setting PS1 directly with \\[ and \\] around colors\n+\t\t\t\t# is necessary to prevent wrapping issues!\n+\t\t\t\tPS1=\"$PS1\\[$branch_color\\]$branchstring\\[$c_clear\\]\"\n+\t\t\t\tif [ -n \"$f\" ]; then\n+\t\t\t\t\tPS1=\"$PS1 \\[$flags_color\\]$f\\[$c_clear\\]\"\n+\t\t\t\tfi\n+\t\t\telse\n+\t\t\t\tPS1=\"$PS1$c${b##refs/heads/}${f:+ $f}$r$p\"\n+\t\t\tfi\n \t\t\tPS1=\"$PS1)$ps1pc_end\"\n \t\telse\n+\t\t\t# NO color option unless in PROMPT_COMMAND mode\n \t\t\tprintf -- \"$printf_format\" \"$c${b##refs/heads/}${f:+ $f}$r$p\"\n \t\tfi\n \tfi\n-- \n1.7.9.5\n"},{"id":"200963","messageId":"7vlife9bkk.fsf@alter.siamese.dyndns.org","threadId":"31656","inReplyTo":"20121010193158.GA6454@simaj.xs4all.nl","subject":"Re: [PATCH 1/2] Allow __git_ps1 to be used in PROMPT_COMMAND","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-10-10T23:00:59Z","receivedAt":"2012-10-10T23:00:59Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Simon Oosthoek writes:\n\n> __git_ps1 ()\n> {\n> +\tlocal pcmode=no\n> +\t#defaults/examples:\n> +\tlocal ps1pc_start='\\u@\\h:\\w '\n> +\tlocal ps1pc_end='\\$ '\n> +\tlocal printf_format='(%s)'\n> + ...\n\nThis conversion is wrong, given that ...\n\n> @@ -284,6 +317,12 @@ __git_ps1 ()\n> \t\tfi\n> \n> \t\tlocal f=\"$w$i$s$u\"\n> -\t\tprintf -- \"${1:- (%s)}\" \"$c${b##refs/heads/}${f:+ $f}$r$p\"\n\n... the original has a SP in front. I've tentatively queued a\nfix-up patch on the topic branch before merging it to 'pu'.\n\n> +\t\tif [ $pcmode = yes ]; then\n> +\t\t\tPS1=\"$ps1pc_start(\"\n> +\t\t\tPS1=\"$PS1$c${b##refs/heads/}${f:+ $f}$r$p\"\n> +\t\t\tPS1=\"$PS1)$ps1pc_end\"\n> +\t\telse\n> +\t\t\tprintf -- \"$printf_format\" \"$c${b##refs/heads/}${f:+ $f}$r$p\"\n> +\t\tfi\n> \tfi\n> }\n"},{"id":"201234","messageId":"507BC7F1.3080506@drmicha.warpmail.net","threadId":"31656","inReplyTo":"20121005211030.GA5414@simaj.xs4all.nl","subject":"Re: [PATCH 2/2] show color hints based on state of the git tree","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2012-10-15T08:23:13Z","receivedAt":"2012-10-15T08:23:13Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Sorry for being late ($DAYJOB and such), but I just noticed this is on\nnext already:\n\nSimon Oosthoek venit, vidit, dixit 05.10.2012 23:10:\n> By setting GIT_PS1_SHOW_COLORHINTS when using __git_ps1\n> as PROMPT_COMMAND, you will get color hints in addition to\n> a different character (*+% etc.)\n> \n> Signed-off-by: Simon Oosthoek \n> ---\n> contrib/completion/git-prompt.sh | 42 +++++++++++++++++++++++++++++++++++---\n> 1 file changed, 39 insertions(+), 3 deletions(-)\n> \n> diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh\n> index c50c94a..51285d7 100644\n> --- a/contrib/completion/git-prompt.sh\n> +++ b/contrib/completion/git-prompt.sh\n> @@ -53,6 +53,12 @@\n> # find one, or @{upstream} otherwise. Once you have set\n> # GIT_PS1_SHOWUPSTREAM, you can override it on a per-repository basis by\n> # setting the bash.showUpstream config variable.\n> +#\n> +# If you would like a colored hint about the current dirty state, set\n> +# GIT_PS1_SHOWCOLORHINTS to a nonempty value. When tracked files are\n> +# modified, the branch name turns red, when all modifications are staged\n> +# the branch name turns yellow and when all changes are checked in, the\n> +# color changes to green. The colors are currently hardcoded in the function.\n> \n> # __gitdir accepts 0 or 1 arguments (i.e., location)\n> # returns location of .git repo\n> @@ -201,11 +207,12 @@ __git_ps1_show_upstream ()\n> # __git_ps1 accepts 0 or 1 arguments (i.e., format string)\n> # when called from PS1 using command substitution\n> # in this mode it returns text to add to bash PS1 prompt (includes branch name) or\n> -# __git_ps1 accepts 0 or 2 arguments when called from PROMPT_COMMAND\n> +# __git_ps1 accepts 0 or 2 arguments when called from PROMPT_COMMAND (pc)\n> # in that case it _sets_ PS1. The arguments are parts of a PS1 string.\n> # when both arguments are given, the first is prepended and the second appended\n> # to the state string when assigned to PS1, otherwise default start/end strings\n> # are used.\n> +# In pcmode you can request colored hints using GIT_PS1_SHOWCOLORHINTS=true\n> __git_ps1 ()\n> {\n> \tlocal pcmode=yes\n> @@ -320,8 +327,37 @@ __git_ps1 ()\n> \n> \t\tlocal f=\"$w$i$s$u\"\n> \t\tif [ $pcmode = yes ]; then\n> -\t\t\tPS1=\"$ps1pc_start($c${b##refs/heads/}${f:+ $f}$r$p)$ps1pc_end\"\n> -\t\telif [ $pcmode = no ]; then\n> +\t\t\tPS1=\"$ps1pc_start(\"\n> +\t\t\tif [ -n \"${GIT_PS1_SHOWCOLORHINT-}\" ]; then\n\nYou're missing the \"S\" here (HINTS).\n\n> +\t\t\t\tlocal c_red='\\e[31m'\n> +\t\t\t\tlocal c_green='\\e[32m'\n> +\t\t\t\tlocal c_yellow='\\e[33m'\n> +\t\t\t\tlocal c_lblue='\\e[1;34m'\n> +\t\t\t\tlocal c_purple='\\e[35m'\n> +\t\t\t\tlocal c_cyan='\\e[36m'\n> +\t\t\t\tlocal c_clear='\\e[0m'\n> +\t\t\t\tlocal branchstring=\"$c${b##refs/heads/}\"\n> +\t\t\t\tlocal branch_color=\"$c_green\"\n> +\t\t\t\tlocal flags_color=\"$c_cyan\"\n> +\n> +\t\t\t\tif [ \"$w\" = \"*\" ]; then\n> +\t\t\t\t\tbranch_color=\"$c_red\"\n> +\t\t\t\telif [ -n \"$i\" ]; then\n> +\t\t\t\t\tbranch_color=\"$c_yellow\"\n> +\t\t\t\tfi\n> +\n> +\t\t\t\t# Setting PS1 directly with \\[ and \\] around colors\n> +\t\t\t\t# is necessary to prevent wrapping issues!\n> +\t\t\t\tPS1=\"$PS1\\[$branch_color\\]$branchstring\\[$c_clear\\]\"\n> +\t\t\t\tif [ -n \"$f\" ]; then\n> +\t\t\t\t\tPS1=\"$PS1 \\[$flags_color\\]$f\\[$c_clear\\]\"\n> +\t\t\t\tfi\n> +\t\t\telse\n> +\t\t\t\tPS1=\"$PS1$c${b##refs/heads/}${f:+ $f}$r$p\"\n> +\t\t\tfi\n> +\t\t\tPS1=\"$PS1)$ps1pc_end\"\n> +\t\telse\n> +\t\t\t# NO color option unless in PROMPT_COMMAND mode\n> \t\t\tprintf -- \"${1:- (%s)}\" \"$c${b##refs/heads/}${f:+ $f}$r$p\"\n> \t\tfi\n> \tfi\n> \n\nI'm afraid I don't like this coloring style at all because it is\ninconsistent with the color usage of \"git status -sb\". First of all, the\ncolors are different, and second, the fact *what* is colored is\ndifferent. I had suggested following \"git status -sb\" for a good reason.\nIt colors a branch green and a detached head red. It colors \"change\"\n(A/D/M/R) as red/green depending on non-cached/cached, so that's how */+\nshould be. Your call for $/% (I'd leave them uncolored).[*][**]\n\nI think it's very confusing to have completely different schemes (not\njust themes) for two versions of the same information: concise status\ninformation.\n\nSo, please try and follow \"git status -sb\".\n\nMichael\n\n[*] Really, there's nothin \"red\" about a branch when there are cached or\nnon-cached changes. They are changes wrt. to what's in HEAD resp. the\nindex, no matter what HEAD is.\n\n[**] Also, coloring the status characters opens the way to even using\nthe same characters as \"status -sb\" (ADM).\n"},{"id":"201236","messageId":"507BD0EE.5000107@nieuwland.nl","threadId":"31656","inReplyTo":"507BC7F1.3080506@drmicha.warpmail.net","subject":"Re: [PATCH 2/2] show color hints based on state of the git tree","fromName":"Simon Oosthoek","fromEmail":"soosthoek@nieuwland.nl","sentAt":"2012-10-15T09:01:34Z","receivedAt":"2012-10-15T09:01:34Z","isPatch":true,"sender":{"key":"soosthoek@nieuwland.nl","avatar":null},"body":"On 10/15/2012 10:23 AM, Michael J Gruber wrote:\n> Sorry for being late ($DAYJOB and such), but I just noticed this is on\n> next already:\n>\n>> +\t\t\tif [ -n \"${GIT_PS1_SHOWCOLORHINT-}\" ]; then\n>\n> You're missing the \"S\" here (HINTS).\n\nindeed, well spotted!\nMy test setup was apparently configured without the S and the commented \nuses all had HINTS...\n\n\n>\n>> +\t\t\t\tlocal c_red='\\e[31m'\n>> +\t\t\t\tlocal c_green='\\e[32m'\n>> +\t\t\t\tlocal c_yellow='\\e[33m'\n>> +\t\t\t\tlocal c_lblue='\\e[1;34m'\n>> +\t\t\t\tlocal c_purple='\\e[35m'\n>> +\t\t\t\tlocal c_cyan='\\e[36m'\n>> +\t\t\t\tlocal c_clear='\\e[0m'\n>> +\t\t\t\tlocal branchstring=\"$c${b##refs/heads/}\"\n>> +\t\t\t\tlocal branch_color=\"$c_green\"\n>> +\t\t\t\tlocal flags_color=\"$c_cyan\"\n>> +\n>> +\t\t\t\tif [ \"$w\" = \"*\" ]; then\n>> +\t\t\t\t\tbranch_color=\"$c_red\"\n>> +\t\t\t\telif [ -n \"$i\" ]; then\n>> +\t\t\t\t\tbranch_color=\"$c_yellow\"\n>> +\t\t\t\tfi\n>> +\n>> +\t\t\t\t# Setting PS1 directly with \\[ and \\] around colors\n>> +\t\t\t\t# is necessary to prevent wrapping issues!\n>> +\t\t\t\tPS1=\"$PS1\\[$branch_color\\]$branchstring\\[$c_clear\\]\"\n>> +\t\t\t\tif [ -n \"$f\" ]; then\n>> +\t\t\t\t\tPS1=\"$PS1 \\[$flags_color\\]$f\\[$c_clear\\]\"\n>> +\t\t\t\tfi\n>> +\t\t\telse\n>> +\t\t\t\tPS1=\"$PS1$c${b##refs/heads/}${f:+ $f}$r$p\"\n>> +\t\t\tfi\n>> +\t\t\tPS1=\"$PS1)$ps1pc_end\"\n>> +\t\telse\n>> +\t\t\t# NO color option unless in PROMPT_COMMAND mode\n>> \t\t\tprintf -- \"${1:- (%s)}\" \"$c${b##refs/heads/}${f:+ $f}$r$p\"\n>> \t\tfi\n>> \tfi\n>>\n>\n> I'm afraid I don't like this coloring style at all because it is\n> inconsistent with the color usage of \"git status -sb\". First of all, the\n> colors are different, and second, the fact *what* is colored is\n> different. I had suggested following \"git status -sb\" for a good reason.\n> It colors a branch green and a detached head red. It colors \"change\"\n> (A/D/M/R) as red/green depending on non-cached/cached, so that's how */+\n> should be. Your call for $/% (I'd leave them uncolored).[*][**]\n\nThis way works for me. The coloring scheme itself is probably quite \npersonal and can, and probably should, be modified by end-users.\n(Whether the current code is suitable for user-modification is another \nmatter)\n\nI'm quite unfamiliar with the color coding of git (I hadn't enabled that \noption), I suppose consistency would be better, but then you'd have to \nadd some code to figure out which color is used for what in git's output \nand convert that to the code setting the colors here.\n\nAs for the characters used, I think there's a good reason not to use the \nones git uses in the prompt. The characters in git status output are put \nin front of the files they apply to, in the prompt you only get a \nsummarized output. And perhaps that argument could be extended to the \nuse of the colors as well, I prefer to know whether I have uncommitted \nchanges and in that category I want to know whether I already staged \nthem or not.\n\nIf I want to know which files are unstaged/uncommitted I do git status \nto see that.\n\n>\n> I think it's very confusing to have completely different schemes (not\n> just themes) for two versions of the same information: concise status\n> information.\n>\n> So, please try and follow \"git status -sb\".\n\nI think there are different levels of conciseness. And I see \"git status \n-sb\" uses green for staged modified files, which would be confusing to me.\n\n>\n> Michael\n>\n> [*] Really, there's nothin \"red\" about a branch when there are cached or\n> non-cached changes. They are changes wrt. to what's in HEAD resp. the\n> index, no matter what HEAD is.\n\nDo you mean that red (unstaged) and yellow (staged) are both \"red\" to you?\n\n>\n> [**] Also, coloring the status characters opens the way to even using\n> the same characters as \"status -sb\" (ADM).\n>\n\nPerhaps, but that would be confusing to me ;-)\n\nCheers\n\nSimon\n"},{"id":"201237","messageId":"507BD3C1.4040807@drmicha.warpmail.net","threadId":"31656","inReplyTo":"507BD0EE.5000107@nieuwland.nl","subject":"Re: [PATCH 2/2] show color hints based on state of the git tree","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2012-10-15T09:13:37Z","receivedAt":"2012-10-15T09:13:37Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Simon Oosthoek venit, vidit, dixit 15.10.2012 11:01:\n> On 10/15/2012 10:23 AM, Michael J Gruber wrote:\n>> Sorry for being late ($DAYJOB and such), but I just noticed this is on\n>> next already:\n>>\n>>> +\t\t\tif [ -n \"${GIT_PS1_SHOWCOLORHINT-}\" ]; then\n>>\n>> You're missing the \"S\" here (HINTS).\n> \n> indeed, well spotted!\n> My test setup was apparently configured without the S and the commented \n> uses all had HINTS...\n> \n> \n>>\n>>> +\t\t\t\tlocal c_red='\\e[31m'\n>>> +\t\t\t\tlocal c_green='\\e[32m'\n>>> +\t\t\t\tlocal c_yellow='\\e[33m'\n>>> +\t\t\t\tlocal c_lblue='\\e[1;34m'\n>>> +\t\t\t\tlocal c_purple='\\e[35m'\n>>> +\t\t\t\tlocal c_cyan='\\e[36m'\n>>> +\t\t\t\tlocal c_clear='\\e[0m'\n>>> +\t\t\t\tlocal branchstring=\"$c${b##refs/heads/}\"\n>>> +\t\t\t\tlocal branch_color=\"$c_green\"\n>>> +\t\t\t\tlocal flags_color=\"$c_cyan\"\n>>> +\n>>> +\t\t\t\tif [ \"$w\" = \"*\" ]; then\n>>> +\t\t\t\t\tbranch_color=\"$c_red\"\n>>> +\t\t\t\telif [ -n \"$i\" ]; then\n>>> +\t\t\t\t\tbranch_color=\"$c_yellow\"\n>>> +\t\t\t\tfi\n>>> +\n>>> +\t\t\t\t# Setting PS1 directly with \\[ and \\] around colors\n>>> +\t\t\t\t# is necessary to prevent wrapping issues!\n>>> +\t\t\t\tPS1=\"$PS1\\[$branch_color\\]$branchstring\\[$c_clear\\]\"\n>>> +\t\t\t\tif [ -n \"$f\" ]; then\n>>> +\t\t\t\t\tPS1=\"$PS1 \\[$flags_color\\]$f\\[$c_clear\\]\"\n>>> +\t\t\t\tfi\n>>> +\t\t\telse\n>>> +\t\t\t\tPS1=\"$PS1$c${b##refs/heads/}${f:+ $f}$r$p\"\n>>> +\t\t\tfi\n>>> +\t\t\tPS1=\"$PS1)$ps1pc_end\"\n>>> +\t\telse\n>>> +\t\t\t# NO color option unless in PROMPT_COMMAND mode\n>>> \t\t\tprintf -- \"${1:- (%s)}\" \"$c${b##refs/heads/}${f:+ $f}$r$p\"\n>>> \t\tfi\n>>> \tfi\n>>>\n>>\n>> I'm afraid I don't like this coloring style at all because it is\n>> inconsistent with the color usage of \"git status -sb\". First of all, the\n>> colors are different, and second, the fact *what* is colored is\n>> different. I had suggested following \"git status -sb\" for a good reason.\n>> It colors a branch green and a detached head red. It colors \"change\"\n>> (A/D/M/R) as red/green depending on non-cached/cached, so that's how */+\n>> should be. Your call for $/% (I'd leave them uncolored).[*][**]\n> \n> This way works for me. The coloring scheme itself is probably quite \n> personal and can, and probably should, be modified by end-users.\n> (Whether the current code is suitable for user-modification is another \n> matter)\n\nIt really doesn't matter much what works for you, and it doesn't matter\nwhat works for me either. The point is: What works for most users?\n\n> I'm quite unfamiliar with the color coding of git (I hadn't enabled that \n> option), I suppose consistency would be better, but then you'd have to \n> add some code to figure out which color is used for what in git's output \n> and convert that to the code setting the colors here.\n\nAs a starter, you could use the default colors which git uses. Querying\ngit for the colors could be the next, optional step.\n\n> As for the characters used, I think there's a good reason not to use the \n> ones git uses in the prompt. The characters in git status output are put \n> in front of the files they apply to, in the prompt you only get a \n> summarized output. And perhaps that argument could be extended to the \n> use of the colors as well, I prefer to know whether I have uncommitted \n> changes and in that category I want to know whether I already staged \n> them or not.\n\nWell, sure. The prompt could show any of AMCRD if you have any of those\nchanges. * + are shortcuts saying you have any of those.\n\n> If I want to know which files are unstaged/uncommitted I do git status \n> to see that.\n\nSure. I don't propose putting file names in the prompt ;)\n\n>>\n>> I think it's very confusing to have completely different schemes (not\n>> just themes) for two versions of the same information: concise status\n>> information.\n>>\n>> So, please try and follow \"git status -sb\".\n> \n> I think there are different levels of conciseness. And I see \"git status \n> -sb\" uses green for staged modified files, which would be confusing to me.\n\n...only because you don't know the color coding scheme. It's green\nbecause those changes are saved somewhere (in the index) and would even\nsurvice a branch switch.\n\n>> Michael\n>>\n>> [*] Really, there's nothin \"red\" about a branch when there are cached or\n>> non-cached changes. They are changes wrt. to what's in HEAD resp. the\n>> index, no matter what HEAD is.\n> \n> Do you mean that red (unstaged) and yellow (staged) are both \"red\" to you?\n\nNo, I said red for unstaged, green for staged for the characters, i.e. a\n* would always be red if present, a + always green if present.\n\nFor the \"branch name\", it would be red for detached head and green for\nchecked out branch.\n\n>> [**] Also, coloring the status characters opens the way to even using\n>> the same characters as \"status -sb\" (ADM).\n>>\n> \n> Perhaps, but that would be confusing to me ;-)\n\nIf that is case, you can try and propose changing that scheme...\n\nBut there's really a good reason for it. Cached (staged) changes are\n\"safe\" because they are saved in the index, and also they are \"good to\ngo into the next commit\", i.e. the commit traffic lights are green!\n\nMichael\n"},{"id":"201240","messageId":"507BE6B0.4020306@nieuwland.nl","threadId":"31656","inReplyTo":"507BD3C1.4040807@drmicha.warpmail.net","subject":"Re: [PATCH 2/2] show color hints based on state of the git tree","fromName":"Simon Oosthoek","fromEmail":"soosthoek@nieuwland.nl","sentAt":"2012-10-15T10:34:24Z","receivedAt":"2012-10-15T10:34:24Z","isPatch":true,"sender":{"key":"soosthoek@nieuwland.nl","avatar":null},"body":"On 10/15/2012 11:13 AM, Michael J Gruber wrote:\n>\n> It really doesn't matter much what works for you, and it doesn't matter\n> what works for me either. The point is: What works for most users?\n\nObviously, that was my point as well ;-)\n\n>> I'm quite unfamiliar with the color coding of git (I hadn't enabled that\n>> option), I suppose consistency would be better, but then you'd have to\n>> add some code to figure out which color is used for what in git's output\n>> and convert that to the code setting the colors here.\n>\n> As a starter, you could use the default colors which git uses. Querying\n> git for the colors could be the next, optional step.\n\nI suppose it would be a start.\n\nso how should it be?\n\nall committed: green branch, no characters\nonly staged changes: green branch, colored characters (yellow/red?)\nonly unstaged changes: red/yellow branch, colored characters (red)\nstaged and unstaged changes: red/yellow branch, multiple characters in \nred/yellow?)\ndetached head: red commit-sha1 (abbrev.), characters as above?\n\nWhat is the most useful thing to show in case of a detached head?\n-the commit hash of current head?\n-\"detached head\"\n\n\n>\n>> As for the characters used, I think there's a good reason not to use the\n>> ones git uses in the prompt. The characters in git status output are put\n>> in front of the files they apply to, in the prompt you only get a\n>> summarized output. And perhaps that argument could be extended to the\n>> use of the colors as well, I prefer to know whether I have uncommitted\n>> changes and in that category I want to know whether I already staged\n>> them or not.\n>\n> Well, sure. The prompt could show any of AMCRD if you have any of those\n> changes. * + are shortcuts saying you have any of those.\n\nHow do you suppose that should work?\nAdd another configuration parameter like GIT_PS1_SHOWSTATUSSBCHARS \n(please give a better suggestion ;-) or the other way around \nGIT_PS1_SHOWSTARPLUS (either of which could be the default)\n\n>>> I think it's very confusing to have completely different schemes (not\n>>> just themes) for two versions of the same information: concise status\n>>> information.\n>>>\n>>> So, please try and follow \"git status -sb\".\n>>\n>> I think there are different levels of conciseness. And I see \"git status\n>> -sb\" uses green for staged modified files, which would be confusing to me.\n>\n> ...only because you don't know the color coding scheme. It's green\n> because those changes are saved somewhere (in the index) and would even\n> survice a branch switch.\n\nI suppose you could see that as green (I usually view a yellow traffic \nlight as green as well ;-)\n\nIsn't it best practice to commit the staged changes ASAP? (But let's not \ndiverge in this thread to discuss best-practices, so consider that a \nrhetorical question for now ;-)\n\n> No, I said red for unstaged, green for staged for the characters, i.e. a\n> * would always be red if present, a + always green if present.\n>\n> For the \"branch name\", it would be red for detached head and green for\n> checked out branch.\n\nusing green for staged changes could be acceptable for me, but I'm \nslightly worried that a colored character would be too slight a hint.\n\nOTOH, a detached head would show up with or without color...\n\n>\n>> Perhaps, but that would be confusing to me ;-)\n>\n> If that is case, you can try and propose changing that scheme...\n>\n> But there's really a good reason for it. Cached (staged) changes are\n> \"safe\" because they are saved in the index, and also they are \"good to\n> go into the next commit\", i.e. the commit traffic lights are green!\n\nI suppose I knew that in the back of my mind, but not as clearly as you \nspell it out here... Tnx!\n\n/Simon\n"},{"id":"201255","messageId":"507C0D81.7030005@nieuwland.nl","threadId":"31656","inReplyTo":"507BD3C1.4040807@drmicha.warpmail.net","subject":"Re: [PATCH 2/2] show color hints based on state of the git tree","fromName":"Simon Oosthoek","fromEmail":"soosthoek@nieuwland.nl","sentAt":"2012-10-15T13:20:01Z","receivedAt":"2012-10-15T13:20:01Z","isPatch":true,"sender":{"key":"soosthoek@nieuwland.nl","avatar":null},"body":"Hi Michael, sorry for the duplicate, forgot to reply-all...\n\nOn 10/15/2012 11:13 AM, Michael J Gruber wrote:\n\n> ...only because you don't know the color coding scheme. It's green\n> because those changes are saved somewhere (in the index) and would even\n> survice a branch switch.\n>\n\nBut git doesn't exactly let you do this:\nI modified some things in git-prompt.sh trying to implement some of what \nwe discussed. Then staged the file and tried git checkout HEAD^^ (or any \nbranch)\n\nerror: Your local changes to the following files would be overwritten by \ncheckout:\n contrib/completion/git-prompt.sh\nPlease, commit your changes or stash them before you can switch branches.\nAborting\n\nSo I don't think it's all that strange to mark the branch as not quite \nsafe to change. The idea (or at least my idea) behind these hints is \nthat it reminds me to do stuff that prevents these \"Aborts\". I think \nthat that is a useful feature for any user of git.\n\nIn this light, would you accept yellow in the branch color to indicate \nuncommitted staged changes?\n\nCheers\n\nSimon\n"},{"id":"201260","messageId":"507C2882.2090406@nieuwland.nl","threadId":"31656","inReplyTo":"CAPc5daVUyAuznmrT+-yqvPR0gd38oiWmi2k+BFVV1s9ouMUt0Q@mail.gmail.com","subject":"Re: [PATCH 2/2] show color hints based on state of the git tree","fromName":"Simon Oosthoek","fromEmail":"soosthoek@nieuwland.nl","sentAt":"2012-10-15T15:15:14Z","receivedAt":"2012-10-15T15:15:14Z","isPatch":true,"sender":{"key":"soosthoek@nieuwland.nl","avatar":null},"body":"On 10/15/2012 11:39 AM, Junio C Hamano wrote:\n> Thanks for bringing some sanity to the color of the bikeshed ;-)\n>\n> As I don't use colors very much, I didn't bother checking the color\n> assignment in the patch in question, but everything you said in your\n> response makes 100% sense, including the traffic light analogy.\n>\n\nHi Junio, Michael\n\nThe point of the thread and the patch was to enable the possibility of \ncolors in the prompt without messing it up.\n\nThe actual colors used are more or less how I'm used to it, but as you \nsaid they may not be suitable to everyone.\n\n@Junio, is this patch something you want to include as it is now (with \nthe extra S that Michael pointed out) or do you want to wait for a \ndiscussion about which colors to use for which state?\n\nI guess it could be quite a messy discussion, as you already hint at \nbikeshed colors, it's quite personal and subjective.\n\nAs a start, I think it's worth considering what the color would actually \nmean.\n\nTo me:\nA neutral color should mean it's safe to switch branches or merge/update\nA non-neutral color would mean some action is required before switching \nbranches.\nThere are various states that may or may not get in the way of \nswitching, like stashed stuff or divergence from upstream. I think these \ncould get a color hint, but I'm not sure what kind.\n\nCheers\n\nSimon\n"},{"id":"201261","messageId":"507C297D.3040304@drmicha.warpmail.net","threadId":"31656","inReplyTo":"507C0D81.7030005@nieuwland.nl","subject":"Re: [PATCH 2/2] show color hints based on state of the git tree","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2012-10-15T15:19:25Z","receivedAt":"2012-10-15T15:19:25Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Simon Oosthoek venit, vidit, dixit 15.10.2012 15:20:\n> Hi Michael, sorry for the duplicate, forgot to reply-all...\n> \n> On 10/15/2012 11:13 AM, Michael J Gruber wrote:\n> \n>> ...only because you don't know the color coding scheme. It's green\n>> because those changes are saved somewhere (in the index) and would even\n>> survice a branch switch.\n>>\n> \n> But git doesn't exactly let you do this:\n> I modified some things in git-prompt.sh trying to implement some of what \n> we discussed. Then staged the file and tried git checkout HEAD^^ (or any \n> branch)\n> \n> error: Your local changes to the following files would be overwritten by \n> checkout:\n> contrib/completion/git-prompt.sh\n> Please, commit your changes or stash them before you can switch branches.\n> Aborting\n> \n> So I don't think it's all that strange to mark the branch as not quite \n> safe to change. The idea (or at least my idea) behind these hints is \n> that it reminds me to do stuff that prevents these \"Aborts\". I think \n> that that is a useful feature for any user of git.\n> \n> In this light, would you accept yellow in the branch color to indicate \n> uncommitted staged changes?\n\nNo, simply because it's not up to me to accept something ;)\n\nI still think that following \"git status -sb\" would be the least\nconfusing solution, and that means\n\n- green for a checked out branch, where you know that any committed\nchanges will not be \"lost\"\n- red for a detached head, where any committed changes will only be\naccessible from the reflog, and only until pruned.\n\nI'm open to change \"git status -sb\", but I think having the branch\ncoloring and the status character coloring be independent has quite some\nmerit. (Your yellow branch just duplicates the information \"there are\nstaged changes\".)\n\nAlso note that in your example above, you cannot switch branches because\nyour staged changes overlap with the changes in the branch that you want\nto switch to (changes relative to your current head). Otherwise, you\ncould have switched. The only way to find out whether there's such a\nconflict is to actually try it, and that is too heavy for a prompt command.\n\nMichael\n"},{"id":"201279","messageId":"7vlif7wqqb.fsf@alter.siamese.dyndns.org","threadId":"31656","inReplyTo":"507C2882.2090406@nieuwland.nl","subject":"Re: [PATCH 2/2] show color hints based on state of the git tree","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-10-15T18:10:52Z","receivedAt":"2012-10-15T18:10:52Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Simon Oosthoek writes:\n\n> The point of the thread and the patch was to enable the possibility of\n> colors in the prompt without messing it up.\n>\n> The actual colors used are more or less how I'm used to it, but as you\n> said they may not be suitable to everyone.\n>\n> @Junio, is this patch something you want to include as it is now (with\n> the extra S that Michael pointed out) or do you want to wait for a\n> discussion about which colors to use for which state?\n\nThe latter.\n\n> I guess it could be quite a messy discussion, as you already hint at\n> bikeshed colors, it's quite personal and subjective.\n\nThe choice of colours may be subjective, but you can just omit that\npart, if there is already an existing choice made by others in\nearlier changes like in \"status\" output. As long as the subjective\nchoices in two systems that show similar information are consistent,\nexact choice of colours does not matter that much.\n"},{"id":"201311","messageId":"20121016053257.GA8366@simaj.xs4all.nl","threadId":"31656","inReplyTo":"7vlif7wqqb.fsf@alter.siamese.dyndns.org","subject":"[PATCH 3/3] Change colors to be based on git status -sb in color mode","fromName":"Simon Oosthoek","fromEmail":"s.oosthoek@xs4all.nl","sentAt":"2012-10-16T05:32:57Z","receivedAt":"2012-10-16T05:32:57Z","isPatch":true,"sender":{"key":"s.oosthoek@xs4all.nl","avatar":"https://avatars.githubusercontent.com/u/11677720?v=4"},"body":"Hi\n\nthis patch is an additional patch to the previous series of two. It also\ncorrects the missing S and some minor details. The main point of this\none is changing the used colors to be more close to the color output of \"git\nstatus -sb\" Mainly, the branchname stays green until it loses a HEAD, in\ndetached head state it becomes red.\nThe flags get their own color, either red or green for unstaged/staged and the\nremaining flags get a different color or none at all.\n\nCheers\n\nSimon\n\nThe color in the prompt now follows the colors used by\ngit itself when showing colors. The branch name is only\ncolored red if the tree has a detached HEAD.\n\nSigned-off-by: Simon Oosthoek \n---\n contrib/completion/git-prompt.sh | 52 ++++++++++++++++++++++----------------\n 1 file changed, 30 insertions(+), 22 deletions(-)\n\ndiff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh\nindex 4fb998a..ff69bbc 100644\n--- a/contrib/completion/git-prompt.sh\n+++ b/contrib/completion/git-prompt.sh\n@@ -55,11 +55,9 @@\n # setting the bash.showUpstream config variable.\n #\n # If you would like a colored hint about the current dirty state, set\n-# GIT_PS1_SHOWCOLORHINTS to a nonempty value. When tracked files are\n-# modified, the branch name turns red, when all modifications are staged\n-# the branch name turns yellow and when all changes are checked in, the\n-# color changes to green. The colors are currently hardcoded in the function.\n-\n+# GIT_PS1_SHOWCOLORHINTS to a nonempty value. The colors are based on \n+# the colored output of \"git status -sb\".\n+#\n # __gitdir accepts 0 or 1 arguments (i.e., location)\n # returns location of .git repo\n __gitdir ()\n@@ -325,35 +323,45 @@ __git_ps1 ()\n \n \t\tlocal f=\"$w$i$s$u\"\n \t\tif [ $pcmode = yes ]; then\n-\t\t\tPS1=\"$ps1pc_start(\"\n-\t\t\tif [ -n \"${GIT_PS1_SHOWCOLORHINT-}\" ]; then\n+\t\t\tif [ -n \"${GIT_PS1_SHOWCOLORHINTS-}\" ]; then\n \t\t\t\tlocal c_red='\\e[31m'\n \t\t\t\tlocal c_green='\\e[32m'\n-\t\t\t\tlocal c_yellow='\\e[33m'\n \t\t\t\tlocal c_lblue='\\e[1;34m'\n-\t\t\t\tlocal c_purple='\\e[35m'\n-\t\t\t\tlocal c_cyan='\\e[36m'\n \t\t\t\tlocal c_clear='\\e[0m'\n \t\t\t\tlocal branchstring=\"$c${b##refs/heads/}\"\n-\t\t\t\tlocal branch_color=\"$c_green\"\n-\t\t\t\tlocal flags_color=\"$c_cyan\"\n+\t\t\t\tlocal branch_color=\"$c_clear\"\n+\t\t\t\tlocal flags_color=\"$c_lblue\"\n \n-\t\t\t\tif [ \"$w\" = \"*\" ]; then\n-\t\t\t\t\tbranch_color=\"$c_red\"\n-\t\t\t\telif [ -n \"$i\" ]; then\n-\t\t\t\t\tbranch_color=\"$c_yellow\"\n-\t\t\t\tfi\n+\t\t\t\tcase \"$b\" in \n+\t\t\t\t\t\\(*\\))\tbranch_color=\"$c_red\"\n+\t\t\t\t\t;;\n+\t\t\t\t\t*)\tlocal branch_color=\"$c_green\"\n+\t\t\t\t\t;;\n+\t\t\t\tesac\n \n \t\t\t\t# Setting PS1 directly with \\[ and \\] around colors\n \t\t\t\t# is necessary to prevent wrapping issues!\n-\t\t\t\tPS1=\"$PS1\\[$branch_color\\]$branchstring\\[$c_clear\\]\"\n-\t\t\t\tif [ -n \"$f\" ]; then\n-\t\t\t\t\tPS1=\"$PS1 \\[$flags_color\\]$f\\[$c_clear\\]\"\n+\t\t\t\tPS1=\"$ps1pc_start (\\[$branch_color\\]$branchstring\\[$c_clear\\]\"\n+\n+\t\t\t\tif [ -n \"$w$i$s$u$r$p\" ]; then\n+\t\t\t\t\tPS1=\"$PS1 \"\n+\t\t\t\tfi\n+\t\t\t\tif [ \"$w\" = \"*\" ]; then\n+\t\t\t\t\tPS1=\"$PS1\\[$c_red\\]$w\"\n+\t\t\t\tfi\n+\t\t\t\tif [ -n \"$i\" ]; then\n+\t\t\t\t\tPS1=\"$PS1\\[$c_green\\]$i\"\n+\t\t\t\tfi\n+\t\t\t\tif [ -n \"$s\" ]; then\n+\t\t\t\t\tPS1=\"$PS1\\[$flags_color\\]$s\"\n+\t\t\t\tfi\n+\t\t\t\tif [ -n \"$u\" ]; then\n+\t\t\t\t\tPS1=\"$PS1\\[$c_red\\]$u\"\n \t\t\t\tfi\n+\t\t\t\tPS1=\"$PS1\\[$c_clear\\]$r$p)$ps1pc_end\"\n \t\t\telse\n-\t\t\t\tPS1=\"$PS1$c${b##refs/heads/}${f:+ $f}$r$p\"\n+\t\t\t\tPS1=\"$ps1pc_start ($c${b##refs/heads/}${f:+ $f}$r$p)$ps1pc_end\"\n \t\t\tfi\n-\t\t\tPS1=\"$PS1)$ps1pc_end\"\n \t\telse\n \t\t\t# NO color option unless in PROMPT_COMMAND mode\n \t\t\tprintf -- \"$printf_format\" \"$c${b##refs/heads/}${f:+ $f}$r$p\"\n-- \n1.7.9.5\n"},{"id":"201348","messageId":"7vvceatnn4.fsf@alter.siamese.dyndns.org","threadId":"31656","inReplyTo":"20121016053257.GA8366@simaj.xs4all.nl","subject":"Re: [PATCH 3/3] Change colors to be based on git status -sb in color mode","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-10-16T15:58:07Z","receivedAt":"2012-10-16T15:58:07Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Simon Oosthoek writes:\n\n> this patch is an additional patch to the previous series of two.\n\n\n> @@ -325,35 +323,45 @@ __git_ps1 ()\n> \n> \t\tlocal f=\"$w$i$s$u\"\n> \t\tif [ $pcmode = yes ]; then\n> +\t\t\tif [ -n \"${GIT_PS1_SHOWCOLORHINTS-}\" ]; then\n> \t\t\t\tlocal c_red='\\e[31m'\n> \t\t\t\tlocal c_green='\\e[32m'\n> \t\t\t\tlocal c_lblue='\\e[1;34m'\n> \t\t\t\tlocal c_clear='\\e[0m'\n> \t\t\t\tlocal branchstring=\"$c${b##refs/heads/}\"\n> +\t\t\t\tlocal branch_color=\"$c_clear\"\n> +\t\t\t\tlocal flags_color=\"$c_lblue\"\n> \n> +\t\t\t\tcase \"$b\" in \n> +\t\t\t\t\t\\(*\\))\tbranch_color=\"$c_red\"\n> +\t\t\t\t\t;;\n> +\t\t\t\t\t*)\tlocal branch_color=\"$c_green\"\n> +\t\t\t\t\t;;\n> +\t\t\t\tesac\n\nWhy \"local\" only on one side and not the other?\n\nAlso switching on \"$b\" and relying on how it happens to be formatted\ninside parentheses when detached (which can very well change in the\nfuture) looks like a fragile bug waiting to be triggered.\n\n> \t\t\t\t# Setting PS1 directly with \\[ and \\] around colors\n> \t\t\t\t# is necessary to prevent wrapping issues!\n> +\t\t\t\tPS1=\"$ps1pc_start (\\[$branch_color\\]$branchstring\\[$c_clear\\]\"\n> +\n> +\t\t\t\tif [ -n \"$w$i$s$u$r$p\" ]; then\n> +\t\t\t\t\tPS1=\"$PS1 \"\n> +\t\t\t\tfi\n> +\t\t\t\tif [ \"$w\" = \"*\" ]; then\n> +\t\t\t\t\tPS1=\"$PS1\\[$c_red\\]$w\"\n> +\t\t\t\tfi\n> +\t\t\t\tif [ -n \"$i\" ]; then\n> +\t\t\t\t\tPS1=\"$PS1\\[$c_green\\]$i\"\n> +\t\t\t\tfi\n\nYou gave nice symbolic names to branch_color and flags_color, but\nthese two use hardcoded colors?\n"},{"id":"201385","messageId":"20121016193405.GA12073@simaj.xs4all.nl","threadId":"31656","inReplyTo":"7vvceatnn4.fsf@alter.siamese.dyndns.org","subject":"[PATCH 3/3] Change colors to be based on git status -sb in color mode","fromName":"Simon Oosthoek","fromEmail":"s.oosthoek@xs4all.nl","sentAt":"2012-10-16T19:34:05Z","receivedAt":"2012-10-16T19:34:05Z","isPatch":true,"sender":{"key":"s.oosthoek@xs4all.nl","avatar":"https://avatars.githubusercontent.com/u/11677720?v=4"},"body":"Hi\n\nFixed the mistakes of the last one, and I'm now using the symbolic names \"ok_color\" and \"bad_color\".\nThe test for headless state is now more direct, and I hope it is still correct.\n\n/Simon\n\n\nthis patch is an additional patch to the previous series of two. It also\ncorrects the missing S and some minor details. The main point of this\none is changing the used colors to be more close to the color output of \"git\nstatus -sb\" Mainly, the branchname stays green until it loses a HEAD, in\ndetached head state it becomes red.\nThe flags get their own color, either red or green for unstaged/staged and the\nremaining flags get a different color or none at all.\n\nSigned-off-by: Simon Oosthoek \n---\n contrib/completion/git-prompt.sh | 52 +++++++++++++++++++++++---------------\n 1 file changed, 31 insertions(+), 21 deletions(-)\n\ndiff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh\nindex 4fb998a..7dce319 100644\n--- a/contrib/completion/git-prompt.sh\n+++ b/contrib/completion/git-prompt.sh\n@@ -55,11 +55,9 @@\n # setting the bash.showUpstream config variable.\n #\n # If you would like a colored hint about the current dirty state, set\n-# GIT_PS1_SHOWCOLORHINTS to a nonempty value. When tracked files are\n-# modified, the branch name turns red, when all modifications are staged\n-# the branch name turns yellow and when all changes are checked in, the\n-# color changes to green. The colors are currently hardcoded in the function.\n-\n+# GIT_PS1_SHOWCOLORHINTS to a nonempty value. The colors are based on \n+# the colored output of \"git status -sb\".\n+#\n # __gitdir accepts 0 or 1 arguments (i.e., location)\n # returns location of .git repo\n __gitdir ()\n@@ -325,35 +323,47 @@ __git_ps1 ()\n \n \t\tlocal f=\"$w$i$s$u\"\n \t\tif [ $pcmode = yes ]; then\n-\t\t\tPS1=\"$ps1pc_start(\"\n-\t\t\tif [ -n \"${GIT_PS1_SHOWCOLORHINT-}\" ]; then\n+\t\t\tif [ -n \"${GIT_PS1_SHOWCOLORHINTS-}\" ]; then\n \t\t\t\tlocal c_red='\\e[31m'\n \t\t\t\tlocal c_green='\\e[32m'\n-\t\t\t\tlocal c_yellow='\\e[33m'\n \t\t\t\tlocal c_lblue='\\e[1;34m'\n-\t\t\t\tlocal c_purple='\\e[35m'\n-\t\t\t\tlocal c_cyan='\\e[36m'\n \t\t\t\tlocal c_clear='\\e[0m'\n+\t\t\t\tlocal bad_color=$c_red\n+\t\t\t\tlocal ok_color=$c_green\n+\t\t\t\tlocal branch_color=\"$c_clear\"\n+\t\t\t\tlocal flags_color=\"$c_lblue\"\n \t\t\t\tlocal branchstring=\"$c${b##refs/heads/}\"\n-\t\t\t\tlocal branch_color=\"$c_green\"\n-\t\t\t\tlocal flags_color=\"$c_cyan\"\n \n-\t\t\t\tif [ \"$w\" = \"*\" ]; then\n-\t\t\t\t\tbranch_color=\"$c_red\"\n-\t\t\t\telif [ -n \"$i\" ]; then\n-\t\t\t\t\tbranch_color=\"$c_yellow\"\n+\t\t\t\tif git symbolic-ref HEAD 2>/dev/null 1>&2\n+\t\t\t\tthen\n+\t\t\t\t\tbranch_color=\"$ok_color\"\n+\t\t\t\telse\n+\t\t\t\t\tbranch_color=\"$bad_color\"\n \t\t\t\tfi\n \n \t\t\t\t# Setting PS1 directly with \\[ and \\] around colors\n \t\t\t\t# is necessary to prevent wrapping issues!\n-\t\t\t\tPS1=\"$PS1\\[$branch_color\\]$branchstring\\[$c_clear\\]\"\n-\t\t\t\tif [ -n \"$f\" ]; then\n-\t\t\t\t\tPS1=\"$PS1 \\[$flags_color\\]$f\\[$c_clear\\]\"\n+\t\t\t\tPS1=\"$ps1pc_start (\\[$branch_color\\]$branchstring\\[$c_clear\\]\"\n+\n+\t\t\t\tif [ -n \"$w$i$s$u$r$p\" ]; then\n+\t\t\t\t\tPS1=\"$PS1 \"\n+\t\t\t\tfi\n+\t\t\t\tif [ \"$w\" = \"*\" ]; then\n+\t\t\t\t\tPS1=\"$PS1\\[$bad_color\\]$w\"\n+\t\t\t\tfi\n+\t\t\t\tif [ -n \"$i\" ]; then\n+\t\t\t\t\tPS1=\"$PS1\\[$ok_color\\]$i\"\n+\t\t\t\tfi\n+\t\t\t\tif [ -n \"$s\" ]; then\n+\t\t\t\t\tPS1=\"$PS1\\[$flags_color\\]$s\"\n+\t\t\t\tfi\n+\t\t\t\tif [ -n \"$u\" ]; then\n+\t\t\t\t\tPS1=\"$PS1\\[$bad_color\\]$u\"\n \t\t\t\tfi\n+\t\t\t\tPS1=\"$PS1\\[$c_clear\\]$r$p)$ps1pc_end\"\n \t\t\telse\n-\t\t\t\tPS1=\"$PS1$c${b##refs/heads/}${f:+ $f}$r$p\"\n+\t\t\t\tPS1=\"$ps1pc_start ($c${b##refs/heads/}${f:+ $f}$r$p)$ps1pc_end\"\n \t\t\tfi\n-\t\t\tPS1=\"$PS1)$ps1pc_end\"\n \t\telse\n \t\t\t# NO color option unless in PROMPT_COMMAND mode\n \t\t\tprintf -- \"$printf_format\" \"$c${b##refs/heads/}${f:+ $f}$r$p\"\n-- \n1.7.9.5\n"},{"id":"201390","messageId":"7vtxtuqf3z.fsf@alter.siamese.dyndns.org","threadId":"31656","inReplyTo":"20121016193405.GA12073@simaj.xs4all.nl","subject":"Re: [PATCH 3/3] Change colors to be based on git status -sb in color mode","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-10-16T21:30:40Z","receivedAt":"2012-10-16T21:30:40Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Simon Oosthoek writes:\n\n> Hi\n>\n> Fixed the mistakes of the last one, and I'm now using the symbolic names \"ok_color\" and \"bad_color\".\n> The test for headless state is now more direct, and I hope it is still correct.\n>\n> /Simon\n\nWill apply with a bit more readable log message.\n\nI think it would be a good idea to squash something like the\nattached into this patch, though.\n\n contrib/completion/git-prompt.sh | 7 +++----\n 1 file changed, 3 insertions(+), 4 deletions(-)\n\ndiff --git i/contrib/completion/git-prompt.sh w/contrib/completion/git-prompt.sh\nindex dced628..9f0b6bb 100644\n--- i/contrib/completion/git-prompt.sh\n+++ w/contrib/completion/git-prompt.sh\n@@ -215,7 +215,7 @@ __git_ps1_show_upstream ()\n __git_ps1 ()\n {\n \tlocal pcmode=no\n-\t#defaults/examples:\n+\tlocal detached=no\n \tlocal ps1pc_start='\\u@\\h:\\w '\n \tlocal ps1pc_end='\\$ '\n \tlocal printf_format=' (%s)'\n@@ -264,7 +264,7 @@ __git_ps1 ()\n \t\t\tfi\n \n \t\t\tb=\"$(git symbolic-ref HEAD 2>/dev/null)\" || {\n-\n+\t\t\t\tdetached=yes\n \t\t\t\tb=\"$(\n \t\t\t\tcase \"${GIT_PS1_DESCRIBE_STYLE-}\" in\n \t\t\t\t(contains)\n@@ -335,8 +335,7 @@ __git_ps1 ()\n \t\t\t\tlocal flags_color=\"$c_lblue\"\n \t\t\t\tlocal branchstring=\"$c${b##refs/heads/}\"\n \n-\t\t\t\tif git symbolic-ref HEAD 2>/dev/null 1>&2\n-\t\t\t\tthen\n+\t\t\t\tif [ $detached = yes ]; then\n \t\t\t\t\tbranch_color=\"$ok_color\"\n \t\t\t\telse\n \t\t\t\t\tbranch_color=\"$bad_color\"\n"},{"id":"201391","messageId":"7vhapuqdit.fsf@alter.siamese.dyndns.org","threadId":"31656","inReplyTo":"7vtxtuqf3z.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 3/3] Change colors to be based on git status -sb in color mode","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-10-16T22:04:58Z","receivedAt":"2012-10-16T22:04:58Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Simon Oosthoek writes:\n>\n>> Hi\n>>\n>> Fixed the mistakes of the last one, and I'm now using the symbolic names \"ok_color\" and \"bad_color\".\n>> The test for headless state is now more direct, and I hope it is still correct.\n>>\n>> /Simon\n>\n> Will apply with a bit more readable log message.\n>\n> I think it would be a good idea to squash something like the\n> attached into this patch, though.\n\nThe reason for this suggestion is not to avoid running symbolic-ref\ntwice (which is a good side effect, though). When you are in the\nmiddle of bisection or multi-commit cherry-pick, for example, you\nwould conceptually be working on the original branch, but the HEAD\npointer may be detached. Earlier parts of the existing code in the\nfunction makes this distinction, and the same distinction should be\ncarried over to the new code that decides the color to paint things\nin.\n\n> contrib/completion/git-prompt.sh | 7 +++----\n> 1 file changed, 3 insertions(+), 4 deletions(-)\n>\n> diff --git i/contrib/completion/git-prompt.sh w/contrib/completion/git-prompt.sh\n> index dced628..9f0b6bb 100644\n> --- i/contrib/completion/git-prompt.sh\n> +++ w/contrib/completion/git-prompt.sh\n> @@ -215,7 +215,7 @@ __git_ps1_show_upstream ()\n> __git_ps1 ()\n> {\n> \tlocal pcmode=no\n> -\t#defaults/examples:\n> +\tlocal detached=no\n> \tlocal ps1pc_start='\\u@\\h:\\w '\n> \tlocal ps1pc_end='\\$ '\n> \tlocal printf_format=' (%s)'\n> @@ -264,7 +264,7 @@ __git_ps1 ()\n> \t\t\tfi\n> \n> \t\t\tb=\"$(git symbolic-ref HEAD 2>/dev/null)\" || {\n> -\n> +\t\t\t\tdetached=yes\n> \t\t\t\tb=\"$(\n> \t\t\t\tcase \"${GIT_PS1_DESCRIBE_STYLE-}\" in\n> \t\t\t\t(contains)\n> @@ -335,8 +335,7 @@ __git_ps1 ()\n> \t\t\t\tlocal flags_color=\"$c_lblue\"\n> \t\t\t\tlocal branchstring=\"$c${b##refs/heads/}\"\n> \n> -\t\t\t\tif git symbolic-ref HEAD 2>/dev/null 1>&2\n> -\t\t\t\tthen\n> +\t\t\t\tif [ $detached = yes ]; then\n> \t\t\t\t\tbranch_color=\"$ok_color\"\n> \t\t\t\telse\n> \t\t\t\t\tbranch_color=\"$bad_color\"\n"},{"id":"201407","messageId":"507E5B98.2020006@xs4all.nl","threadId":"31656","inReplyTo":"7vtxtuqf3z.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 3/3] Change colors to be based on git status -sb in color mode","fromName":"Simon Oosthoek","fromEmail":"s.oosthoek@xs4all.nl","sentAt":"2012-10-17T07:17:44Z","receivedAt":"2012-10-17T07:17:44Z","isPatch":true,"sender":{"key":"s.oosthoek@xs4all.nl","avatar":"https://avatars.githubusercontent.com/u/11677720?v=4"},"body":"On 16/10/12 23:30, Junio C Hamano wrote:\n> Simon Oosthoek writes:\n> \n>> Hi\n>>\n>> Fixed the mistakes of the last one, and I'm now using the symbolic names \"ok_color\" and \"bad_color\".\n>> The test for headless state is now more direct, and I hope it is still correct.\n>>\n>> /Simon\n> \n> Will apply with a bit more readable log message.\n\nOk\n\n> \n> I think it would be a good idea to squash something like the\n> attached into this patch, though.\n\nI tried the patch and it works when you switch the color assignments in\nthe if statement you added...\n\n> @@ -264,7 +264,7 @@ __git_ps1 ()\n> \t\t\tfi\n> \n> \t\t\tb=\"$(git symbolic-ref HEAD 2>/dev/null)\" || {\n> -\n> +\t\t\t\tdetached=yes\n> \t\t\t\tb=\"$(\n> \t\t\t\tcase \"${GIT_PS1_DESCRIBE_STYLE-}\" in\n> \t\t\t\t(contains)\n> @@ -335,8 +335,7 @@ __git_ps1 ()\n> \t\t\t\tlocal flags_color=\"$c_lblue\"\n> \t\t\t\tlocal branchstring=\"$c${b##refs/heads/}\"\n> \n> -\t\t\t\tif git symbolic-ref HEAD 2>/dev/null 1>&2\n> -\t\t\t\tthen\n> +\t\t\t\tif [ $detached = yes ]; then\n- \t\t\t\t\tbranch_color=\"$ok_color\"\n+ \t\t\t\t\tbranch_color=\"$bad_color\"\n> \t\t\t\telse\n- \t\t\t\t\tbranch_color=\"$bad_color\"\n+ \t\t\t\t\tbranch_color=\"$ok_color\"\n\nif detached = yes, then bad_color should be applied, else use ok_color.\n\nCheers\n\nSimon\n"}]}