That's definitely a lot more full-featured, but seems like overkill for what I was trying to do.
Had I known about `git symbolic-ref`, I might have used that instead of `git branch`. On the other hand, I would have needed to re-implement lots of what `git branch` does, such as detecting the difference between not being in a git repository and simply not being on a branch.
The interface of `git branch` seems stable enough that I doubt it will break this. If it does, it should take me no longer than 5 minutes to fix, since that's about how long it would take me to re-write the whole thing from scratch.
Is there any particular reason that using `git symbolic-ref` is better than `git branch` in this case, given that I want human-readable output, instead an unambiguous filesystem location?
Personally, I'd argue you do want to keep track of whether you are in a repo or not, since including that pipeline in your PS1 always forks three processes on every prompt. And if you're going to do that in your shell, it's good to have separate commands for each task.
For the case of not being on a branch, the output of 'git branch' is not very useful. I am currently using 'git name-rev --name-only HEAD', but the contrib script has an even fancier mechanism (via 'git describe') for coming up with something to display when HEAD isn't a symbolic ref.
It also shows the correct state of merge/rebase in the prompt as well. In many distributions, it's installed as /etc/bash_completion.d/git when you install git from a package management system, you just need to source /etc/bash_completion to get all the benefits.