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,
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
* G?bor Szeder [2014-04-24 23:10:10 +0430]:
> > I'd like to see this patch eyeballed by those who have been involved
> > in the script (shortlog and blame tells me they are SZEDER and
> > Simon, CC'ed), so that we can hopefully merge it by the time -rc1 is
> > tagged.
>
> I think this is a se
* Piotr Krukowiecki [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 ~/.
On 28/11/12 19:02, Piotr Krukowiecki wrote:
> Is your setting?:
> PROMPT_COMMAND=__git_ps1
>
>
> That's right
>
>
> I believe you need to give 2 parameters in order to use it in
> PROMPT_COMMAND mode.
>
>
> Are you sure? git-prompt.sh says:
>
> #3a) In ~/.bashrc set PROM
On 28/11/12 21:47, Junio C Hamano wrote:
> Simon Oosthoek 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 &q
lain 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 writes:
>
>> perhaps the point should read li
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 i
On 12/12/12 18:50, Junio C Hamano wrote:
> Simon Oosthoek 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 re
* Junio C Hamano [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
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
---
contrib/completion/git-prompt.sh |
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 per
* Junio C Hamano [2012-12-26 11:45:48 -0800]:
> Simon Oosthoek 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 t
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 per
* Junio C Hamano [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" m
* Junio C Hamano [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 a7fe7de8
> >
> > But I'll save that as an exercise for the reader (or the future)
>
> I think a much more
* Junio C Hamano [2013-06-18 09:48:28 -0700]:
> SZEDER Gábor 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
> > me
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'
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 fir
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 pa
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 wh
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
---
co
On 09/28/2012 07:58 PM, Junio C Hamano wrote:
Simon Oosthoek 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
+}
On 01/10/12 19:16, Junio C Hamano wrote:
> Simon Oosthoek writes:
>
>> On 09/28/2012 07:58 PM, Junio C Hamano wrote:
>>> Simon Oosthoek writes:
>>>
>>>> +# __git_ps1_pc accepts 0 arguments (for now)
>>>> +# It is meant to be
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
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_COM
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 tha
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 poin
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
---
contrib/completion/git-prompt.sh | 42 +++---
1 file changed, 39 insertions
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
---
contrib/completion/git-prompt.sh
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 precm
Hi Junio
thanks for your feedback!
On 08/10/12 20:12, Junio C Hamano wrote:
> Simon Oosthoek 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_COMM
enclosed zero-width codes in
between don't count in the length of the prompt.
Signed-off-by: Simon Oosthoek
---
contrib/completion/git-prompt.sh | 51 +-
1 file changed, 45 insertions(+), 6 deletions(-)
diff --git a/contrib/completion/git-prompt.sh b/co
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
---
contrib/completion/git-prompt.sh | 36
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
---
contrib/completion/git-prompt.sh | 51 +-
1 file change
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
---
contrib/completion/git-prompt.sh | 36
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 co
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 enab
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 exac
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
me is only
colored red if the tree has a detached HEAD.
Signed-off-by: Simon Oosthoek
---
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-promp
er red or green for unstaged/staged and the
remaining flags get a different color or none at all.
Signed-off-by: Simon Oosthoek
---
contrib/completion/git-prompt.sh | 52 +++---
1 file changed, 31 insertions(+), 21 deletions(-)
diff --git a/contrib/completion/git
On 16/10/12 23:30, Junio C Hamano wrote:
> Simon Oosthoek 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 direc
On 19/02/13 00:07, Junio C Hamano wrote:
>
> I think you are misreading a suggestion that is somewhat misguided
> (yes "[ && ]" does not make sense, but that is
> not applicable to "test && test "); ignore it.
>
> It is fine to write "test && test " and that
> works portably to even pre-posix
44 matches
Mail list logo
