Watch for `branch --show-current` patch

[rpdelaney]

There's a patch being considered here: https://public-inbox.org/git/20181025190421.15022-1-daniels@umanovskis.se/t/#u

When called with --show-current, git branch will print the current
branch name and terminate. Only the actual name gets printed,
without refs/heads. In detached HEAD state, nothing is output.

However, as the threaded discussion shows, the implementation of this switch (and its intended use for scripting / machine parsing) is controversial. I don't know if it will be accepted or not.

Regardless, if it is accepted, do we want to use it anyway? Some time would pass before the new git version would be distributed widely enough.

[twolfson]

It seems like a nice feature. I'm going to concur that it's going to take a while to distribute. I'd like to support back to the default git found on common OS PPA's. For example, the Ubuntu 12.04 was 1.7.9.5-1:

https://github.com/twolfson/sexy-bash-prompt/blob/0.28.0/.travis.yml#L3-L5

We can prob move to a later version of Ubuntu, it looks like 14.04 is still in LTS though it will be out in early 2019:

https://www.ubuntu.com/about/release-cycle

[twolfson]

I'm also open to the idea of defining different bash functions based on feature availability. We should vet that it's faster performance though:

# Unsure if this works like this
if $(git branch --current-version &> /dev/null); then
  function sexy_bash_prompt_get_git_branch() {
    git branch --current-version
  }
else
  function sexy_bash_prompt_get_git_branch() {
    # Old version
  }
fi

[rpdelaney]

It does:

$ cat foo && source foo && _foo && _bar
#!/usr/bin/env bash
if true; then
  _foo() {
    echo "foo-true"
  }
else
  _foo() {
    echo "foo-false"
  }
fi

if false; then
  _bar() {
    echo "bar-true"
  }
else
  _bar() {
    echo "bar-false"
  }
fi
# EOF
foo-true
bar-false
$

I'm imagining two uses for such a construction here:

1. For UI/UE purposes, we want to exploit functionality of a new git revision with a fallback behavior if it's not found;
2. Same as the above except for performance instead of user experience.

No. 2 seems implausible, because (as you mentioned) testing if the switch is there requires running the command, which could eat up any performance gain. It might even be faster to just parse the git version at startup and infer what's available and what isn't.

As for No. 1, that seems conceivable but this project is pretty stable at this point and I don't know what features we would want to add that would require this. I suppose we can keep it in the back-of-mind in case something comes up in the future that we're hungry to incorporate.

[twolfson]

Yea, I feel like (1) isn't super practical. I'm pretty sure this prompt is as stable as it's going to get. We've only had a few feature requests and they've all been one-offs better as forks

(2) is quite practical. The tradeoff would be doing the logic check at shell launch. However, once the shell is launched, the function we want to run (without doing the if check) is now cached so it could be faster to run on each new line

[rpdelaney]

You're right. We only have to check when .bash_prompt is sourced. This gives me some other ideas, but I'm not in a hurry to follow up on them at the moment. I'll circle back if I get something more than half baked. Thanks