Re: [PATCH] git-prompt: make colors available in custom prompts

[Simon Oosthoek]

Hi Andrew

sorry, I only noticed your request this morning...

On 22/04/16 07:00, Andrew Schwartzmeyer wrote:

This was disabled in the original implementation, probably because it
does not work if the __git_ps1 function is single-quoted. However, if
you double-quote per the updated documentation, you can have colors in
your custom Git prompt function, no problem.

Signed-off-by: Andrew Schwartzmeyer 
---
  contrib/completion/git-prompt.sh | 12 ++--
  1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index f18aedc73..ffe79168c 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -12,8 +12,8 @@
  #source ~/.git-prompt.sh
  #3a) Change your PS1 to call __git_ps1 as
  #command-substitution:
-#Bash: PS1='[\u@\h \W$(__git_ps1 " (%s)")]\$ '
-#ZSH:  setopt PROMPT_SUBST ; PS1='[%n@%m %c$(__git_ps1 " (%s)")]\$ '
+#Bash: PS1="[\u@\h \W$(__git_ps1 ' (%s)')]\$ "
+#ZSH:  setopt PROMPT_SUBST ; PS1="[%n@%m %c$(__git_ps1 ' (%s)')]\$ "


I haven't tested this at all, but when using double quotes, you need to 
at least check all the escapings, like \$ should probably be: \\\$ when 
used in double quotes.



  #the optional argument will be used as format string.
  #3b) Alternatively, for a slightly faster prompt, __git_ps1 can
  #be used for PROMPT_COMMAND in Bash or for precmd() in Zsh
@@ -82,8 +82,9 @@
  #
  # If you would like a colored hint about the current dirty state, set
  # GIT_PS1_SHOWCOLORHINTS to a nonempty value. The colors are based on
-# the colored output of "git status -sb" and are available only when
-# using __git_ps1 for PROMPT_COMMAND or precmd.
+# the colored output of "git status -sb". If you are using your own
+# PROMPT_COMMAND function, you must use double-quotes when calling
+# __git_ps1, e.g. PS1="$(__git_ps1 '%s ')".
  #
  # If you would like __git_ps1 to do nothing in the case when the current
  # directory is set up to be ignored by git, then set
@@ -499,8 +500,7 @@ __git_ps1 ()

local z="${GIT_PS1_STATESEPARATOR-" "}"

-   # NO color option unless in PROMPT_COMMAND mode
-   if [ $pcmode = yes ] && [ -n "${GIT_PS1_SHOWCOLORHINTS-}" ]; then
+   if [ -n "${GIT_PS1_SHOWCOLORHINTS-}" ]; then
__git_ps1_colorize_gitstring
fi




The original reason for not using colors in command substitution mode 
was that the prompt string length was not calculated correctly by bash 
and it messed up the commandline with very long commands (relative to 
the terminal width), when browsing the command history.
However I think I've seen this effect even with the new code, but I've 
never dug into this.


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: Colors in __git_ps1

[Simon Oosthoek]

Dear Mantas,

On 07/10/14 18:18, Mantas Mikulėnas wrote:

There was a question in #git recently on why __git_ps1 from
git-prompt.sh does not allow colors in $PS1 mode.

 From what I see, commit 1bfc51ac8141 talks about the need for \[ and
\] assignments in $PS1, and commit cf4cac4cfc13 says that PS1 mode
turns off color support since \[ and \] won't work; as I understand
it, this is because bash will output literal \[ if __git_ps1 tries
to echo it.

Internally, \[ and \] are translated by bash into 0x01 and 0x02 before
passing the final string to readline. So there *is* a way to achieve
the same effect in PS1 mode – __git_ps1 just needs to echo \001 and
\002 before  after the color codes, and readline will interpret them
correctly when calculating the prompt width. For example, echo
$'foo\001\e[1m\002bar'.

Might be worth considering, even if $PS1 mode is inferior to
$PROMPT_COMMAND mode for other reasons.



I would actually prefer the PS1='$(__git_ps)' like way, as it is more 
generic and intuitive when you know generic Bourne shell ways.


The reason to go for PROMPT_COMMAND was that it appears to be the only 
way to set the PS1 prompt and let bash keep track of the length of the 
prompt properly. This is needed to allow browsing the bash history with 
long(er than width of the terminal) command lines without the terminal 
getting messed up.
And I'm still not sure PROMPT_COMMAND mode fixes this properly, but it 
passed the tests where command substitution mode failed.


IMHO the way colours are now implemented could very well be considered a 
workaround for a bug in bash. Only I'm not skilled enough (or have 
enough time) to get to the bottom of it...


I hope this answers your question.

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 v2 00/13] bash prompt speedup

[Simon Oosthoek]

* Junio C Hamano gits...@pobox.com [2013-06-18 09:48:28 -0700]:

 SZEDER Gábor sze...@ira.uka.de writes:
 
  This patch series eliminates many command substitutions and commands
  in __git_ps1() from top to bottom by replacing them with bash builtins
  or consolidating them.  A few timing results are shown in the log
  message of patch 10.
 
 Nice.  I think I saw Peff's comment and discussion between you two
 already resuted in a fixup, so perhaps I'll see a reroll sometime
 later when the dust settles?
 
 Also, could you help review the other topic by Eduardo R. D'Avila
 about colored prompt (Sion Oosthoek, who did the color support,
 CC'ed)?
 
 http://thread.gmane.org/gmane.comp.version-control.git/228017
 
 The impression I got when the PROMPT_COMMAND series was discussed
 last October was that you need to use \[...\] pairs to get the
 cursor position right for the purpose of command line editing, and
 D'Avila's series seemed to only do so in PROMPT_COMMAND mode.
 

Hi Junio e.a.

Unfortunately I'm very busy with lots of stuff, so hardly time to look at this. 
(I didn't read the full patch or resulting file)

The PROMPT_COMMAND business was not something I was glad to use, I was unable 
to get command substitution mode to work with colours and keep bash happy about 
the prompt string length. The thing to test is not whether or not colours 
appear when using substitution in PS1, but to see whether bash will not mess up 
the commandline when browsing through the history. This is especially 
inconvenient with very long commandlines (as you can imagine).

An optimisation which I've not yet had time to work on would be to do a lot of 
the processing in separate functions and use the result in separate functions 
for pcmode and subst. mode. The idea being that the maintainability of the 
logic for generating the prompt goes up (no duplicate code, clear separation, 
etc.) and the size of the called functions to gerenate the prompt goes down. 
And perhaps most important that it would be very easy to build a customised 
version of __git_ps1() using those functions from the standard code. 

I know this is pretty vague, I wish it wasn't so...

If it's somehow possible to eliminate the PROMPT_COMMAND mode, I'm all for it. 
But I doubt it can be done while keeping commandline browsing working ok... 
(please go ahead and prove me wrong!)

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] shell-prompt: clean up nested if-then

[Simon Oosthoek]

On 19/02/13 00:07, Junio C Hamano wrote:
 
 I think you are misreading a suggestion that is somewhat misguided
 (yes [ condition  another ] does not make sense, but that is
 not applicable to test conditon  test another); ignore it.
 
 It is fine to write test condition  test another and that
 works portably to even pre-posix systems.

(that's like doing ls file  rm file )

 
 But the existing code the patch touches favors [] over test
 consistently; that alone is a good reason to stick with [] in _this_
 script, even though it is against Git's overall shell script style.
 

I suppose it would be fine if a patch was sent to update the entire
git-prompt.sh code to be more in line with the Git shell script style...

My original gripe was just with doing it in one place while leaving all
the others unchanged. It makes for messy reading and leads to confusion.

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: git-prompt.sh vs leading white space in __git_ps1()::printf_format

[Simon Oosthoek]

* Junio C Hamano gits...@pobox.com [2012-12-25 23:47:53 -0800]:
 
 Can we make it take an optional third parameter so that we could say
 
   PROMPT_COMMAND='__git_ps1 : \h \W ;  /%s'
 
 to do the same as what the command substitution mode would have
 given for
 
   PS1=': \h \W$(__git_ps1 /%s); '
 
 perhaps?
 
 Totally untested, but perhaps along this line.
 

I tried your patch and (to my surprise, after the first reading) it worked.

I've further modified git-prompt.sh to include more usage text and I changed
the name of ps1 to gitstring, as it might be confused with PS1 upon casual
reading.

I'll be sending a format-patch patchmail ASAP...


  contrib/completion/git-prompt.sh | 24 ++--
  1 file changed, 14 insertions(+), 10 deletions(-)
 
 diff --git a/contrib/completion/git-prompt.sh 
 b/contrib/completion/git-prompt.sh
 index 9b074e1..b2579f4 100644
 --- a/contrib/completion/git-prompt.sh
 +++ b/contrib/completion/git-prompt.sh
 @@ -236,9 +236,10 @@ __git_ps1 ()
   local printf_format=' (%s)'
  
   case $# in
 - 2)  pcmode=yes
 + 2|3)pcmode=yes
   ps1pc_start=$1
   ps1pc_end=$2
 + printf_format=${3:-$printf_format}
   ;;
   0|1)printf_format=${1:-$printf_format}
   ;;
 @@ -339,6 +340,7 @@ __git_ps1 ()
  
   local f=$w$i$s$u
   if [ $pcmode = yes ]; then
 + local ps1=
   if [ -n ${GIT_PS1_SHOWCOLORHINTS-} ]; then
   local c_red='\e[31m'
   local c_green='\e[32m'
 @@ -356,29 +358,31 @@ __git_ps1 ()
   branch_color=$bad_color
   fi
  
 - # Setting PS1 directly with \[ and \] around 
 colors
 + # Setting ps1 directly with \[ and \] around 
 colors
   # is necessary to prevent wrapping issues!
 - PS1=$ps1pc_start 
 (\[$branch_color\]$branchstring\[$c_clear\]
 + ps1=\[$branch_color\]$branchstring\[$c_clear\]
  
   if [ -n $w$i$s$u$r$p ]; then
 - PS1=$PS1 
 + ps1=$ps1  
 
   fi
   if [ $w = * ]; then
 - PS1=$PS1\[$bad_color\]$w
 + ps1=$ps1\[$bad_color\]$w
   fi
   if [ -n $i ]; then
 - PS1=$PS1\[$ok_color\]$i
 + ps1=$ps1\[$ok_color\]$i
   fi
   if [ -n $s ]; then
 - PS1=$PS1\[$flags_color\]$s
 + ps1=$ps1\[$flags_color\]$s
   fi
   if [ -n $u ]; then
 - PS1=$PS1\[$bad_color\]$u
 + ps1=$ps1\[$bad_color\]$u
   fi
 - PS1=$PS1\[$c_clear\]$r$p)$ps1pc_end
 + ps1=$ps1\[$c_clear\]$r$p
   else
 - PS1=$ps1pc_start ($c${b##refs/heads/}${f:+ 
 $f}$r$p)$ps1pc_end
 + ps1=$c${b##refs/heads/}${f:+ $f}$r$p
   fi
 + ps1=$(printf -- $printf_format $ps1)
 + PS1=$ps1pc_start$ps1$ps1pc_end
   else
   # NO color option unless in PROMPT_COMMAND mode
   printf -- $printf_format $c${b##refs/heads/}${f:+ 
 $f}$r$p

/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

[PATCH] make __git_ps1 accept a third parameter in pcmode

[Simon Oosthoek]

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
---
 contrib/completion/git-prompt.sh |   32 
 1 file changed, 20 insertions(+), 12 deletions(-)

diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 9b074e1..2922bb3 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -24,6 +24,8 @@
 #will show username, at-sign, host, colon, cwd, then
 #various status string, followed by dollar and SP, as
 #your prompt.
+#Optionally, you can supply a third argument with a printf
+#format string to finetune the output of the branch status
 #
 # The argument to __git_ps1 will be displayed only if you are currently
 # in a git repository.  The %s token will be the name of the current
@@ -222,10 +224,12 @@ __git_ps1_show_upstream ()
 # when called from PS1 using command substitution
 # in this mode it prints text to add to bash PS1 prompt (includes branch name)
 #
-# __git_ps1 requires 2 arguments when called from PROMPT_COMMAND (pc)
+# __git_ps1 requires 2 or 3 arguments when called from PROMPT_COMMAND (pc)
 # in that case it _sets_ PS1. The arguments are parts of a PS1 string.
-# when both arguments are given, the first is prepended and the second appended
+# when two arguments are given, the first is prepended and the second appended
 # to the state string when assigned to PS1.
+# The optional third parameter will be used as printf format string to further
+# customize the output of the git-status string.
 # In this mode you can request colored hints using GIT_PS1_SHOWCOLORHINTS=true
 __git_ps1 ()
 {
@@ -236,9 +240,10 @@ __git_ps1 ()
local printf_format=' (%s)'
 
case $# in
-   2)  pcmode=yes
+   2|3)pcmode=yes
ps1pc_start=$1
ps1pc_end=$2
+   printf_format=${3:-$printf_format}
;;
0|1)printf_format=${1:-$printf_format}
;;
@@ -339,6 +344,7 @@ __git_ps1 ()
 
