Junio C Hamano venit, vidit, dixit 27.09.2012 08:53: > Simon Oosthoek <soosthoek@xxxxxxxxxxxx> writes: > >> I read the guide and now I have some questions: >> >> - It suggests to use the oldest commit that contains the "bug" and can >> support the fix. This would be the very first mention of __git_ps1 >> function I think commit d3d717a4ad0c8d7329e79f7d0313baec57c6b585 > > You could claim that the lack of coloring is a bug, but nobody > complained about it so far (and I personally hate coloring in > prompts as they are distracting noise, and would reject a patch if > it weren't made conditional), so I would think this is more about > "adding a feature the users can choose to use but they do not have > to". > > We do not usually add new features to maintenance tracks, so the > result of applying the patch does not have to be merge-able to maint > or amything older. I would base the patch on v1.7.12 (the latest > stable release) if I were you. > >> - I read that git-prompt.sh is meant to support bash and zsh, I have >> only tested it on bash. Should I attempt to test it on zsh or is there a >> kind person with zsh as his/her shell to test it for me? Actually, the instructions in the prompt script are not complete for zsh (you need to activate expansion in the prompt), and I think there is some breakage because bash uses "\h" etc. for PS1 format specifiers whereas zsh uses '%h', and so the '%' in the prompt is a problem for zsh. > That is something you should ask on list, like you did here, but the > most effective way to do so is do so when you send a patch you > worked on and tested with bash. Say "I've tested it only with bash; > can you please take a look?" and Cc the folks you find in the output > of "git log contrib/completion/" who worked on making it workable > with zsh. > Additionally, there have been several attempts already for prompt. So I'd suggest you check the list archives to see whether you addressed the issues which were raised back then. I've actually been toying with that myself lately. A few hints: - You need to escape the escapes '\[', i.e. tell the shell that color escapes produce zero length output, or else line wrapping is distorted. - Bash interpretes '\' only when PS1 is assigned, not when an expansion in PS1 produces it. - Some don't like it colorful, so the coloring needs to depend on a config setting or env variable. - Coloring should be consistent with other coloring in Git, such as 'status -s -b'. - Coloring provides the way to make the prompt characters analogous to 'status -s -b' because a green 'M' is different from red 'M', and is much clearer then having to remember '+' vs. '*' (so there is a logic in that). >From trying myself, I'm convinced that you need a clever combination of PROMPT_COMMAND and PS1 to make this work. Setting PS1 in PROMPT_COMMAND is probably a no-go because that makes it difficult to customize PS1. I have something in the works which reproduces the current prompt but need to clean it up further. The actual coloring would require setting a lot of variables which communicate data from PROMPT_COMMAND to PS1, and I actually don't like that. An alternative approach would be: - Tell users to activate git prompt by doing something like PROMPT_COMMAND='__git_prompt "[\u@\h \W (%s)]\$ ' rather than the current PS1='[\u@\h \W$(__git_ps1 " (%s)")]\$ ' - set PS1 from __git_prompt I'm not sure about the performance implications of re-setting PS1 on (before) each prompt invocation, though. Would that be OK? Michael -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html