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

From: Thomas Rast <trast@student.ethz.ch>
Date: Jun 14, 2010, 07:42 UTC
Message-ID: <201006140942.43099.trast@student.ethz.ch>
In-Reply-To: <4C13F32B.7060106@pileofstuff.org>

Andrew Sayers wrote:

Show 5 quoted lines

> 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