local f=$w$i$s$u
if [ $pcmode = yes ]; then
+   local gitstring=
if [ -n ${GIT_PS1_SHOWCOLORHINTS-} ]; then
local c_red='\e[31m'
local c_green='\e[32m'
@@ -356,29 +362,31 @@ __git_ps1 ()
branch_color=$bad_color
fi
 
-   # Setting PS1 directly with \[ and \] around 
colors
+   # Setting gitstring directly with \[ and \] 
around colors
# is necessary to prevent wrapping issues!
-   PS1=$ps1pc_start 
(\[$branch_color\]$branchstring\[$c_clear\]
+   
gitstring=\[$branch_color\]$branchstring\[$c_clear\]
 
if [ -n $w$i$s$u$r$p ]; then
-   PS1=$PS1 
+   gitstring=$gitstring  

fi
if [ $w = * ]; then
-   PS1=$PS1\[$bad_color\]$w
+   gitstring=$gitstring\[$bad_color\]$w
fi
if [ -n $i ]; then
-   PS1=$PS1\[$ok_color\]$i
+   gitstring=$gitstring\[$ok_color\]$i
fi
if [ -n $s ]; then
-   PS1=$PS1\[$flags_color\]$s
+   gitstring=$gitstring\[$flags_color\]$s
fi
if [ -n $u ]; then
-   PS1=$PS1\[$bad_color\]$u
+   gitstring=$gitstring\[$bad_color\]$u
fi
-   PS1=$PS1\[$c_clear\]$r$p)$ps1pc_end
+   gitstring=$gitstring\[$c_clear\]$r$p
else
-   PS1=$ps1pc_start ($c${b##refs/heads/}${f:+ 
$f}$r$p)$ps1pc_end
+   gitstring=$c${b##refs/heads/}${f:+ $f}$r$p
fi
+   gitstring=$(printf -- $printf_format $gitstring)
+   PS1=$ps1pc_start$gitstring$ps1pc_end
else
# NO color option unless in PROMPT_COMMAND mode
printf -- $printf_format $c${b##refs/heads/}${f:+ 
$f}$r$p
-- 
1.7.9.5

PS, I was surprised

generating format-patch options from an e-mail

[Simon Oosthoek]

Hi all

I've been very frustrated by the process to setup a commandline for git 
format-patch, to include everyone in the cc list and reply to the right 
message-id.

In my frustration I created a perl script to generate the options from a saved 
e-mail, I realise that it may be non-general and perhaps it could be written 
better using a module which understands e-mails, but well, it worked for me ;-)

Anyway, I could imagine this as optional flag of git format-patch, so you could 
say:
$ git format-patch -s --in-reply-to-email mboxfile a7fe7de8

But I'll save that as an exercise for the reader (or the future)

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]

* 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

generating format-patch options from an e-mail

[Simon Oosthoek]

Hi all

I've been very frustrated by the process to setup a commandline for git 
format-patch, to include everyone in the cc list and reply to the right 
message-id.

In my frustration I created a perl script to generate the options from a saved 
e-mail, I realise that it may be non-general and perhaps it could be written 
better using a module which understands e-mails, but well, it worked for me ;-)

Anyway, I could imagine this as optional flag of git format-patch, so you could 
say:
$ git format-patch -s --in-reply-to-email mboxfile a7fe7de8

But I'll save that as an exercise for the reader (or the future)

Cheers

Simon

PS, now with the script
#!/usr/bin/perl

use warnings;
use strict;

our @to;
our @cc;
our @id;
our $emptyline=0;

if (defined $ARGV[0] and -f $ARGV[0]) {
	open (MAIL, $ARGV[0]) or die cannot open $ARGV[0]\n;
	#while (my $line=MAIL  ($emptyline == 0) ) {
	while (my $line=MAIL ) {
			chomp $line;
			my $header=;
			my $content=;
		
			if ($line =~ /^(.*?):.*[ ,](.*?@.*?)[, ]/ ||
	$line =~ /^(.*ID?):.*[ ,](.*?)[, ]/) {
	$header=$1;
	$content=$2;
	if ($header eq From) {
			push(@to, $content);
	} if ($header eq To) {
			push(@cc, $content);
	} elsif ($header eq Cc) {
			$line =~ /:(.*)$/;
			my @ccs=split(/,/, $1);
			foreach my $addr (@ccs) {
	if ($addr =~ /(.*)/) {
			push(@cc, $1);
	} else {
			push(@cc, $addr);
	}
			}
	} elsif ($header eq Message-ID) {
			push(@id, $content);
	}
			}
			$emptyline++ if (length($line) == 0);

	}
	close (MAIL);
}


foreach my $item (@to) {
		print  --to \$item\;
}
foreach my $item (@cc) {
		print  --cc \$item\;
}
foreach my $item (@id) {
		print  --in-reply-to \$item\;
}

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

[Simon Oosthoek]

* 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

Re: generating format-patch options from an e-mail

[Simon Oosthoek]

* Junio C Hamano gits...@pobox.com [2012-12-26 12:35:28 -0800]:
 
  Anyway, I could imagine this as optional flag of git format-patch, so you 
  could say:
  $ git format-patch -s --in-reply-to-email mboxfile a7fe7de8
 
  But I'll save that as an exercise for the reader (or the future)
 
 I think a much more general approach would be to turn your script
 into get-msg-id script and use it like so:
 
   $ git format-patch --in-reply-to $(get-msg-id mboxfile) a7fe7de8
 
 Then you can reuse that script in a context outside format-patch,
 whereever you need the message-id in a single message in the
 mailbox.
 

That would work for the message-ID, but not for the various To: and Cc: 
addresses.

The hacky script that I sent afterwards produces a string with the various 
options to git format-patch (--to --cc --in-reply-to) based on the headers 
To:/Cc:/From:/Message-ID:

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: git-prompt.sh vs leading white space in __git_ps1()::printf_format

[Simon Oosthoek]

Hi Junio

This removes most of the ambiguities :-)
Ack from me!

I still have some minor nits, but I'll leave that for another time when I'm 
less busy.

BTW, I haven't tried this yet, but if you pass 2 arguments to __git_ps1 when 
called from command-substition mode, I suppose it will think it's in PC mode 
and overwrite the PS1!

At some point, I'd like to see this code split off into pc and cs functions 
which call a common function to get the git status. But that's a major rewrite 
and it may involve more overhead, since each function should process the output 
of the common function in a different way.

Cheers

Simon

* Junio C Hamano gits...@pobox.com [2012-12-11 16:03:36 -0800]:

 Junio C Hamano gits...@pobox.com writes:
 
  Perhaps like this?
 
 OK, this time with a log message.
 
 -- 8 --
 Subject: [PATCH] git-prompt.sh: update PROMPT_COMMAND documentation
 
 The description of __git_ps1 function operating in two-arg mode was
 not very clear.  It said set PROMPT_COMMAND=__git_ps1 which is not
 the right usage for this mode, followed by To customize the prompt,
 do this, giving a false impression that those who do not want to
 customize it can get away with no-arg form, which was incorrect.
 
 Make it clear that this mode always takes two arguments, pre and
 post, with an example.
 
 The straight-forward one should be listed as the primary usage, and
 the confusing one should be an alternate for advanced users.  Swap
 the order of these two.
 
 Signed-off-by: Junio C Hamano gits...@pobox.com
 ---
  contrib/completion/git-prompt.sh | 16 +++-
  1 file changed, 11 insertions(+), 5 deletions(-)
 
 diff --git a/contrib/completion/git-prompt.sh 
 b/contrib/completion/git-prompt.sh
 index a8b53ba..9b074e1 100644
 --- a/contrib/completion/git-prompt.sh
 +++ b/contrib/completion/git-prompt.sh
 @@ -10,14 +10,20 @@
  #1) Copy this file to somewhere (e.g. ~/.git-prompt.sh).
  #2) Add the following line to your .bashrc/.zshrc:
  #source ~/.git-prompt.sh
 -#3a) In ~/.bashrc set PROMPT_COMMAND=__git_ps1
 -#To customize the prompt, provide start/end arguments
 -#PROMPT_COMMAND='__git_ps1 \u@\h:\w \\\$ '
 -#3b) Alternatively change your PS1 to call __git_ps1 as
 +#3a) Change your PS1 to call __git_ps1 as
  #command-substitution:
  #Bash: PS1='[\u@\h \W$(__git_ps1  (%s))]\$ '
  #ZSH:  PS1='[%n@%m %c$(__git_ps1  (%s))]\$ '
 -#the optional argument will be used as format string
 +#the optional argument will be used as format string.
 +#3b) Alternatively, if you are using bash, __git_ps1 can be
 +#used for PROMPT_COMMAND with two parameters, pre and
 +#post, which are strings you would put in $PS1 before
 +#and after the status string generated by the git-prompt
 +#machinery.  e.g.
 +#   PROMPT_COMMAND='__git_ps1 \u@\h:\w \\\$ '
 +#will show username, at-sign, host, colon, cwd, then
 +#various status string, followed by dollar and SP, as
 +#your prompt.
  #
  # The argument to __git_ps1 will be displayed only if you are currently
  # in a git repository.  The %s token will be the name of the current
 -- 
 1.8.1.rc1.128.gd8d1528
 
--
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: git-prompt.sh vs leading white space in __git_ps1()::printf_format

[Simon Oosthoek]

On 12/12/12 18:50, Junio C Hamano wrote:
 Simon Oosthoek s.oosth...@xs4all.nl writes:
 
 This removes most of the ambiguities :-)
 Ack from me!
 
 OK, as this is a low-impact finishing touch for a new feature, I'll
 fast-track this to 'master' before the final release.
 

