Re: [PATCH] bash completion: Support "divergence from upstream" messages in __git_ps1

[Thomas Rast <trast@student.ethz.ch>]

Andrew Sayers wrote:
> I've added a message in the "equal to upstream" case, to differentiate
> it from the "no upstream" case.  Again, this is an over-the-shoulder
> issue - when I see an "=" (or " u=") in someone's prompt, I don't have
> to patronise them about whether they've e.g. misconfigured their
> branch.

I omitted it because I thought it would be too cluttery, but then my
branches seem to rarely agree with their upstream.

> +       local cfg=( $( git config --get-regexp '^bash\.showUpstream$|^svn-remote\..*\.url$' 2>/dev/null ) )

Doesn't this break if the config value contains spaces?  I don't know
enough about bash arrays but in my simple tests, the array elements
are split between words.

And with the new design, you practically *expect* the config key to
contain spaces.

Along the same lines, I think
> +                               GIT_PS1_SHOWUPSTREAM="${cfg[$((n+1))]}"
> +                               if [[ -z "${GIT_PS1_SHOWUPSTREAM}" ]]; then
can never trigger because bash will never see the empty config string.

Slightly more robust would be to use

  git config --get-regexp '^bash\.showUpstream$|^svn-remote\..*\.url$' \
    2>/dev/null |
  while read key value, do
    # stuff
  done

That still breaks in the case of values containing newlines, though.

> I like the "ref" option, but I'm not really sure when "eval" would be
> useful.  I've changed it here to "cmd" so people are encouraged to put
> their work in a script.
[...]
> +#           cmd=<command> compare HEAD to the output of <command>
[...]
> +		cmd\=*) upstream=$( "${option:4}" ) ;;

"Encourage" is a mild understatement; AFAICS the code doesn't work
with more than single-word command any more.

The original intent was that the user could put a (very small) shell
script directly in the configuration if the normal DWIMming doesn't
fit his neds, perhaps most likely in the case of git-svn (do other
remote helpers have the same problem?).

Having to wrap it in a script defeats that point, as it becomes almost
as easy to edit the completion script.  So I think if it can't eval,
you might as well remove it.

BTW, please spell $(command) substitution without the spaces.  Your
current style does not match what is already in the file.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch