It's better to use a plumbing command for this sort of thing; git-completion.bash (http://git.kernel.org/?p=git/git.git;a=blob;f=contrib/comple...) has a thorough example. (The actual command called is 'git symbolic-ref HEAD'.)
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?
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.
export PS1='\w:$(__git_ps1 "%s")$ '
function parse_git_dirty {
git diff --quiet HEAD &>/dev/null
[[ $? == 1 ]] && echo "✎ " || echo "➜ "
}
function parse_git_branch {
local branch=$(__git_ps1 "%s")
[[ $branch ]] && echo "$branch$(parse_git_dirty)"
}
PS1='\u@\h $(parse_git_branch)\W $ '
The OP is an example of wheel reinvented, poorly.