Ok, wonderful!
BTW, I tried the thing I mentioned and it was safe to do:
PS1='blabla$(__git_ps1 x y)blabla'
will not eat your prompt, although I'd recommend putting something
useful instead of blabla ;-)

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: git-prompt.sh vs leading white space in __git_ps1()::printf_format

[Simon Oosthoek]

Hi Junio

This patch for the documentation doesn't seem to be in rc2 of 1.8.1...

tonight I was explaining this feature to a small group of people and I
pulled the git tree to get the latest code.

The current tagged 1.8.1-rc2 doesn't yet have your improvement and after
trying to explain it, I think it should be improved even more ;-)

I'm sorry to say I don't have the time right now to make a proper patch,
but I'll try to expand below...

On 28/11/12 21:47, Junio C Hamano wrote:
 Simon Oosthoek s.oosth...@xs4all.nl writes:
 
 perhaps the point should read like this:
 #3a) In ~/.bashrc set PROMPT_COMMAND
 #To customize the prompt, provide start/end arguments
 #PROMPT_COMMAND='__git_ps1 \u@\h:\w \\\$ '

 Which would not be confusing at all, I think...
 
 It says to customize, so a user who just wants the default (which
 does not exist but the comment does not say so) would be left
 without instruction, no?
 
 In $HOME/.bashrc, PROMPT_COMMAND can be set to
 '__git_ps1 pre post', where pre and post
 are strings you would put in $PS1 before and after
 the status string generated by git-prompt machinery.
 e.g.
 PROMPT_COMMAND='__git_ps1 \u@\h:\w \\\$ '
 
 or something?
 

The gist should be that:
__git_ps1 can function in two modes; The traditional way with command
substitution. This mode is activated when the function is provided 0 or
1 arguments. The new way, activated by providing exactly 2 arguments to
__git_ps1 is intended for use in the PROMPT_COMMAND way of bash to call
a function before writing the prompt. This command can then be (and is
in fact) used to set/overwrite the PS1 variable.

Only in the PROMPT_COMMAND mode can you get a prompt with colors for the
various states of the git tree showing in the prompt.

An example for inclusion in the ~/.bashrc file is:
-snip-
PROMPT_COMMAND='__git_ps1 \u@\h:\w \\\$ '
GIT_PS1_SHOWDIRTYSTATE=true
GIT_PS1_SHOWCOLORHINTS=true
--

It turns out that it can be quite confusing to get your head around this
split personality of __git_ps1...

I hope you can somehow get this into the next release with some
improvement to the docs!

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: git-prompt.sh vs leading white space in __git_ps1()::printf_format

[Simon Oosthoek]

* Piotr Krukowiecki piotr.krukowie...@gmail.com [2012-11-28 11:03:29 +0100]:

 Hi,
 
 when I set PROMPT_COMMAND to __git_ps1 I get a space at the beginning:
 

Is your setting?:
PROMPT_COMMAND=__git_ps1

I believe you need to give 2 parameters in order to use it in PROMPT_COMMAND 
mode.

In my .bashrc I have:
if [ -f ~/.gitprompt.sh ]
then
. ~/.gitprompt.sh
GIT_PS1_SHOWDIRTYSTATE=true
GIT_PS1_SHOWCOLORHINTS=true
GIT_PS1_SHOWUNTRACKEDFILES=true
PROMPT_COMMAND=__git_ps1 '\u@\[\e[1;34m\]\h\[\e[0m\]:\w' '\\\$ '
fi


  (master)pkruk@foobar ~/dir$
 ^ space
 
 Is there a reason for this? It looks like a waste of space. If I'm not in
 git repository I don't have the space:
 
 pkruk@foobar ~/other$
 
 I noticed the space is explicitly specified in printf_format in
 git-prompt.sh. Is it needed? If I remove it, everything seems to work fine
 (no leading space)...
 
 --- /usr/local/src/git/git/contrib/completion/git-prompt.sh 2012-11-28
 10:27:05.728939201 +0100
 +++ /home/pkruk/.git-prompt.sh 2012-11-28 10:52:56.852629745 +0100
 @@ -218,7 +218,7 @@ __git_ps1 ()
   local detached=no
   local ps1pc_start='\u@\h:\w '
   local ps1pc_end='\$ '
 - local printf_format=' (%s)'
 + local printf_format='(%s)'
 
   case $# in
   2) pcmode=yes


These last 2 lines say: if 2 arguments are given, use pcmode. Otherwise you get 
command-subtitution mode, which gives weird effects when being called from 
PROMPT_COMMAND.

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: git-prompt.sh vs leading white space in __git_ps1()::printf_format

[Simon Oosthoek]

On 28/11/12 21:47, Junio C Hamano wrote:
 Simon Oosthoek s.oosth...@xs4all.nl writes:
 
 perhaps the point should read like this:
 #3a) In ~/.bashrc set PROMPT_COMMAND
 #To customize the prompt, provide start/end arguments
 #PROMPT_COMMAND='__git_ps1 \u@\h:\w \\\$ '

 Which would not be confusing at all, I think...
 
 It says to customize, so a user who just wants the default (which
 does not exist but the comment does not say so) would be left
 without instruction, no?
 
 In $HOME/.bashrc, PROMPT_COMMAND can be set to
 '__git_ps1 pre post', where pre and post
 are strings you would put in $PS1 before and after
 the status string generated by git-prompt machinery.
 e.g.
 PROMPT_COMMAND='__git_ps1 \u@\h:\w \\\$ '
 
 or something?
 

Looks better than my suggestion :-)

thanks

/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 3/3] Change colors to be based on git status -sb in color mode

[Simon Oosthoek]

On 16/10/12 23:30, Junio C Hamano wrote:
 Simon Oosthoek s.oosth...@xs4all.nl writes:
 
 Hi

 Fixed the mistakes of the last one, and I'm now using the symbolic names 
 ok_color and bad_color.
 The test for headless state is now more direct, and I hope it is still 
 correct.

 /Simon
 
 Will apply with a bit more readable log message.

Ok

 
 I think it would be a good idea to squash something like the
 attached into this patch, though.

I tried the patch and it works when you switch the color assignments in
the if statement you added...

 @@ -264,7 +264,7 @@ __git_ps1 ()
   fi
  
   b=$(git symbolic-ref HEAD 2/dev/null) || {
 -
 + detached=yes
   b=$(
   case ${GIT_PS1_DESCRIBE_STYLE-} in
   (contains)
 @@ -335,8 +335,7 @@ __git_ps1 ()
   local flags_color=$c_lblue
   local branchstring=$c${b##refs/heads/}
  
 - if git symbolic-ref HEAD 2/dev/null 12
 - then
 + if [ $detached = yes ]; then
-   branch_color=$ok_color
+   branch_color=$bad_color
   else
-   branch_color=$bad_color
+   branch_color=$ok_color

if detached = yes, then bad_color should be applied, else use ok_color.

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

[PATCH 3/3] Change colors to be based on git status -sb in color mode

[Simon Oosthoek]

Hi

Fixed the mistakes of the last one, and I'm now using the symbolic names 
ok_color and bad_color.
The test for headless state is now more direct, and I hope it is still correct.

/Simon


this patch is an additional patch to the previous series of two.  It also
corrects the missing S and some minor details. The main point of this
one is changing the used colors to be more close to the color output of git
status -sb Mainly, the branchname stays green until it loses a HEAD, in
detached head state it becomes red.
The flags get their own color, either red or green for unstaged/staged and the
remaining flags get a different color or none at all.

Signed-off-by: Simon Oosthoek s.oosth...@xs4all.nl
---
 contrib/completion/git-prompt.sh |   52 +++---
 1 file changed, 31 insertions(+), 21 deletions(-)

diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 4fb998a..7dce319 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -55,11 +55,9 @@
 # setting the bash.showUpstream config variable.
 #
 # If you would like a colored hint about the current dirty state, set
-# GIT_PS1_SHOWCOLORHINTS to a nonempty value. When tracked files are
-# modified, the branch name turns red, when all modifications are staged
-# the branch name turns yellow and when all changes are checked in, the
-# color changes to green. The colors are currently hardcoded in the function.
-
+# GIT_PS1_SHOWCOLORHINTS to a nonempty value. The colors are based on 
+# the colored output of git status -sb.
+#
 # __gitdir accepts 0 or 1 arguments (i.e., location)
 # returns location of .git repo
 __gitdir ()
@@ -325,35 +323,47 @@ __git_ps1 ()
 
local f=$w$i$s$u
if [ $pcmode = yes ]; then
-   PS1=$ps1pc_start(
-   if [ -n ${GIT_PS1_SHOWCOLORHINT-} ]; then
+   if [ -n ${GIT_PS1_SHOWCOLORHINTS-} ]; then
local c_red='\e[31m'
local c_green='\e[32m'
-   local c_yellow='\e[33m'
local c_lblue='\e[1;34m'
-   local c_purple='\e[35m'
-   local c_cyan='\e[36m'
local c_clear='\e[0m'
+   local bad_color=$c_red
+   local ok_color=$c_green
+   local branch_color=$c_clear
+   local flags_color=$c_lblue
local branchstring=$c${b##refs/heads/}
-   local branch_color=$c_green
-   local flags_color=$c_cyan
 
-   if [ $w = * ]; then
-   branch_color=$c_red
-   elif [ -n $i ]; then
-   branch_color=$c_yellow
+   if git symbolic-ref HEAD 2/dev/null 12
+   then
+   branch_color=$ok_color
+   else
+   branch_color=$bad_color
fi
 
# Setting PS1 directly with \[ and \] around 
colors
# is necessary to prevent wrapping issues!
-   
PS1=$PS1\[$branch_color\]$branchstring\[$c_clear\]
-   if [ -n $f ]; then
-   PS1=$PS1 
\[$flags_color\]$f\[$c_clear\]
+   PS1=$ps1pc_start 
(\[$branch_color\]$branchstring\[$c_clear\]
+
+   if [ -n $w$i$s$u$r$p ]; then
+   PS1=$PS1 
+   fi
+   if [ $w = * ]; then
+   PS1=$PS1\[$bad_color\]$w
+   fi
+   if [ -n $i ]; then
+   PS1=$PS1\[$ok_color\]$i
+   fi
+   if [ -n $s ]; then
+   PS1=$PS1\[$flags_color\]$s
+   fi
+   if [ -n $u ]; then
+   PS1=$PS1\[$bad_color\]$u
fi
+   PS1=$PS1\[$c_clear\]$r$p)$ps1pc_end
else
-   PS1=$PS1$c${b##refs/heads/}${f:+ $f}$r$p
+   PS1=$ps1pc_start ($c${b##refs/heads/}${f:+ 
$f}$r$p)$ps1pc_end
fi
-   PS1=$PS1)$ps1pc_end
else
# NO color option unless in PROMPT_COMMAND mode

Re: [PATCH 2/2] show color hints based on state of the git tree

[Simon Oosthoek]

On 10/15/2012 10:23 AM, Michael J Gruber wrote:

Sorry for being late ($DAYJOB and such), but I just noticed this is on
next already:


+   if [ -n ${GIT_PS1_SHOWCOLORHINT-} ]; then


You're missing the S here (HINTS).


indeed, well spotted!
My test setup was apparently configured without the S and the commented 
uses all had HINTS...






+   local c_red='\e[31m'
+   local c_green='\e[32m'
+   local c_yellow='\e[33m'
+   local c_lblue='\e[1;34m'
+   local c_purple='\e[35m'
+   local c_cyan='\e[36m'
+   local c_clear='\e[0m'
+   local branchstring=$c${b##refs/heads/}
+   local branch_color=$c_green
+   local flags_color=$c_cyan
+
+   if [ $w = * ]; then
+   branch_color=$c_red
+   elif [ -n $i ]; then
+   branch_color=$c_yellow
+   fi
+
+   # Setting PS1 directly with \[ and \] around 
colors
+   # is necessary to prevent wrapping issues!
+   
PS1=$PS1\[$branch_color\]$branchstring\[$c_clear\]
+   if [ -n $f ]; then
+   PS1=$PS1 
\[$flags_color\]$f\[$c_clear\]
+   fi
+   else
+   PS1=$PS1$c${b##refs/heads/}${f:+ $f}$r$p
+   fi
+   PS1=$PS1)$ps1pc_end
+   else
+   # NO color option unless in PROMPT_COMMAND mode
printf -- ${1:- (%s)} $c${b##refs/heads/}${f:+ 
$f}$r$p
fi
fi



I'm afraid I don't like this coloring style at all because it is
inconsistent with the color usage of git status -sb. First of all, the
colors are different, and second, the fact *what* is colored is
different. I had suggested following git status -sb for a good reason.
It colors a branch green and a detached head red. It colors change
(A/D/M/R) as red/green depending on non-cached/cached, so that's how */+
should be. Your call for $/% (I'd leave them uncolored).[*][**]


This way works for me. The coloring scheme itself is probably quite 
personal and can, and probably should, be modified by end-users.
(Whether the current code is suitable for user-modification is another 
matter)


I'm quite unfamiliar with the color coding of git (I hadn't enabled that 
option), I suppose consistency would be better, but then you'd have to 
add some code to figure out which color is used for what in git's output 
and convert that to the code setting the colors here.


As for the characters used, I think there's a good reason not to use the 
ones git uses in the prompt. The characters in git status output are put 
in front of the files they apply to, in the prompt you only get a 
summarized output. And perhaps that argument could be extended to the 
use of the colors as well, I prefer to know whether I have uncommitted 
changes and in that category I want to know whether I already staged 
them or not.


If I want to know which files are unstaged/uncommitted I do git status 
to see that.




I think it's very confusing to have completely different schemes (not
just themes) for two versions of the same information: concise status
information.

So, please try and follow git status -sb.


I think there are different levels of conciseness. And I see git status 
-sb uses green for staged modified files, which would be confusing to me.




Michael

[*] Really, there's nothin red about a branch when there are cached or
non-cached changes. They are changes wrt. to what's in HEAD resp. the
index, no matter what HEAD is.


Do you mean that red (unstaged) and yellow (staged) are both red to you?



[**] Also, coloring the status characters opens the way to even using
the same characters as status -sb (ADM).



Perhaps, but that would be confusing to me ;-)

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 2/2] show color hints based on state of the git tree

[Simon Oosthoek]

On 10/15/2012 11:13 AM, Michael J Gruber wrote:


It really doesn't matter much what works for you, and it doesn't matter
what works for me either. The point is: What works for most users?


Obviously, that was my point as well ;-)


I'm quite unfamiliar with the color coding of git (I hadn't enabled that
option), I suppose consistency would be better, but then you'd have to
add some code to figure out which color is used for what in git's output
and convert that to the code setting the colors here.


As a starter, you could use the default colors which git uses. Querying
git for the colors could be the next, optional step.


I suppose it would be a start.

so how should it be?

all committed: green branch, no characters
only staged changes: green branch, colored characters (yellow/red?)
only unstaged changes: red/yellow branch, colored characters (red)
staged and unstaged changes: red/yellow branch, multiple characters in 
red/yellow?)

