Sean <seanlkml@xxxxxxxxxxxx> wrote:
> On Mon, 27 Nov 2006 01:54:00 -0500
> Shawn Pearce <spearce@xxxxxxxxxxx> wrote:
>
> > I'm using something like this, and will be adding it to
> > git-completion.bash tonight:
> >
> > __git_ps1 ()
> > {
> > local b="$(git symbolic-ref HEAD 2>/dev/null)"
> > if [ -n "$b" ]; then echo "(${b##refs/heads/})"; fi
> > }
> > PS1='[\u@\h \W$(__git_ps1)]\$ '
> >
> > it works very well...
>
> Yeah, when I first coded it I even looked at making it a bash loadable
> to make it perform better but found the prototype to run acceptably,
> so never bothered.
When I originally coded the first version of __git_ps1 I was using
it on a Cygwin system, where the fork+exec of the external script
can take a little while. The time to fork+exec two programs (script
and then git) is huge compared to just fork+exec of git by itself,
so I coded it as a function. On the other hand my Mac OS X system
doesn't even blink at either implementation.
> If Git does get a --show-ps1 option, people will
> still be able to roll their own version to tweak the output format
> as you did above. Hopefully the standard format will work for most
> though.
I'm not sure that's worth implementing in the core code.
Most shells that will let you invoke a command as part of their
prompt generation will also let you use builtin functions and do
some basic string manipulation (e.g. like I do above with bash).
At which point it is say 5 lines of shell (nicely formatted) to
craft a prompt string vs. 15-20 lines of C to parse the option,
read HEAD, and craft a prompt string.
If someone else contributes a --show-ps1 option that is useable as
a replacement for my __git_ps1 I'll gladly jump on board and change
to using it, but I just don't see a reason to write it myself.
--
Shawn.
-
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