On Thu, Feb 04, 2016 at 11:34:59AM +0100, Sebastian Schuberth wrote: > This avoids output like > > warning: ignoring broken ref refs/remotes/origin/HEAD > > while completing branch names. Hmm. I feel like this case (HEAD points to a branch, then `fetch --prune` deletes it) came up recently and we discussed quieting that warning. But now I cannot seem to find it. Anyway, I this is a reasonable workaround. Errors from bash completion scripts are almost always going to be useless and get in the way of reading your own prompt. > diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash > index 15ebba5..7c0549d 100644 > --- a/contrib/completion/git-completion.bash > +++ b/contrib/completion/git-completion.bash > @@ -317,7 +317,7 @@ __git_heads () > local dir="$(__gitdir)" > if [ -d "$dir" ]; then > git --git-dir="$dir" for-each-ref --format='%(refname:short)' \ > - refs/heads > + refs/heads 2>/dev/null > return Not really related to your topic, but digging into it caused me to read b7dd2d2 (for-each-ref: Do not lookup objects when they will not be used, 2009-05-27), which is about making sure for-each-ref is very fast in completion. It looks like %(refname:short) is actually kind of expensive: $ time git for-each-ref --format='%(refname)' refs/tags >/dev/null real 0m0.004s user 0m0.000s sys 0m0.004s $ time git for-each-ref --format='%(refname:short)' refs/tags >/dev/null real 0m0.009s user 0m0.004s sys 0m0.004s The upcoming refname:strip does much better: $ time git for-each-ref --format='%(refname:strip=2)' refs/tags >/dev/null real 0m0.004s user 0m0.000s sys 0m0.004s Obviously these are pretty small timings from my git.git with ~600 tags, but you can see that refname:short really does cost more. On a more ridiculous example repository I have with about 10 million refs, the timings are more like 5s, 66s, 5.5s. Just thought I'd throw that our there in case any completion people feel like poking around with it. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html