detached head: red commit-sha1 (abbrev.), characters as above?

What is the most useful thing to show in case of a detached head?
-the commit hash of current head?
-detached head





As for the characters used, I think there's a good reason not to use the
ones git uses in the prompt. The characters in git status output are put
in front of the files they apply to, in the prompt you only get a
summarized output. And perhaps that argument could be extended to the
use of the colors as well, I prefer to know whether I have uncommitted
changes and in that category I want to know whether I already staged
them or not.


Well, sure. The prompt could show any of AMCRD if you have any of those
changes. * + are shortcuts saying you have any of those.


How do you suppose that should work?
Add another configuration parameter like GIT_PS1_SHOWSTATUSSBCHARS 
(please give a better suggestion ;-) or the other way around 
GIT_PS1_SHOWSTARPLUS (either of which could be the default)



I think it's very confusing to have completely different schemes (not
just themes) for two versions of the same information: concise status
information.

So, please try and follow git status -sb.


I think there are different levels of conciseness. And I see git status
-sb uses green for staged modified files, which would be confusing to me.


...only because you don't know the color coding scheme. It's green
because those changes are saved somewhere (in the index) and would even
survice a branch switch.


I suppose you could see that as green (I usually view a yellow traffic 
light as green as well ;-)


Isn't it best practice to commit the staged changes ASAP? (But let's not 
diverge in this thread to discuss best-practices, so consider that a 
rhetorical question for now ;-)



No, I said red for unstaged, green for staged for the characters, i.e. a
* would always be red if present, a + always green if present.

For the branch name, it would be red for detached head and green for
checked out branch.


using green for staged changes could be acceptable for me, but I'm 
slightly worried that a colored character would be too slight a hint.


OTOH, a detached head would show up with or without color...




Perhaps, but that would be confusing to me ;-)


If that is case, you can try and propose changing that scheme...

But there's really a good reason for it. Cached (staged) changes are
safe because they are saved in the index, and also they are good to
go into the next commit, i.e. the commit traffic lights are green!


I suppose I knew that in the back of my mind, but not as clearly as you 
spell it out here... Tnx!


/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 2/2] show color hints based on state of the git tree

[Simon Oosthoek]

Hi Michael, sorry for the duplicate, forgot to reply-all...

On 10/15/2012 11:13 AM, Michael J Gruber wrote:


...only because you don't know the color coding scheme. It's green
because those changes are saved somewhere (in the index) and would even
survice a branch switch.



But git doesn't exactly let you do this:
I modified some things in git-prompt.sh trying to implement some of what 
we discussed. Then staged the file and tried git checkout HEAD^^ (or any 
branch)


error: Your local changes to the following files would be overwritten by 
checkout:

contrib/completion/git-prompt.sh
Please, commit your changes or stash them before you can switch branches.
Aborting

So I don't think it's all that strange to mark the branch as not quite 
safe to change. The idea (or at least my idea) behind these hints is 
that it reminds me to do stuff that prevents these Aborts. I think 
that that is a useful feature for any user of git.


In this light, would you accept yellow in the branch color to indicate 
uncommitted staged changes?


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 2/2] show color hints based on state of the git tree

[Simon Oosthoek]

On 10/15/2012 11:39 AM, Junio C Hamano wrote:

Thanks for bringing some sanity to the color of the bikeshed ;-)

As I don't use colors very much, I didn't bother checking the color
assignment in the patch in question, but everything you said in your
response makes 100% sense, including the traffic light analogy.



Hi Junio, Michael

The point of the thread and the patch was to enable the possibility of 
colors in the prompt without messing it up.


The actual colors used are more or less how I'm used to it, but as you 
said they may not be suitable to everyone.


@Junio, is this patch something you want to include as it is now (with 
the extra S that Michael pointed out) or do you want to wait for a 
discussion about which colors to use for which state?


I guess it could be quite a messy discussion, as you already hint at 
bikeshed colors, it's quite personal and subjective.


As a start, I think it's worth considering what the color would actually 
mean.


To me:
A neutral color should mean it's safe to switch branches or merge/update
A non-neutral color would mean some action is required before switching 
branches.
There are various states that may or may not get in the way of 
switching, like stashed stuff or divergence from upstream. I think these 
could get a color hint, but I'm not sure what kind.


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

[PATCH 3/3] Change colors to be based on git status -sb in color mode

[Simon Oosthoek]

Hi

this patch is an additional patch to the previous series of two.  It also
corrects the missing S and some minor details. The main point of this
one is changing the used colors to be more close to the color output of git
status -sb Mainly, the branchname stays green until it loses a HEAD, in
detached head state it becomes red.
The flags get their own color, either red or green for unstaged/staged and the
remaining flags get a different color or none at all.

Cheers

Simon

The color in the prompt now follows the colors used by
git itself when showing colors. The branch name is only
colored red if the tree has a detached HEAD.

Signed-off-by: Simon Oosthoek s.oosth...@xs4all.nl
---
 contrib/completion/git-prompt.sh |   52 ++
 1 file changed, 30 insertions(+), 22 deletions(-)

diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 4fb998a..ff69bbc 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -55,11 +55,9 @@
 # setting the bash.showUpstream config variable.
 #
 # If you would like a colored hint about the current dirty state, set
-# GIT_PS1_SHOWCOLORHINTS to a nonempty value. When tracked files are
-# modified, the branch name turns red, when all modifications are staged
-# the branch name turns yellow and when all changes are checked in, the
-# color changes to green. The colors are currently hardcoded in the function.
-
+# GIT_PS1_SHOWCOLORHINTS to a nonempty value. The colors are based on 
+# the colored output of git status -sb.
+#
 # __gitdir accepts 0 or 1 arguments (i.e., location)
 # returns location of .git repo
 __gitdir ()
@@ -325,35 +323,45 @@ __git_ps1 ()
 
local f=$w$i$s$u
if [ $pcmode = yes ]; then
-   PS1=$ps1pc_start(
-   if [ -n ${GIT_PS1_SHOWCOLORHINT-} ]; then
+   if [ -n ${GIT_PS1_SHOWCOLORHINTS-} ]; then
local c_red='\e[31m'
local c_green='\e[32m'
-   local c_yellow='\e[33m'
local c_lblue='\e[1;34m'
-   local c_purple='\e[35m'
-   local c_cyan='\e[36m'
local c_clear='\e[0m'
local branchstring=$c${b##refs/heads/}
-   local branch_color=$c_green
-   local flags_color=$c_cyan
+   local branch_color=$c_clear
+   local flags_color=$c_lblue
 
-   if [ $w = * ]; then
-   branch_color=$c_red
-   elif [ -n $i ]; then
-   branch_color=$c_yellow
-   fi
+   case $b in 
+   \(*\))  branch_color=$c_red
+   ;;
+   *)  local branch_color=$c_green
+   ;;
+   esac
 
# Setting PS1 directly with \[ and \] around 
colors
# is necessary to prevent wrapping issues!
-   
PS1=$PS1\[$branch_color\]$branchstring\[$c_clear\]
-   if [ -n $f ]; then
-   PS1=$PS1 
\[$flags_color\]$f\[$c_clear\]
+   PS1=$ps1pc_start 
(\[$branch_color\]$branchstring\[$c_clear\]
+
+   if [ -n $w$i$s$u$r$p ]; then
+   PS1=$PS1 
+   fi
+   if [ $w = * ]; then
+   PS1=$PS1\[$c_red\]$w
+   fi
+   if [ -n $i ]; then
+   PS1=$PS1\[$c_green\]$i
+   fi
+   if [ -n $s ]; then
+   PS1=$PS1\[$flags_color\]$s
+   fi
+   if [ -n $u ]; then
+   PS1=$PS1\[$c_red\]$u
fi
+   PS1=$PS1\[$c_clear\]$r$p)$ps1pc_end
else
-   PS1=$PS1$c${b##refs/heads/}${f:+ $f}$r$p
+   PS1=$ps1pc_start ($c${b##refs/heads/}${f:+ 
$f}$r$p)$ps1pc_end
fi
-   PS1=$PS1)$ps1pc_end
else
# NO color option unless in PROMPT_COMMAND mode
printf -- $printf_format $c${b##refs/heads/}${f:+ 
$f}$r$p
-- 
1.7.9.5
--
To unsubscribe from

