Re: [PATCH] make __git_ps1 accept a third parameter in pcmode
Simon Oosthoek s.oosth...@xs4all.nl writes: The optional third parameter when __git_ps1 is used in PROMPT_COMMAND mode as format string for printf to further customize the way the git status string is embedded in the user's PS1 prompt. Signed-off-by: Simon Oosthoek s.oosth...@xs4all.nl --- Thanks. If we do not care about the existing users (and in this case, because PROMPT_COMMAND mode is in no released version, we could declare there is no existing user), another and simpler approach is to just drop ( and ) altogether and have the user give these as part of the pre/post strings. Or we could go the other way and drop pre/post strings, making them part of the printf_format string. Perhaps that might be a better interface in the longer term. Then people can use the same pre%spost format string and do either of these: PS1=$(__git_ps1 pre%spost) PROMPT_COMMAND='PS1=$(__git_ps1 pre%spost)' without __git_ps1 having a special prompt command mode, no? I have a feeling that I am missing something major, though... if [ $w = * ]; then - PS1=$PS1\[$bad_color\]$w + gitstring=$gitstring\[$bad_color\]$w fi Every time I looked at this line, I wondered why '*' state is bad. Does a user go into any bad state by having a dirty working tree? Same for untracked ($u) and detached. These are all perfectly normal part of a workflow, so while choice of red may be fine to attract attention, calling it bad sounds misguided. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] make __git_ps1 accept a third parameter in pcmode
* Junio C Hamano gits...@pobox.com [2012-12-26 11:45:48 -0800]: Simon Oosthoek s.oosth...@xs4all.nl writes: The optional third parameter when __git_ps1 is used in PROMPT_COMMAND mode as format string for printf to further customize the way the git status string is embedded in the user's PS1 prompt. Signed-off-by: Simon Oosthoek s.oosth...@xs4all.nl --- Thanks. If we do not care about the existing users (and in this case, because PROMPT_COMMAND mode is in no released version, we could declare there is no existing user), another and simpler approach is to just drop ( and ) altogether and have the user give these as part of the pre/post strings. The problem with doing it in pre-post is when inside non-git directories. You want to avoid any gitstring output, including the brackets, when not inside a repository. Doing it all in the third parameter is perhaps a better approach, but then it becomes mandatory instead of optional. Or we could go the other way and drop pre/post strings, making them part of the printf_format string. Perhaps that might be a better interface in the longer term. Then people can use the same pre%spost format string and do either of these: PS1=$(__git_ps1 pre%spost) PROMPT_COMMAND='PS1=$(__git_ps1 pre%spost)' without __git_ps1 having a special prompt command mode, no? But how to determine which mode to use? In pcmode, you must set the PS1, in command-subsitute mode, you must print a formatted gitstring. I have a feeling that I am missing something major, though... I think the fundamentally different way of setting the PS1 between the two modes is very confusing. Which is why I originally made a different function (with duplicated code) for both modes. if [ $w = * ]; then - PS1=$PS1\[$bad_color\]$w + gitstring=$gitstring\[$bad_color\]$w fi Every time I looked at this line, I wondered why '*' state is bad. Does a user go into any bad state by having a dirty working tree? Same for untracked ($u) and detached. These are all perfectly normal part of a workflow, so while choice of red may be fine to attract attention, calling it bad sounds misguided. Well, I'm most often a really casual user of git and to make this function work the way I want to, I found out by trial-and-error that this was a way to test whether it's time to colour the string red or green ;-) I'm very open to better ways to determine the colour modes. Anyway, the colours are now more or less the same as what git itself uses when printing the status with colour hints in git status. Cheers Simon -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] make __git_ps1 accept a third parameter in pcmode
Simon Oosthoek s.oosth...@xs4all.nl writes: The problem with doing it in pre-post is when inside non-git directories. You want to avoid any gitstring output, including the brackets, when not inside a repository. Ah, Ok, that is probably what I missed. Or we could go the other way and drop pre/post strings, making them part of the printf_format string. Perhaps that might be a better interface in the longer term. Then people can use the same pre%spost format string and do either of these: PS1=$(__git_ps1 pre%spost) PROMPT_COMMAND='PS1=$(__git_ps1 pre%spost)' without __git_ps1 having a special prompt command mode, no? But how to determine which mode to use? In pcmode, you must set the PS1, in command-subsitute mode, you must print a formatted gitstring. The point of the above two was that __git_ps1 does not have to set PS1 as long as the insn says user to use PROMPT_COMMAND that sets PS1 himself, exactly as illustrated above. In other words, replace the last PS1=... in the prompt command mode with an echo or something and make the user responsible for assigning it to PS1 in his PROMPT_COMMAND. Or put it in another way, I was hoping that we can do without adding the prompt command mode---if there is no two modes, there is no need to switch between them. But as I said, there probably is a reason why that approach does not work, that is why I said... I have a feeling that I am missing something major, though... -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] make __git_ps1 accept a third parameter in pcmode
Simon Oosthoek s.oosth...@xs4all.nl writes: Every time I looked at this line, I wondered why '*' state is bad. Does a user go into any bad state by having a dirty working tree? Same for untracked ($u) and detached. These are all perfectly normal part of a workflow, so while choice of red may be fine to attract attention, calling it bad sounds misguided. Well, I'm most often a really casual user of git and to make this function work the way I want to, I found out by trial-and-error that this was a way to test whether it's time to colour the string red or green ;-) I'm very open to better ways to determine the colour modes. Anyway, the colours are now more or less the same as what git itself uses when printing the status with colour hints in git status. Oh, I am not opposed to the choice of colors; something that wants an attention from the user may be better in red. I was merely commenting on the choice of the variable name, the user of word bad as if the conditions that use this color were bad in some way. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] make __git_ps1 accept a third parameter in pcmode
Junio C Hamano gits...@pobox.com writes: But as I said, there probably is a reason why that approach does not work, that is why I said... I have a feeling that I am missing something major, though... In any case, this was more like if we were doing this from scratch conversation. I think PROMPT_COMMAND mode that takes pre and post string has been advertised throughout the pre-release freeze, which is long enough in Git timescale to avoid backward incompatibility, so we are already stuck with the function in two modes even if what I said in the previous message (i.e. why not just one mode) worked. I am considering to fast-track the optional third parameter patch to the 1.8.1 final, so that we can have the same degree of customizability in both modes. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] make __git_ps1 accept a third parameter in pcmode
* Junio C Hamano gits...@pobox.com [2012-12-26 12:32:20 -0800]: The point of the above two was that __git_ps1 does not have to set PS1 as long as the insn says user to use PROMPT_COMMAND that sets PS1 himself, exactly as illustrated above. In other words, replace the last PS1=... in the prompt command mode with an echo or something and make the user responsible for assigning it to PS1 in his PROMPT_COMMAND. Or put it in another way, I was hoping that we can do without adding the prompt command mode---if there is no two modes, there is no need to switch between them. But as I said, there probably is a reason why that approach does not work, that is why I said... The only reason to my knowledge is that bash's handling of zero-length strings, like terminal colour commands, is producing a PS1 that outputs less visible characters than bash thinks and thus bash makes mistakes when wrapping the commandline. The way to prevent that is to use \[ and \] around those and that doesn't seem to work from a string produced from command-substitution. (BTW, the colours come through just fine, just the \[ and \] don't) Another approach could be to split up the functionality and have a few support functions to set various variables (corresponding with the gitstring features, like *%+ characters and colour hints). These variables could then be used by a custom PROMPT_COMMAND function or a command substitution function to produce a gitstring. I suppose that would mean a complete rewrite or very close to it ;-) /Simon -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
