Re: [PATCH] make __git_ps1 accept a third parameter in pcmode

[Simon Oosthoek <s.oosthoek@xs4all.nl>]

* Junio C Hamano <gitster@pobox.com> [2012-12-26 11:45:48 -0800]:

> Simon Oosthoek <s.oosthoek@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.oosthoek@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>%s<post>" format string and do either of these:
> 
> 	PS1=$(__git_ps1 "<pre>%s<post>")
> 	PROMPT_COMMAND='PS1=$(__git_ps1 "<pre>%s<post>")'
> 
> 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