[PATCH 1/2] Allow __git_ps1 to be used in PROMPT_COMMAND

[Simon Oosthoek]

Changes __git_ps1 to allow its use as PROMPT_COMMAND in bash
in addition to setting PS1 with __git_ps1 in a command substitution.
PROMPT_COMMAND has advantages for using color without running
into prompt-wrapping issues. Only by assigning \[ and \] to PS1
directly can bash know that these and the enclosed zero-width codes in
between don't count in the length of the prompt.

Signed-off-by: Simon Oosthoek s.oosth...@xs4all.nl
---
 contrib/completion/git-prompt.sh |   51 +-
 1 file changed, 45 insertions(+), 6 deletions(-)

diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 29b1ec9..4fbc1e6 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -10,9 +10,14 @@
 #1) Copy this file to somewhere (e.g. ~/.git-prompt.sh).
 #2) Add the following line to your .bashrc/.zshrc:
 #source ~/.git-prompt.sh
-#3) Change your PS1 to also show the current branch:
-# Bash: PS1='[\u@\h \W$(__git_ps1  (%s))]\$ '
-# ZSH:  PS1='[%n@%m %c$(__git_ps1  (%s))]\$ '
+#3a) In ~/.bashrc set PROMPT_COMMAND=__git_ps1
+#To customize the prompt, provide start/end arguments
+#PROMPT_COMMAND='__git_ps1 \u@\h:\w \\\$ '
+#3b) Alternatively change your PS1 to call __git_ps1 as
+#command-substitution:
+#Bash: PS1='[\u@\h \W$(__git_ps1  (%s))]\$ '
+#ZSH:  PS1='[%n@%m %c$(__git_ps1  (%s))]\$ '
+#the optional argument will be used as format string
 #
 # The argument to __git_ps1 will be displayed only if you are currently
 # in a git repository.  The %s token will be the name of the current
@@ -194,11 +199,39 @@ __git_ps1_show_upstream ()
 
 
 # __git_ps1 accepts 0 or 1 arguments (i.e., format string)
-# returns text to add to bash PS1 prompt (includes branch name)
+# when called from PS1 using command substitution
+# in this mode it prints text to add to bash PS1 prompt (includes branch name)
+#
+# __git_ps1 requires 2 arguments when called from PROMPT_COMMAND (pc)
+# in that case it _sets_ PS1. The arguments are parts of a PS1 string.
+# when both arguments are given, the first is prepended and the second appended
+# to the state string when assigned to PS1.
 __git_ps1 ()
 {
+   local pcmode=no
+   #defaults/examples:
+   local ps1pc_start='\u@\h:\w '
+   local ps1pc_end='\$ '
+   local printf_format='(%s)'
+
+   case $# in
+   2)  pcmode=yes
+   ps1pc_start=$1
+   ps1pc_end=$2
+   ;;
+   0|1)printf_format=${1:-$printf_format}
+   ;;
+   *)  return
+   ;;
+   esac
+
local g=$(__gitdir)
-   if [ -n $g ]; then
+   if [ -z $g ]; then
+   if [ $pcmode = yes ]; then
+   #In PC mode PS1 always needs to be set
+   PS1=$ps1pc_start$ps1pc_end
+   fi
+   else
local r=
local b=
if [ -f $g/rebase-merge/interactive ]; then
@@ -284,6 +317,12 @@ __git_ps1 ()
fi
 
local f=$w$i$s$u
-   printf -- ${1:- (%s)} $c${b##refs/heads/}${f:+ $f}$r$p
+   if [ $pcmode = yes ]; then
+   PS1=$ps1pc_start(
+   PS1=$PS1$c${b##refs/heads/}${f:+ $f}$r$p
+   PS1=$PS1)$ps1pc_end
+   else
+   printf -- $printf_format $c${b##refs/heads/}${f:+ 
$f}$r$p
+   fi
fi
 }
-- 
1.7.9.5
--
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

[PATCH 1/2] Allow __git_ps1 to be used in PROMPT_COMMAND

[Simon Oosthoek]

Apologies if you receive this e-mail multiple times, my MTA was misconfigured...


Changes __git_ps1 to allow its use as PROMPT_COMMAND in bash
in addition to setting PS1 with __git_ps1 in a command substitution.
PROMPT_COMMAND has advantages for using color without running
into prompt-wrapping issues. Only by assigning \[ and \] to PS1
directly can bash know that these and the enclosed zero-width codes in
between don't count in the length of the prompt.

Signed-off-by: Simon Oosthoek s.oosth...@xs4all.nl
---
 contrib/completion/git-prompt.sh |   51 +-
 1 file changed, 45 insertions(+), 6 deletions(-)

diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 29b1ec9..4fbc1e6 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -10,9 +10,14 @@
 #1) Copy this file to somewhere (e.g. ~/.git-prompt.sh).
 #2) Add the following line to your .bashrc/.zshrc:
 #source ~/.git-prompt.sh
-#3) Change your PS1 to also show the current branch:
-# Bash: PS1='[\u@\h \W$(__git_ps1  (%s))]\$ '
-# ZSH:  PS1='[%n@%m %c$(__git_ps1  (%s))]\$ '
+#3a) In ~/.bashrc set PROMPT_COMMAND=__git_ps1
+#To customize the prompt, provide start/end arguments
+#PROMPT_COMMAND='__git_ps1 \u@\h:\w \\\$ '
+#3b) Alternatively change your PS1 to call __git_ps1 as
+#command-substitution:
+#Bash: PS1='[\u@\h \W$(__git_ps1  (%s))]\$ '
+#ZSH:  PS1='[%n@%m %c$(__git_ps1  (%s))]\$ '
+#the optional argument will be used as format string
 #
 # The argument to __git_ps1 will be displayed only if you are currently
 # in a git repository.  The %s token will be the name of the current
@@ -194,11 +199,39 @@ __git_ps1_show_upstream ()
 
 
 # __git_ps1 accepts 0 or 1 arguments (i.e., format string)
-# returns text to add to bash PS1 prompt (includes branch name)
+# when called from PS1 using command substitution
+# in this mode it prints text to add to bash PS1 prompt (includes branch name)
+#
+# __git_ps1 requires 2 arguments when called from PROMPT_COMMAND (pc)
+# in that case it _sets_ PS1. The arguments are parts of a PS1 string.
+# when both arguments are given, the first is prepended and the second appended
+# to the state string when assigned to PS1.
 __git_ps1 ()
 {
+   local pcmode=no
+   #defaults/examples:
+   local ps1pc_start='\u@\h:\w '
+   local ps1pc_end='\$ '
+   local printf_format='(%s)'
+
+   case $# in
+   2)  pcmode=yes
+   ps1pc_start=$1
+   ps1pc_end=$2
+   ;;
+   0|1)printf_format=${1:-$printf_format}
+   ;;
+   *)  return
+   ;;
+   esac
+
local g=$(__gitdir)
-   if [ -n $g ]; then
+   if [ -z $g ]; then
+   if [ $pcmode = yes ]; then
+   #In PC mode PS1 always needs to be set
+   PS1=$ps1pc_start$ps1pc_end
+   fi
+   else
local r=
local b=
if [ -f $g/rebase-merge/interactive ]; then
@@ -284,6 +317,12 @@ __git_ps1 ()
fi
 
