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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html