local f=$w$i$s$u
-   printf -- ${1:- (%s)} $c${b##refs/heads/}${f:+ $f}$r$p
+   if [ $pcmode = yes ]; then
+   PS1=$ps1pc_start(
+   PS1=$PS1$c${b##refs/heads/}${f:+ $f}$r$p
+   PS1=$PS1)$ps1pc_end
+   else
+   printf -- $printf_format $c${b##refs/heads/}${f:+ 
$f}$r$p
+   fi
fi
 }
-- 
1.7.9.5
--
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

[PATCH 2/2] show color hints based on state of the git tree

[Simon Oosthoek]

By setting GIT_PS1_SHOW_COLORHINTS when using __git_ps1
as PROMPT_COMMAND, you will get color hints in addition to
a different character (*+% etc.) to indicate the state of
the tree.

Signed-off-by: Simon Oosthoek s.oosth...@xs4all.nl
---
 contrib/completion/git-prompt.sh |   36 +++-
 1 file changed, 35 insertions(+), 1 deletion(-)

diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 4fbc1e6..a693565 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -53,6 +53,12 @@
 # find one, or @{upstream} otherwise.  Once you have set
 # GIT_PS1_SHOWUPSTREAM, you can override it on a per-repository basis by
 # setting the bash.showUpstream config variable.
+#
+# If you would like a colored hint about the current dirty state, set
+# GIT_PS1_SHOWCOLORHINTS to a nonempty value. When tracked files are
+# modified, the branch name turns red, when all modifications are staged
+# the branch name turns yellow and when all changes are checked in, the
+# color changes to green. The colors are currently hardcoded in the function.
 
 # __gitdir accepts 0 or 1 arguments (i.e., location)
 # returns location of .git repo
@@ -206,6 +212,7 @@ __git_ps1_show_upstream ()
 # in that case it _sets_ PS1. The arguments are parts of a PS1 string.
 # when both arguments are given, the first is prepended and the second appended
 # to the state string when assigned to PS1.
+# In this mode you can request colored hints using GIT_PS1_SHOWCOLORHINTS=true
 __git_ps1 ()
 {
local pcmode=no
@@ -319,9 +326,36 @@ __git_ps1 ()
local f=$w$i$s$u
if [ $pcmode = yes ]; then
PS1=$ps1pc_start(
-   PS1=$PS1$c${b##refs/heads/}${f:+ $f}$r$p
+   if [ -n ${GIT_PS1_SHOWCOLORHINT-} ]; then
+   local c_red='\e[31m'
+   local c_green='\e[32m'
+   local c_yellow='\e[33m'
+   local c_lblue='\e[1;34m'
+   local c_purple='\e[35m'
+   local c_cyan='\e[36m'
+   local c_clear='\e[0m'
+   local branchstring=$c${b##refs/heads/}
+   local branch_color=$c_green
+   local flags_color=$c_cyan
+
+   if [ $w = * ]; then
+   branch_color=$c_red
+   elif [ -n $i ]; then
+   branch_color=$c_yellow
+   fi
+
+   # Setting PS1 directly with \[ and \] around 
colors
+   # is necessary to prevent wrapping issues!
+   
PS1=$PS1\[$branch_color\]$branchstring\[$c_clear\]
+   if [ -n $f ]; then
+   PS1=$PS1 
\[$flags_color\]$f\[$c_clear\]
+   fi
+   else
+   PS1=$PS1$c${b##refs/heads/}${f:+ $f}$r$p
+   fi
PS1=$PS1)$ps1pc_end
else
+   # NO color option unless in PROMPT_COMMAND mode
printf -- $printf_format $c${b##refs/heads/}${f:+ 
$f}$r$p
fi
fi
-- 
1.7.9.5
--
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] Add __git_ps1_pc to use as PROMPT_COMMAND

[Simon Oosthoek]

Hi Junio

I hope you found my patches, if not, I'll try to send them out again. 
(Unfortunately my current mail setup is a mess and I need time to figure 
out what to fix...)


As for the zsh support, I found out a little bit more.
ZSH doesn't have a variable like PROMPT_COMMAND in bash. The precmd name 
is a function the user has to define herself to have it called before 
the prompt is shown. Functionally this is almost, but not quite, the 
same as PROMPT_COMMAND. The subtle difference is that with 
PROMPT_COMMAND you can use parameters to customize the prompt, so in 
bash you can say:


PROMPT_COMMAND=__git_ps1 '\u@\[\e[1;34m\]\h\[\e[0m\]:\w' '\\\$ '

where in zsh, if you want the status in the prompt, you can either use 
$(__git_ps1 (%s)) or something like it in setting the PS1 (and forget 
about the color hints!) or you can copy the __git_ps1 function and 
modify and rename it as precmd to set PS1 via that function. Obviously 
it is probably even more complicated, but I'd have to try it to be certain.


An alternative way might be to set special variables from __git_set_vars 
function which may be used in a custom precmd to set the prompt.


e.g. say __git_set_vars sets __GIT_VAR_STATE=dirty|stage|clean

in precmd you could do
case $__GIT_VAR_STATE in
(dirty) PS1=$PS1 files modified in __GIT_VAR_BRANCHNAME
;;
(stage) PS1=$PS1 files staged in __GIT_VAR_BRANCHNAME
;;
(clean) PS1=$PS1 __GIT_VAR_BRANCHNAME clean
;;
esac

(more or less of course)..

In that way it would be possible to add the colors relatively easily 
based on the state of the tree in a custom precmd function of zsh.


/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 1/2] Allow __git_ps1 to be used in PROMPT_COMMAND

[Simon Oosthoek]

Hi Junio

thanks for your feedback!

On 08/10/12 20:12, Junio C Hamano wrote:
 Simon Oosthoek s.oosth...@xs4all.nl writes:
 
 changes __git_ps1 to not just allow use in setting PS1
 with __git_ps1 in a command substitution, but also allows
 __git_ps1 to be used as PROMPT_COMMAND in bash.
 This has advantages for using color and I think it is more
 elegant
 
 Is and I think necessary?  I do not think it matters what _you_
 think when judging it is worth including in the future releases ;-)

Hmm, right :-P

How about This has advantages for using color without running into
prompt-wrapping issues. Only by assigning \[ and \] to PS1 directly can
bash know these and the color codes in between don't count in the length
of the prompt.?

I'll rewrite the patch later on...

Isn't it confusing that the color codes don't figure in this patch at all?

  
  # __git_ps1 accepts 0 or 1 arguments (i.e., format string)
 +# when called from PS1 using command substitution
 +# in this mode it returns text to add to bash PS1 prompt (includes branch 
 name) or
 +# __git_ps1 accepts 0 or 2 arguments when called from PROMPT_COMMAND
 +# in that case it _sets_ PS1. The arguments are parts of a PS1 string.
 +# when both arguments are given, the first is prepended and the second 
 appended
 +# to the state string when assigned to PS1, otherwise default start/end 
 strings
 +# are used.
 
 Sorry, but I cannot parse this.  Is this meant to be a two-item list,
 one describing the command substitution mode (zero or 1 arguments) and
 the other describing the prompt command mode?  If so, perhaps replacing
 the  or at the end of the first item with .\n#\n would make it readable.

I agree, that would make it more readable.

 
  __git_ps1 ()
  {
 +local pcmode=yes
 +local ps1pc_start='\u@\h:\w '
 +local ps1pc_end='\$ '
 +
 +case $PROMPT_COMMAND in
 +__git_ps1*)
 +if [ $# = 2 ]; then
 +ps1pc_start=$1
 +ps1pc_end=$2
 +fi
 +case $PS1 in
 +*__git_ps1*)
 +echo '__git_ps1: overwriting PS1 due to 
 PROMPT_COMMAND'
 
 Is this supposed to be an error and/or warning message?  Why is it
 worth warning only when you are overwriting __git_ps1 style of PS1
 and not other user customization?

That's what this is doing, I wasn't able to make it the other way
around. I thought that I could detect when PS1 contained __git_ps1 that
it shouldn't overwrite the PS1, which worked, but when PROMPT_COMMAND
was set with __git_ps1 and PS1=$(__git_ps1) as well, it gave double output.
As PROMPT_COMMAND is relatively obscure I thought a warning when
overwriting the PS1 was good, but not unless there was a real conflict
(double call to __git_ps1).
The warning is only shown once.

I don't think it would be possible to detect any other kind of
customization without including specific code for it. Do you think it's
unnecessary to include a warning? (I think it would take people a long
time to figure out why their prompt goes whoopsy without getting a hint
that PROMPT_COMMAND messes up the PS1)

(OTOH, if you configure PROMPT_COMMAND, you're bound to know a little
bit about what you're doing...)

Perhaps it's better to just do it.


 
 +;;
 +esac
 +;;
 +*)  pcmode=no ;; #no output
 +esac
 
 Please align outer case its arms) and esac at the same column,
 like you did for the inner case/esac.

ok

 
 Auto-detetction based on PROMPT_COMMAND is a flaky approach.  In
 practice, nobody will call PROMPT_COMMAND with the __git_ps1 without
 any parameter (100% people want their prompt to end with some sort
 of whitespace so they want the what comes after what is computed,
 aka $2), and even more importantly, nobody has been relying on use
 of 0 argument form of __git_ps1 in PROMPT_COMMAND.  So why not
 always require 2 args and take that as a cue to go into the pc mode?

That's a good idea, I'll change that.


 +if [ $pcmode = yes ]; then
 +PS1=$ps1pc_start($c${b##refs/heads/}${f:+ 
 $f}$r$p)$ps1pc_end
 +elif [ $pcmode = no ]; then
 +printf -- ${1:- (%s)} $c${b##refs/heads/}${f:+ 
 $f}$r$p
 +fi
 
 Are there $pcmode other than yes or no?  Why not just else,
 instead of performing the test twice?

I forgot to remove that one, I had a default at some point ;-)

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

[PATCH 2/2] show color hints based on state of the git tree

[Simon Oosthoek]

By setting GIT_PS1_SHOW_COLORHINTS when using __git_ps1
as PROMPT_COMMAND, you will get color hints in addition to
a different character (*+% etc.)

Signed-off-by: Simon Oosthoek soosth...@nieuwland.nl
---
 contrib/completion/git-prompt.sh |   42 +++---
 1 file changed, 39 insertions(+), 3 deletions(-)

diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index c50c94a..51285d7 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -53,6 +53,12 @@
 # find one, or @{upstream} otherwise.  Once you have set
 # GIT_PS1_SHOWUPSTREAM, you can override it on a per-repository basis by
 # setting the bash.showUpstream config variable.
+#
+# If you would like a colored hint about the current dirty state, set
+# GIT_PS1_SHOWCOLORHINTS to a nonempty value. When tracked files are
+# modified, the branch name turns red, when all modifications are staged
+# the branch name turns yellow and when all changes are checked in, the
+# color changes to green. The colors are currently hardcoded in the function.
 
 # __gitdir accepts 0 or 1 arguments (i.e., location)
 # returns location of .git repo
@@ -201,11 +207,12 @@ __git_ps1_show_upstream ()
 # __git_ps1 accepts 0 or 1 arguments (i.e., format string)
 # when called from PS1 using command substitution
 # in this mode it returns text to add to bash PS1 prompt (includes branch 
name) or
-# __git_ps1 accepts 0 or 2 arguments when called from PROMPT_COMMAND
+# __git_ps1 accepts 0 or 2 arguments when called from PROMPT_COMMAND (pc)
 # in that case it _sets_ PS1. The arguments are parts of a PS1 string.
 # when both arguments are given, the first is prepended and the second appended
 # to the state string when assigned to PS1, otherwise default start/end strings
 # are used.
+# In pcmode you can request colored hints using GIT_PS1_SHOWCOLORHINTS=true
 __git_ps1 ()
 {
local pcmode=yes
@@ -320,8 +327,37 @@ __git_ps1 ()
 
local f=$w$i$s$u
if [ $pcmode = yes ]; then
-   PS1=$ps1pc_start($c${b##refs/heads/}${f:+ 
$f}$r$p)$ps1pc_end
-   elif [ $pcmode = no ]; then
+   PS1=$ps1pc_start(
+   if [ -n ${GIT_PS1_SHOWCOLORHINT-} ]; then
+   local c_red='\e[31m'
+   local c_green='\e[32m'
+   local c_yellow='\e[33m'
+   local c_lblue='\e[1;34m'
+   local c_purple='\e[35m'
+   local c_cyan='\e[36m'
+   local c_clear='\e[0m'
+   local branchstring=$c${b##refs/heads/}
+   local branch_color=$c_green
+   local flags_color=$c_cyan
+
+   if [ $w = * ]; then
+   branch_color=$c_red
+   elif [ -n $i ]; then
+   branch_color=$c_yellow
+   fi
+
+   # Setting PS1 directly with \[ and \] around 
colors
+   # is necessary to prevent wrapping issues!
+   
PS1=$PS1\[$branch_color\]$branchstring\[$c_clear\]
+   if [ -n $f ]; then
+   PS1=$PS1 
\[$flags_color\]$f\[$c_clear\]
+   fi
+   else
+   PS1=$PS1$c${b##refs/heads/}${f:+ $f}$r$p
+   fi
+   PS1=$PS1)$ps1pc_end
+   else
+   # NO color option unless in PROMPT_COMMAND mode
printf -- ${1:- (%s)} $c${b##refs/heads/}${f:+ 
$f}$r$p
fi
fi
-- 
1.7.9.5
--
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

[PATCH 1/2] Allow __git_ps1 to be used in PROMPT_COMMAND

[Simon Oosthoek]

changes __git_ps1 to not just allow use in setting PS1
with __git_ps1 in a command substitution, but also allows
__git_ps1 to be used as PROMPT_COMMAND in bash.
This has advantages for using color and I think it is more
elegant

Signed-off-by: Simon Oosthoek soosth...@nieuwland.nl
---
 contrib/completion/git-prompt.sh |   51 +-
 1 file changed, 45 insertions(+), 6 deletions(-)

diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 29b1ec9..c50c94a 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -10,9 +10,14 @@
 #1) Copy this file to somewhere (e.g. ~/.git-prompt.sh).
 #2) Add the following line to your .bashrc/.zshrc:
 #source ~/.git-prompt.sh
-#3) Change your PS1 to also show the current branch:
-# Bash: PS1='[\u@\h \W$(__git_ps1  (%s))]\$ '
-# ZSH:  PS1='[%n@%m %c$(__git_ps1  (%s))]\$ '
+#3a) In ~/.bashrc set PROMPT_COMMAND=__git_ps1
+#To customize the prompt, provide start/end arguments
+#PROMPT_COMMAND=__git_ps1 '\u@\h:\w (' ')\$ '
+#3b) Alternatively change your PS1 to call __git_ps1 as
+#command-substitution:
+#Bash: PS1='[\u@\h \W$(__git_ps1  (%s))]\$ '
+#ZSH:  PS1='[%n@%m %c$(__git_ps1  (%s))]\$ '
+#the optional argument will be used as format string
 #
 # The argument to __git_ps1 will be displayed only if you are currently
 # in a git repository.  The %s token will be the name of the current
@@ -194,11 +199,41 @@ __git_ps1_show_upstream ()
 
 
 # __git_ps1 accepts 0 or 1 arguments (i.e., format string)
-# returns text to add to bash PS1 prompt (includes branch name)
+# when called from PS1 using command substitution
+# in this mode it returns text to add to bash PS1 prompt (includes branch 
name) or
+# __git_ps1 accepts 0 or 2 arguments when called from PROMPT_COMMAND
+# in that case it _sets_ PS1. The arguments are parts of a PS1 string.
+# when both arguments are given, the first is prepended and the second appended
+# to the state string when assigned to PS1, otherwise default start/end strings
+# are used.
 __git_ps1 ()
 {
+   local pcmode=yes
+   local ps1pc_start='\u@\h:\w '
+   local ps1pc_end='\$ '
+
+   case $PROMPT_COMMAND in
+   __git_ps1*)
+   if [ $# = 2 ]; then
+   ps1pc_start=$1
+   ps1pc_end=$2
+   fi
+   case $PS1 in
+   *__git_ps1*)
+   echo '__git_ps1: overwriting PS1 due to 
PROMPT_COMMAND'
+   ;;
+   esac
+   ;;
+   *)  pcmode=no ;; #no output
+   esac
+
local g=$(__gitdir)
-   if [ -n $g ]; then
+   if [ -z $g ]; then
+   if [ $pcmode = yes ]; then
+   #In PC mode PS1 always needs to be set
+   PS1=$ps1pc_start$ps1pc_end
+   fi
+   else
local r=
local b=
if [ -f $g/rebase-merge/interactive ]; then
@@ -284,6 +319,10 @@ __git_ps1 ()
fi
 
local f=$w$i$s$u
-   printf -- ${1:- (%s)} $c${b##refs/heads/}${f:+ $f}$r$p
+   if [ $pcmode = yes ]; then
+   PS1=$ps1pc_start($c${b##refs/heads/}${f:+ 
$f}$r$p)$ps1pc_end
+   elif [ $pcmode = no ]; then
+   printf -- ${1:- (%s)} $c${b##refs/heads/}${f:+ 
$f}$r$p
+   fi
fi
 }
-- 
1.7.9.5
--
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] Add __git_ps1_pc to use as PROMPT_COMMAND

[Simon Oosthoek]

On 10/02/2012 09:38 AM, Michael J Gruber wrote:

The longer I read your explanation, the less useful the PC mode
sounds like, at least to me.  So why does an user even want to use
such a mechanism, instead of PS1?  And even if the user wants to use
it by doing \w, \u etc. himself, she can do that with

PROMPT_COMMAND='
PS1=$(printf \u \h \w %s$  $(__git_ps1 %s))
 '

just fine, no?


Well, in that way, it doesn't work and setting PS1 directly would be 
better. But this way you cannot do colors.




Confused


I know the feeling ;-)



The problem (as far as I see) is only: What user interface do we want
to expose to the user, or rather, do we want to expose the user to ;)

So far, we say:

#1) Copy this file to somewhere (e.g. ~/.git-prompt.sh).
#2) Add the following line to your .bashrc/.zshrc:
#source ~/.git-prompt.sh
#3) Change your PS1 to also show the current branch:
# Bash: PS1='[\u@\h \W$(__git_ps1  (%s))]\$ '
# ZSH:  PS1='[%n@%m %c$(__git_ps1  (%s))]\$ '

(That's incomplete for zsh, but I'm digressing...). With the above, we
would change the bash instruction to

PROMPT_COMMAND='
PS1=$(printf \u \h \w %s$  $(__git_ps1 %s))
'

which may look more complicated to some. I think we can aim for
something like

PROMPT_COMMAND='__git_ps1_color \u \h \w%s$   (%s)'

so that the first arg is a PS1 string, %s there gets replaced by the git
prompt (if any), and the second arg defines the formatting of the git
prompt. This makes the ui (what you have to set the shells vars to) as
simple as possible.

As I said, I had done some fixes and refactoring to that effect already,
but I'm not going to race Simon.


I don't quite see how you're going to smurf the formatted string into 
the PS1 string at %s...


Wouldn't it be easier in this case to have the user provide 3 arguments:

PROMPT_COMMAND='__git_ps1 \u@\h:\w  (%s) \$ '

The first and last can be directly assigned to PS1 and the format string 
can be put in the middle.


BUT. In this way, it is still impossible to change the colors inside the 
format string, unless you ignore that when the user requested color 
hints. Because the output of printf will not be interpreted by bash when 
put in via command substitution.


The whole point of this exercise (for me at least) was to be able to 
color different parts of the bit that __git_ps1 put in, based on the 
current state of the tree.


I think the user interface could be something like:

use either:
PROMPT_COMMAND='__git_ps1 \u@\h:\w  \$ ' # 2 args!
or
PS1=\u@\h:\w $(__git_ps1 '(%s)')\$ 

(I just realised that I still need to handle the case where both PS1 and 
PROMPT_COMMAND contain __git_ps1 ;-)


Note that in the PS1 case, no color codes should be put into the string, 
as they will mangle the prompt length and wrapping problems start happening.


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] Add __git_ps1_pc to use as PROMPT_COMMAND

[Simon Oosthoek]

On 02/10/12 19:01, Junio C Hamano wrote:
 If your goal is to use PROMPT_COMMAND and not PS1, then yes between
 the two definitions of PROMPT_COMMAND above, the latter may look
 simpler.  But that does not explain why you want to prefer it over
 PS1 in the first place, which was the central point of my question
 that still has not been answered.
 
 Even more confused...
 

The specific answer to your question is that without using
PROMPT_COMMAND it doesn't seem to be possible to use colors based on the
state of the git tree. The reason being that in order to prevent
wrapping problems on the command line (specifically going up/down the
history list in bash or line wrapping on a long command). This is
prevented (and quite the norm in static PS1 strings) by enclosing the
terminal code for color inside \[ and \] so bash doesn't count these and
what is in between them in the length of the prompt string.

The only way to get the colors in without messing up normal functioning
of the prompt is to use PROMPT_COMMAND to set PS1, with colors based
dynamically on the state of the tree.

In my current version (which I haven't had time to properly send out,
sorry!) it can do both using the same __git_ps1 function. But only color
in the PROMPT_COMMAND mode for the reason laid out above.

Having said that, I think there's another benefit to using
PROMPT_COMMAND; I think it is more elegant to use a function via
PROMPT_COMMAND (now that I know of it), than using a function via
command substitution inside the PS1.

I guess your (and my) confusion is more caused by unfamiliarity with
this feature of bash than it being used. Is that correct?

*desperately trying to get out of confused mode*

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] Add __git_ps1_pc to use as PROMPT_COMMAND

[Simon Oosthoek]

On 09/28/2012 07:58 PM, Junio C Hamano wrote:

Simon Oosthoek soosth...@nieuwland.nl writes:


+# __git_ps1_pc accepts 0 arguments (for now)
+# It is meant to be used as PROMPT_COMMAND, it sets PS1
+__git_ps1_pc ()
+{
+   local g=$(__gitdir)
+   if [ -n $g ]; then
+...
+   fi
+}


This looks awfully similar to the existing code in __git_ps1
function.  Without refactoring to share the logic between them, it
won't be maintainable.



I agree that it's ugly. How about the following:

I modified __git_ps1 to work both in PROMPT_COMMAND mode and in that 
mode support color hints.


This way there's one function, so no overlap.

Shall I send patches for the two changes separately (to support 
PROMPT_COMMAND mode and another to support color hints) or in one?


And what about zsh support? I doubt the PROMPT_COMMAND thing is 
compatible with zsh, but the command substitution mode should probably 
work, unless it is already broken by the use of % to indicate untracked 
files (when GIT_PS1_SHOWUNTRACKEDFILES is set). Unless it is tested 
further in zsh, I'd say it might be better not to claim zsh is supported.


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] Add __git_ps1_pc to use as PROMPT_COMMAND

[Simon Oosthoek]

On 01/10/12 19:16, Junio C Hamano wrote:
 Simon Oosthoek soosth...@nieuwland.nl writes:
 
 On 09/28/2012 07:58 PM, Junio C Hamano wrote:
 Simon Oosthoek soosth...@nieuwland.nl writes:

 +# __git_ps1_pc accepts 0 arguments (for now)
 +# It is meant to be used as PROMPT_COMMAND, it sets PS1
 +__git_ps1_pc ()
 +{
 +  local g=$(__gitdir)
 +  if [ -n $g ]; then
 +...
 +  fi
 +}

 This looks awfully similar to the existing code in __git_ps1
 function.  Without refactoring to share the logic between them, it
 won't be maintainable.


 I agree that it's ugly. How about the following:

 I modified __git_ps1 to work both in PROMPT_COMMAND mode and in that
 mode support color hints.

 This way there's one function, so no overlap.
 
 I think the logical progression would be
 
  - there are parts of __git_ps1 you want to reuse for your
__git_ps1_pc; separate that part out as a helper function,
and make __git_ps1 call it, without changing what __git_ps1
does (i.e. no colors, etc.)
 
  - add __git_ps1_pc that uses the helper function you separated
out.
 
  - add whatever bells and whistles that are useful for users of
either __git_ps1 or __git_ps1_pc to that helper function.
 
 

Since this is the shell, it could turn out to be ugly this way:

function ps1_common {
set global variable (branchname, dirty state, untracked files,
divergence from upstream, etc.)
}

function __git_ps1 {
call ps1_common
print PS1 string based on format string or default (color in prompt
isn't an option) and include global variables where necessary
}

function __git_ps1_pc {
call ps1_common
set PS1=
based on hardcoded PS1 definition, expand the PS1 using global
variables (add color if requested)
}

The problem I see is that it would involve a lot of global variables
visible in the shell (OTOH, they could be used by other scripts, but
only when using this prompt ;-).
Or you could print a string, which can be caught in the relevant _ps1
function, but then this string needs to be chopped up and processed (by
a bunch of awk oneliners or bash-voodoo)

The latter introduces so much overhead (in processing and
maintainability) that I think it should not be considered.

That leaves passing the variables from one function to another using
globally scoped variables in the shell.

It can be done, but the current combined implementation has only the
global variables set by the user (GIT_PS1_SHOWDIRTYSTATE and so on) and
the rest remains local to the function.

The main obstacle to better code here is the need to work around the
shell's oddities. :-(

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] Add __git_ps1_pc to use as PROMPT_COMMAND

[Simon Oosthoek]

On 01/10/12 21:13, Junio C Hamano wrote:

 Hrm, let me ask a stupid question.  Why do we even need __git_ps1_pc
 in the first place?  Wouldn't it be just the matter of
 
   PROMPT_COMMAND='__git_ps1 %s'
 
 once you have __git_ps1 that works?

Apart from one small detail, PS1 must be set directly when __git_ps1 is
called as a PROMPT_COMMAND, while in command substitution mode,
__git_ps1 needs to put out a string value to substitute...

This is the way it works now (I'll send the patch later this week, I
want to test it some more...)

/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] Add __git_ps1_pc to use as PROMPT_COMMAND

[Simon Oosthoek]

On 01/10/12 21:54, Junio C Hamano wrote:
 Now you lost me.  The documentation of PROMPT_COMMAND in man bash
 says this:
 
PROMPT_COMMAND
   If set, the value is executed as a command prior to
   issuing each primary prompt.
 
 So yes, if you say PROMPT_COMMAND='whatever', you will get output
 from 'whatever' followed by what $PS1 would normally give you.  
 If you do not want to see PS1 after 'whatever' gives you, you have
 to set it to an empty string.
 
 On the other hand, they way people have been using __git_ps1 is (as
 described in the prompt script) to do something like this:
 
   PS1='...cruft... $(__git_ps1 %s) ...cruft...'
 
 To keep supporting them, __git_ps1 has to be a function that writes
 the prompt string to its standard output.  The external interface of
 PROMPT_COMMAND also is that it wants a command that emits the string
 desired for the prompt to its standard output.  I do not see any
 when it is used like this, X, but when it is used like that, Y
 kind of issue around it, either.
 
 So what is the problem
 

Well, I hadn't thought about that way of using it. It works in a way...

But PS1 is set and interpreted in a special way by bash (I gather from
examples, I'm kind of confused by it).

It's possible to set PS1 to nothing and print a string from
PROMPT_COMMAND, but then you miss out on all the features of the PS1
interpretation by bash and compared to the use of __git_ps1 at the
moment, it has to put out quite a different string. Because if you like
to see user@host+workdir (git-status)[$#]
the current users of __git_ps1 say PS1=\u@host+\w $(__git_ps1 %s)\$
, but all __git+ps1 has to put out is (branch) or (branch *), etc.

If it has to print the same prompt in PC mode, it has to add all the
user/host/workdir/[$#] data as well, withouth being able to use the bash
internal interpretation (because that is only working when PS1 is set).

The example(s) I found when googling for a solution were to set PS1
inside the PC function, in a way that it was possible to add color
encodings, without messing up the wrapping. This is _impossible_ using
command substitution, because then bash doesn't interpret the \[ and \]
around the color codes, and that messes up the accounting of how long
the prompt string is.

/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

[PATCH] Add __git_ps1_pc to use as PROMPT_COMMAND

[Simon Oosthoek]

Hi again

After the previous comments, I decided to attempt it using 
PROMPT_COMMAND rather than calling a function from command substitution 
in PS1. This new code works and doesn't have the wrapping issue anymore.
I've simplified some of the coloring stuff and for now there's no 
parameters to customize the PS1. Users will have to customize the 
function itself for now...
As a small observation, I think it's more logical to use PROMPT_COMMAND, 
since that explicitly uses a function, rather than using command 
substitution when setting PS1.
Obviously, as I didn't remove __git_ps1, the older use is unchanged, but 
now there is about 80% duplication of code between __git_ps1 and 
__git-ps1_pc
And AFAICT zsh is not supported here due to different escape characters 
(\ in bash, % in zsh)

Please let me know if and how this can/should be integrated!

Cheers

Simon




The function can set the PS1 varible optionally with
Colored hints about the state of the tree when
GIT_PS1_SHOWCOLORHINTS is set to a nonempty value.
This version doesn't accept arguments to customize the
prompt. And it has not been tested with zsh.

Signed-off-by: Simon Oosthoek soosth...@nieuwland.nl
---
 contrib/completion/git-prompt.sh |  135 
++

 1 file changed, 135 insertions(+)

diff --git a/contrib/completion/git-prompt.sh 
b/contrib/completion/git-prompt.sh

index 29b1ec9..8ed6b84 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -48,6 +48,16 @@
 # find one, or @{upstream} otherwise.  Once you have set
 # GIT_PS1_SHOWUPSTREAM, you can override it on a per-repository basis by
 # setting the bash.showUpstream config variable.
+#
+# If you would like colored hints in the branchname shown in the prompt
+# you can set PROMPT_COMMAND (bash) to __git_ps1_pc and export the +# 
variables GIT_PS1_SHOWDIRTYSTATE and GIT_PS1_SHOWCOLORHINT:

+# example:
+# export GIT_PS1_SHOWDIRTYSTATE=true
+# export GIT_PS1_SHOWCOLORHINT=true
+# export PROMPT_COMMAND=__git_ps1_pc
+# The prompt command function will directly set PS1, in order to +# 
insert color commands in a way that doesn't mess up wrapping.

  # __gitdir accepts 0 or 1 arguments (i.e., location)
 # returns location of .git repo
@@ -287,3 +297,128 @@ __git_ps1 ()
printf -- ${1:- (%s)} $c${b##refs/heads/}${f:+ $f}$r$p
fi
 }
+
+
+# __git_ps1_pc accepts 0 arguments (for now)
+# It is meant to be used as PROMPT_COMMAND, it sets PS1
+__git_ps1_pc ()
+{
+   local g=$(__gitdir)
+   if [ -n $g ]; then
+   local r=
+   local b=
+   if [ -f $g/rebase-merge/interactive ]; then
+   r=|REBASE-i
+   b=$(cat $g/rebase-merge/head-name)
+   elif [ -d $g/rebase-merge ]; then
+   r=|REBASE-m
+   b=$(cat $g/rebase-merge/head-name)
+   else
+   if [ -d $g/rebase-apply ]; then
+   if [ -f $g/rebase-apply/rebasing ]; then
+   r=|REBASE
+   elif [ -f $g/rebase-apply/applying ]; then
+   r=|AM
+   else
+   r=|AM/REBASE
+   fi
+   elif [ -f $g/MERGE_HEAD ]; then
+   r=|MERGING
+   elif [ -f $g/CHERRY_PICK_HEAD ]; then
+   r=|CHERRY-PICKING
+   elif [ -f $g/BISECT_LOG ]; then
+   r=|BISECTING
+   fi
+
+   b=$(git symbolic-ref HEAD 2/dev/null) || {
+
+   b=$(
+   case ${GIT_PS1_DESCRIBE_STYLE-} in
+   (contains)
+   git describe --contains HEAD ;;
+   (branch)
+   git describe --contains --all HEAD ;;
+   (describe)
+   git describe HEAD ;;
+   (* | default)
+   git describe --tags --exact-match HEAD 
;;
+   esac 2/dev/null) ||
+
+   b=$(cut -c1-7 $g/HEAD 2/dev/null)... ||
+   b=unknown
+   b=($b)
+   }
+   fi
+
+   local w=
+   local i=
+   local s=
+   local u=
+   local c=
+   local p=
+
+   if [ true = $(git rev-parse --is-inside-git-dir 
2/dev/null) ]; then
+			if [ true = $(git rev-parse --is-bare-repository 2/dev/null) ]; 
then

+   c=BARE:
+   else

Re: bash completion with colour hints

[Simon Oosthoek]

On 09/27/2012 10:53 AM, Michael J Gruber wrote:

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 now have a patch based on 1.7.12


- 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.


The only feature using it is untracked files, so that should probably be 
changed to work 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:


This would take me too much time



- You need to escape the escapes '\[', i.e. tell the shell that color
escapes produce zero length output, or else line wrapping is distorted.


A: this is something I've run into with my own contraption and I'm not 
sure I fixed it with my patch :-(


Can you give a more complete example of how that should work?



- Bash interpretes '\' only when PS1 is assigned, not when an expansion
in PS1 produces it.


is that true? how can \w produce the current working dir in the prompt?
Or do you mean it is translated to $PWD in some form internally?



- Some don't like it colorful, so the coloring needs to depend on a
config setting or env variable.


It is.



- Coloring should be consistent with other coloring in Git, such as
'status -s -b'.


That would be nice, I suppose the coloring is configurable for git, so 
the values would need to be dynamically imported from the git config. I 
don't know how to do that.




- 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).


Are you suggesting to use M instead of * or +? wouldn't that interfere 
with branchnames?




 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.


I think it should be possible in PS1 only.



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?


I doubt you can set PS1 from a function (effectively a subshell?)

Thanks for your comments

I will send an updated patch later

/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: bash completion with colour hints

[Simon Oosthoek]

On 09/27/2012 10:53 AM, Michael J Gruber wrote:



 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?


After some research, I completely agree with your assessment!

I don't think the performance issue is that big and it's the only way to 
get the colors in there without messing up word wrapping.


I'm afraid that either this will need a new function just to get the 
coloring hints or that it will break the usage of __git_ps1 entirely (if 
you'd require the user to use it as PROMPT_COMMAND instead of via PS1)


And I suppose this will not be compatible with zsh?

/Simon

PS, I'd rather have colours with wrapping issues, than no colour hints. 
But I realise this has to be fixed before inclusion into the main tree.



--
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

bash completion with colour hints

[Simon Oosthoek]

Hi Shawn

I only recently found the __git_ps1 function, but it wasn't directly 
able to replace my own contraption. I've modified the version I found 
after installing bash-completion in debian 6.


The patch is attached, it contains an escape character, so it is hard to 
include in plain text. I've gzipped it for convenience...


This is only a first step, I had a hard time figuring out what exactly 
the one-letter variables were doing (and still a bit unclear), so I'm 
sure this can be improved!


Anyway, the functionality of this patch is to show the output in green 
if the repo is up to date and red or other colours if it isn't.


Cheers

Simon


bash_git_completion_colour.patch.gz
Description: application/gzip

Re: bash completion with colour hints

[Simon Oosthoek]

On 26/09/12 17:24, Ramkumar Ramachandra wrote:
 Hi Simon,
 
 Could you follow the guidelines in Documentation/SubmittingPatches, so
 that the patch can be considered for inclusion?

Hi Ram, thanks for your feedback.

I gather now that this file is part of the entire git tree ;-)

this is my first time to submit a patch to git and frankly I coded this
up very quickly and did only a small test.

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
However, I guess that although I have been using something similar since
about 2009, I should at least base it on the relatively new
git-prompt.sh file, is this a correct interpretation of the guide?
(BTW, I wonder how this will affect ultimately the current master?)

- 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?

My instinct is to just apply my patch to the current master, but I'm
open to starting from a different base, but I'm too new to the tree to
know which one, any suggestions?



 
 --- git-orig-bak 2012-09-26 16:39:47.0 +0200
 +++ git-bashcompletion   2012-09-26 16:50:57.0 +0200
 @@ -59,6 +59,9 @@
  #   per-repository basis by setting the bash.showUpstream config
  #   variable.
  #
 +#   If you would like an additional hint in colour in your prompt
 +#   set GIT_PS1_SHOWCOLORHINT to a nonempty value. Currently
 +#   the colours are hardcoded in the function...
 
 Nit: I think it's spelt color everywhere else in git.
 

I can adapt ;-)

 +local c_red=' [31m'
 +local c_yellow=' [33m'
 +local c_lblue=' [1,34m'
 +local c_green=' [32m'
 +local c_purple=' [35m'
 +local c_cyan=' [36m'
 +local c_clear=' [0m'
 +local printf_format=${1:- (%s)}
 +
 +if [ -n ${GIT_PS1_SHOWCOLORHINT-} ]; then
 +if [ $w != * ]; then
 +printf_format=$c_green$printf_format$c_clear
 +else
 +printf_format=$c_red$printf_format$c_clear
 +fi
 +if [ -n $i ]; then
 +i=$c_yellow$i$c_clear
 +fi
 +if [ -n $s ]; then
 +s=$c_lblue$i$c_clear
 +fi
 +if [ -n $u ]; then
 +u=$c_purple$i$c_clear
 +fi
 +fi
 +
  local f=$w$i$s$u
 -printf ${1:- (%s)} $c${b##refs/heads/}${f:+ $f}$r$p
 +echo $(printf $printf_format $c${b##refs/heads/}${f:+ 
 $f}$r$p)

I'm still in some doubt over this last line, including the color codes
is confusing me...

I'll go ahead and try some more polishing and whatever more comes as
suggestions. Is it ok to bother the list with intermediate stuff in this
thread?

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